[prev in list] [next in list] [prev in thread] [next in thread]
List: mpls
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT)
From: Alvaro Retana <aretana.ietf () gmail ! com>
Date: 2020-12-18 16:11:03
Message-ID: CAMMESsx0G6kRS1ScRzAd9uZ20u8aqTgvXVhG99QWaCtiKcKFnQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Chandra:
It looks good. I have cleared the DISCUSS.
Thanks!
Alvaro.
From: Chandrasekar Ramachandran <csekar@juniper.net> <csekar@juniper.net>
Date: December 18, 2020 at 10:13:24 AM
To: Alvaro Retana <aretana.ietf@gmail.com> <aretana.ietf@gmail.com>, The
IESG <iesg@ietf.org> <iesg@ietf.org>, BRUNGARD, DEBORAH A <db3546@att.com>
<db3546@att.com>
CC: mpls-chairs@ietf.org <mpls-chairs@ietf.org> <mpls-chairs@ietf.org>,
mpls@ietf.org <mpls@ietf.org> <mpls@ietf.org>,
draft-ietf-mpls-ri-rsvp-frr@ietf.org <draft-ietf-mpls-ri-rsvp-frr@ietf.org>
<draft-ietf-mpls-ri-rsvp-frr@ietf.org>, Nicolai Leymann
<n.leymann@telekom.de> <n.leymann@telekom.de>
Subject: RE: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07:
(with DISCUSS and COMMENT)
Hi Alvaro,
> Please refer inline.
>
> Thanks,
> Chandra.
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: Alvaro Retana <aretana.ietf@gmail.com>
> Sent: Friday, December 11, 2020 5:15 PM
> To: Chandrasekar Ramachandran <csekar@juniper.net>; The IESG
> <iesg@ietf.org>; BRUNGARD, DEBORAH A <db3546@att.com>
> Cc: mpls-chairs@ietf.org; mpls@ietf.org;
> draft-ietf-mpls-ri-rsvp-frr@ietf.org;
> Nicolai Leymann <n.leymann@telekom.de>
> Subject: RE: Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07:
> (with
> DISCUSS and COMMENT)
>
> [External Email. Be cautious of content]
>
>
> On November 23, 2020 at 12:19:22 AM, Chandrasekar Ramachandran wrote:
>
>
> Chandra:
>
> Hi!
>
> I have reworded the text in Section 4.1 to spell out the requirements
> on setting or not setting the I-bit by implementations that support
> RFC 4090 and RFC 8370. I have also included a new Section 4.6.2.3
> "Advertising RI-RSVP without RI-RSVP-FRR" describing the impact of
> ignoring the requirements for setting the I-bit.
>
> Could you go through these sections in the 09 version of the draft and
> respond if your comment is addressed?
>
>
> The text in §4.1 still contains normative text directed at nodes that
> don't
> support this spec: "node...not supporting the extensions
> specified in this document MUST NOT set the...I bit". Your original
> suggestion worked:
>
>
> [Chandra] I have removed the first sentence and switched to the previously
> agreed text you have referred to below. Please check version 10 of the
> draft that I uploaded today.
>
> ...
>
> [Chandra] I agree that what you have pointed out requires some
> changes to the text. Would the following changes to the
> document address your concerns adequately?
>
> ...
>
> (3) Change the only paragraph in Section 4.1 from "A node
> supporting [RFC4090] facility protection FRR MAY set the
> RI-RSVP capability (I
> bit) defined in Section 3 of RSVP-TE Scaling Techniques
> [RFC8370] only if it supports all the extensions specified in
> the rest of this document. A node supporting [RFC4090]
> facility bypass FRR but not supporting the extensions
> specified in this document MUST reset the RI-RSVP capability
> (I bit) in the outgoing Node-ID based Hello messages. Hence,
> this document updates [RFC4090] by defining extensions and
> additional procedures over facility protection FRR defined in
> [RFC4090] in order to advertise RI-RSVP capability [RFC8370]."
> To
> "A node supporting [RFC4090] facility protection FRR MUST set
> the RI-RSVP capability (I bit) defined in Section 3 of RSVP-TE
> Scaling Techniques [RFC8370] only if it supports all the
> extensions specified in the rest of this document. Hence, this
> document updates [RFC4090] and [RFC8370] by defining
> extensions and additional procedures over facility protection
> FRR defined in [RFC4090] in order to advertise RI-RSVP capability
>
> [RFC8370]."
>
>
> I think that §4.6.2.3 is ok, but there's still the possibility of some of
> the timing
> issues described in §3 as well, right?
>
>
> [Chandra] If a node running RFC 4090 does set the I bit without the
> extensions specified in this draft, then it does leave room for the problem
> described in Section 3. I have added a reference to Section 3 from 4.6.2.3
> in version
> 10 of the draft that I uploaded today.
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ri-rsvp-frr-09&url2=draft-ietf-mpls-ri-rsvp-frr-10&difftype=--hwdiff
>
> Thanks,
> Chandra.
>
[Attachment #5 (text/html)]
<html><head></head><body>Chandra:<div><br></div><div>It looks good. I have cleared \
the DISCUSS.</div><div><br></div><div>Thanks!</div><div><br></div><div>Alvaro.<br> \
<div class="gmail_quote" style="color:black"><br>From: <span \
style="color:black">Chandrasekar Ramachandran</span> <a \
href="mailto:csekar@juniper.net"><csekar@juniper.net></a><br>Date: <span \
style="color:black">December 18, 2020 at 10:13:24 AM</span><br>To: <span \
style="color:black">Alvaro Retana</span> <a \
href="mailto:aretana.ietf@gmail.com"><aretana.ietf@gmail.com></a>, <span \
style="color:black">The IESG</span> <a \
href="mailto:iesg@ietf.org"><iesg@ietf.org></a>, <span \
style="color:black">BRUNGARD, DEBORAH A</span> <a \
href="mailto:db3546@att.com"><db3546@att.com></a><br>CC: <span \
style="color:black"><a \
href="mailto:mpls-chairs@ietf.org">mpls-chairs@ietf.org</a></span> <a \
href="mailto:mpls-chairs@ietf.org"><mpls-chairs@ietf.org></a>, <span \
style="color:black"><a href="mailto:mpls@ietf.org">mpls@ietf.org</a></span> <a \
href="mailto:mpls@ietf.org"><mpls@ietf.org></a>, <span style="color:black"><a \
href="mailto:draft-ietf-mpls-ri-rsvp-frr@ietf.org">draft-ietf-mpls-ri-rsvp-frr@ietf.org</a></span> \
<a href="mailto:draft-ietf-mpls-ri-rsvp-frr@ietf.org"><draft-ietf-mpls-ri-rsvp-frr@ietf.org></a>, \
<span style="color:black">Nicolai Leymann</span> <a \
href="mailto:n.leymann@telekom.de"><n.leymann@telekom.de></a><br>Subject: \
<span style="color:black"> RE: Alvaro Retana's Discuss on \
draft-ietf-mpls-ri-rsvp-frr-07: (with DISCUSS and COMMENT) <br></span></div><br> \
<blockquote type="cite" class="gmail_quote"><span><div><div></div><div>Hi Alvaro, \
<br>Please refer inline. <br>
<br>Thanks,
<br>Chandra.
<br>
<br>
<br>Juniper Business Use Only
<br>
<br><blockquote type="cite">-----Original Message-----
<br>From: Alvaro Retana <<a \
href="mailto:aretana.ietf@gmail.com">aretana.ietf@gmail.com</a>> <br>Sent: Friday, \
December 11, 2020 5:15 PM <br>To: Chandrasekar Ramachandran <<a \
href="mailto:csekar@juniper.net">csekar@juniper.net</a>>; The IESG <br><<a \
href="mailto:iesg@ietf.org">iesg@ietf.org</a>>; BRUNGARD, DEBORAH A <<a \
href="mailto:db3546@att.com">db3546@att.com</a>> <br>Cc: <a \
href="mailto:mpls-chairs@ietf.org">mpls-chairs@ietf.org</a>; <a \
href="mailto:mpls@ietf.org">mpls@ietf.org</a>; <a \
href="mailto:draft-ietf-mpls-ri-rsvp-frr@ietf.org">draft-ietf-mpls-ri-rsvp-frr@ietf.org</a>;
<br>Nicolai Leymann <<a \
href="mailto:n.leymann@telekom.de">n.leymann@telekom.de</a>> <br>Subject: RE: \
Alvaro Retana's Discuss on draft-ietf-mpls-ri-rsvp-frr-07: (with <br>DISCUSS and \
COMMENT) <br>
<br>[External Email. Be cautious of content]
<br>
<br>
<br>On November 23, 2020 at 12:19:22 AM, Chandrasekar Ramachandran wrote:
<br>
<br>
<br>Chandra:
<br>
<br>Hi!
<br>
<br><blockquote type="cite">I have reworded the text in Section 4.1 to spell out the \
requirements <br>on setting or not setting the I-bit by implementations that support
<br>RFC 4090 and RFC 8370. I have also included a new Section 4.6.2.3
<br>"Advertising RI-RSVP without RI-RSVP-FRR" describing the impact of
<br>ignoring the requirements for setting the I-bit.
<br>
<br>Could you go through these sections in the 09 version of the draft and
<br>respond if your comment is addressed?
<br></blockquote>
<br>The text in §4.1 still contains normative text directed at nodes that don't
<br>support this spec: "node...not supporting the extensions
<br>specified in this document MUST NOT set the...I bit". Your original
<br>suggestion worked:
<br>
<br></blockquote>
<br>[Chandra] I have removed the first sentence and switched to the previously agreed \
text you have referred to below. Please check version 10 of the draft that I uploaded \
today. <br>
<br><blockquote type="cite">...
<br><blockquote type="cite"><blockquote type="cite"><blockquote \
type="cite"><blockquote type="cite"><blockquote type="cite">[Chandra] I agree that \
what you have pointed out requires some <br>changes to the text. Would the following \
changes to the <br>document address your concerns adequately?
<br></blockquote>...
<br><blockquote type="cite">(3) Change the only paragraph in Section 4.1 from "A \
node <br>supporting [RFC4090] facility protection FRR MAY set the
<br>RI-RSVP capability (I
<br>bit) defined in Section 3 of RSVP-TE Scaling Techniques
<br>[RFC8370] only if it supports all the extensions specified in
<br>the rest of this document. A node supporting [RFC4090]
<br>facility bypass FRR but not supporting the extensions
<br>specified in this document MUST reset the RI-RSVP capability
<br>(I bit) in the outgoing Node-ID based Hello messages. Hence,
<br>this document updates [RFC4090] by defining extensions and
<br>additional procedures over facility protection FRR defined in
<br>[RFC4090] in order to advertise RI-RSVP capability [RFC8370]."
<br>To
<br>"A node supporting [RFC4090] facility protection FRR MUST set
<br>the RI-RSVP capability (I bit) defined in Section 3 of RSVP-TE
<br>Scaling Techniques [RFC8370] only if it supports all the
<br>extensions specified in the rest of this document. Hence, this
<br>document updates [RFC4090] and [RFC8370] by defining
<br>extensions and additional procedures over facility protection
<br>FRR defined in [RFC4090] in order to advertise RI-RSVP capability
<br></blockquote></blockquote></blockquote></blockquote></blockquote>[RFC8370]."
<br>
<br>
<br>I think that §4.6.2.3 is ok, but there's still the possibility of some of \
the timing <br>issues described in §3 as well, right?
<br>
<br></blockquote>
<br>[Chandra] If a node running RFC 4090 does set the I bit without the extensions \
specified in this draft, then it does leave room for the problem described in Section \
3. I have added a reference to Section 3 from 4.6.2.3 in version <br>10 of the \
draft that I uploaded today. <br><a \
href="https://www.ietf.org/rfcdiff?url1=draft-ietf-mpls-ri-rsvp-frr-09&url2=draft- \
ietf-mpls-ri-rsvp-frr-10&difftype=--hwdiff">https://www.ietf.org/rfcdiff?url1=draf \
t-ietf-mpls-ri-rsvp-frr-09&url2=draft-ietf-mpls-ri-rsvp-frr-10&difftype=--hwdiff</a>
<br>
<br>Thanks,
<br>Chandra.
<br></div></div></span></blockquote> <br><div class="gmail_signature"></div>
</div></body></html>
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic