Re: [Lsr] AD review of draft-ietf-lsr-ospf-bfd-strict-mode-05
Hi Ketan, My comments in line below. > On Sep 2, 2022, at 6:37 AM, Ketan Talaulikar wrote: > > Hi John, > > Please check inline below for responses with KT2 > > > On Thu, Sep 1, 2022 at 10:42 PM John Scudder wrote: > Hi Ketan, > > Thanks for the prompt update. I have one question about your edits. In > Section 6, I had suggested > > OLD: >Implementations MAY >provide a local configuration option to specifically enable BFD >operation in OSPF BFD strict-mode only. > > NEW (my suggestion): >Implementations MAY >provide a local configuration option to require BFD strict-mode. > > NEW (your revision): >Implementations MAY >provide a local configuration option to require BFD operation in OSPF >BFD strict-mode only. > > I’m wrestling with whether this option is supposed to mean “the adjacency > must not establish unless BFD comes up first” or “if the neighbor supports > BFD, then BFD must come up first before the adjacency is allowed to > establish”. > > KT2> I meant the former. So this is like "force" BFD strict-mode operation. > The default mode is negotiation when strict-mode is enabled. > > I.e., as written I can make the argument that if my neighbor doesn’t > advertise the B-bit, then it’s fine for the adjacency to come up as long as > BFD isn’t run at all. The former interpretation seems more operationally > useful, but the spec text is ambiguous. > > I’m not sure my proposed text even resolved that problem, on reflection. In > any case, I would be happier if the ambiguity were resolved somehow. > > KT2> How about the following? > > Implementations MAY provide a local configuration option to force BFD > operation only in > OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session is > established). It gets the job done; good enough. [snip] > > Whenever the neighbor state transitions to Down state, the removal of > > the BFD session associated with that neighbor SHOULD be requested by > > @@ -246,6 +281,14 @@ > > result in the deletion and creation of the BFD session respectively > > when OSPF is the only client interested in the BFD session with the > > neighbor address. > > + > > +jgs: Please do a global search for the RFC 2119 keyword SHOULD and in > > +each instance, consider whether it can be a MUST, or the normal English > > +word "should" (in lower or mixed case). If SHOULD is the appropriate > > +keyword, please supply some detail about when it would be appropriate > > +for an implementor to disregard the SHOULD. (The one place where I > > +thought "should" might be the appropriate choice is in the Operations & > > +Management Considerations section.) > > > > KT> In this specific case, we are discussing implementation specifics that > > are also applicable without the strict-mode, and hence introducing a MUST > > here was not appropriate. We could change it to "should" if that would be > > more appropriate. Looking for feedback if this change is required. > > This actually motivates the question, why does that paragraph need to be > there at all? Was the base behavior underspecified and in need of update? > > KT2> Yes, I believe has been underspecified in RFC5882. > > Is this just a nota bene for the implementor? Should you more clearly signal > that’s what it is? But this is in any case tangential to the main point; we > can return to it later perhaps. I did note the peculiar nature of the > paragraph on my first read-through, and figured it did no harm to clarify > that this is how implementations should be done regardless — but in any case > I don’t see why that makes MUST inappropriate. > > KT2> This is at the end and internal behavior between OSPF and BFD within a > system. It may be possible to do this differently and yet exhibit the same > external behavior. That is why either SHOULD or should seem more appropriate. If I understand the situation correctly (and I haven’t gone and re-checked what RFC 5882 says), that sounds like a case for “should”. You can change it (and the one subsequent SHOULD that’s in the same category, total three) or not, at your discretion. > > In some other places, the behavior may be applicable and shared with "base" > > BFD and hence we felt not appropriate to make it a MUST. However, we have > > taken the opportunity to suggest a desirable behavior. We look for feedback > > if any specific instance needs change or clarification. > > I have a different take on the appropriate use of SHOULD vs. MUST. Let’s look > at what RFC 2119 says about SHOULD: > > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there >may exist valid reasons in particular circumstances to ignore a >particular item, but the full implications must be understood and >carefully weighed before choosing a different course. > > I tend to think of SHOULD informally as a “MUST… UNLESS” pair. > > KT2> I am not sure if the "MUST ... UNLESS"
Re: [Lsr] AD review of draft-ietf-lsr-ospf-reverse-metric-05
Hi Ketan, LGTM generally. Regarding your uses of SHOULD, the updates to refer to Section 7 are helpful. I agree that the other uses are innocuous enough as to be obvious to “one versed in the art”; we shall see if other reviewers agree. I personally am not crazy about RFC 2119 keywords directed at operators rather than implementors (e.g. the first use in Section 10) but I accept that it’s a common pattern. Regarding the “don’t write bugs” text, if I were reviewing the prior RFC I would also have flagged that one too. I don’t insist that it be removed, but gosh it doesn’t seem to add anything actionable. Remaining open items — Minor: For this text: For the use case in Section 2.1, it is RECOMMENDED that the network operator limit the period of enablement of the reverse metric mechanism only for the duration of a network maintenance window. I suggest For the use case in Section 2.1, it is RECOMMENDED that the network operator limit the period of enablement of the reverse metric mechanism to be only the duration of a network maintenance window. Nits: - I had suggested changing “4 octet” to “4 octets”, was this missed or deliberately not adopted? - s/safegaurd/safeguard/ Regards, —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04
Hi Ketan, Thanks for the update. > On Sep 2, 2022, at 9:16 AM, Ketan Talaulikar wrote: > > Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs' > sub-TLVs, we need another flag X for those sub-TLVs that are not associated > with the Router Link TLV. Good point. But, doesn’t that suggest that if we’re going to annotate the registry anyway, it should be annotated to indicate applicability for each sub-TLV type? That would clean up the presentation from Y/N/X to just Y/N per column. It would add a lot more columns but we don’t pay by the column. :-) If there’s some reason this wouldn’t be valuable that’s OK but I’d like to understand what makes Router Link and L2 Bundle Member need special treatment that the other sub-TLVs don’t need. Thanks, —John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] IPR Disclosure ORANGE's Statement about IPR related to draft-ietf-lsr-isis-fast-flooding
Dear Bruno Decraene, Les Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Chris Bowers, Gunter Van de Velde, Peter Psenak, Tony Przygienda: An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS Fast Flooding" (draft-ietf-lsr-isis-fast-flooding) was submitted to the IETF Secretariat on 2022-09-01 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (/ipr/5797/history/). The title of the IPR disclosure is "ORANGE's Statement about IPR related to draft-ietf-lsr-isis-fast-flooding" Thank you IETF Secretariat ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD review of draft-ietf-lsr-ospf-l2bundles-04
Hi John, Thanks for your review. I think it is a good idea to indicate and capture applicability as part of the IANA registry. This will ensure compliance for sub-TLVs defined in the future. An updated version of the draft that captures these changes is posted for your and WG review/comments: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05 Since the OSPFv3 registry is shared for all OSPFv3 Extended LSA TLVs' sub-TLVs, we need another flag X for those sub-TLVs that are not associated with the Router Link TLV. Thanks, Ketan On Thu, Sep 1, 2022 at 6:44 PM John Scudder wrote: > Dear Authors, > > Thanks for this short, clean, document. I have no nits (!!) and only one > substantive comment to discuss. > > In Figures 2 and 3, you annotate all the sub-TLVs from the relevant OSPFv2 > and OSPFv3 registries, to indicate whether those sub-TLVs are, or are not, > applicable in the context of the L2 Bundle Member Attribute Sub-TLV. It > seems to me that it would be helpful to update the registries themselves, > to add a column with this information. In addition to making the > information easier to find, it would also reduce the risk of future > document authors forgetting to specify this information. (It’s all very > well for your spec to say that future documents MUST supply this > information, but such mandates on future document authors are hard to > enforce consistently, absent some process. Updating the IANA registry would > provide that process.) > > Related, the OSPFv3 registry now has three additional code points, beyond > those you annotate. I guess you should update Figure 3 to specify Y/N for > code points 30-32. > > Thanks, > > —John > > > ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-lsr-ospf-l2bundles-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : Advertising Layer 2 Bundle Member Link Attributes in OSPF Authors : Ketan Talaulikar Peter Psenak Filename: draft-ietf-lsr-ospf-l2bundles-05.txt Pages : 10 Date: 2022-09-02 Abstract: There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the Layer 3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-l2bundles/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-l2bundles-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-l2bundles-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD review of draft-ietf-lsr-ospf-reverse-metric-05
Hi John, Thanks for your detailed review. We've incorporated the editorial changes suggested by you. Please check inline below for responses. An update with these changes has also been posted: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-06 On Thu, Sep 1, 2022 at 2:28 AM John Scudder wrote: > Dear Authors, > > Thanks for your patience. Here’s my review. > > I’ve supplied my comments in the form of an edited copy of the draft. > Minor editorial suggestions I’ve made in place without further comment, > more substantive comments are done in-line and prefixed with “jgs:”. You > can use your favorite diff tool to review them; I’ve attached a PDF of the > iddiff output for your convenience if you’d like to use it. I’ve also > pasted a traditional diff below in case you want to use it for in-line > reply. > > Thanks, > > —John > > > --- draft-ietf-lsr-ospf-reverse-metric-05.txt 2022-08-30 > 14:25:14.0 -0400 > +++ draft-ietf-lsr-ospf-reverse-metric-05-jgs-comments.txt 2022-08-31 > 16:54:21.0 -0400 > @@ -1,4 +1,18 @@ > - > +jgs: Nit, the doc is inconsistent on what case to use for "hello" > +(sometimes spelled Hello, sometimes hello) and also mixes "Hello > +packets" and "hello messages". Can you pick one and stick with it? (RFC > +2328 calls them "Hello packets".) > KT> Ack. Changed to "Hello packet" for consistency. > + > +jgs: This document makes fairly liberal use of SHOULD. Please review > +these. For each one, please consider whether it can be a MUST instead, > +or the plain English word "should", or some other construction (e.g. a > +statement like "A router receiving a Hello packet from its neighbor that > +contains the Reverse Metric TLV on a link uses the RM value to derive > +the metric for the link..."). If the RFC 2119 SHOULD is really the > +appropriate tool, please add some context about when it would be > +appropriate for the implementor to make a different choice than what is > +specified, and perhaps what that choice might be. (Same point applies > +to your use of RECOMMENDED.) > > KT> Updated the text to clarify in a few instances. I believe others should be clear; if not, we can discuss specifics. > > > @@ -22,7 +36,7 @@ > signaling of this reverse metric, to be used on the link to the > signaling router, allows a router to influence the amount of traffic > flowing towards itself and in certain use cases enables routers to > - maintain symmetric metric on both sides of a link between them. > + maintain symmetric metrics on both sides of a link between them. > > Status of This Memo > > @@ -88,12 +102,12 @@ > > 1. Introduction > > - Routers running the Open Shortest Path First (OSPFv2) [RFC2328] and > - OSPFv3 [RFC5340] routing protocols originate a Router-LSA (Link State > + A router running the Open Shortest Path First (OSPFv2) [RFC2328] and > + OSPFv3 [RFC5340] routing protocols originates a Router-LSA (Link-State > Advertisement) that describes all its links to its neighbors and > - includes a metric that indicates its "cost" of reaching the neighbor > + includes a metric that indicates its "cost" to reach the neighbor > over that link. Consider two routers R1 and R2 that are connected > - via a link. The metric for this link in direction R1->R2 is > + via a link. The metric for this link in the direction R1->R2 is > configured on R1 and in the direction R2->R1 is configured on R2. > Thus the configuration on R1 influences the traffic that it forwards > towards R2 but does not influence the traffic that it may receive > @@ -114,9 +128,14 @@ > Internet-Draft OSPF Reverse MetricApril 2022 > > > - results in the desired change in the traffic distribution that R1 > + may result in the desired change in the traffic distribution that R1 > wanted to achieve towards itself over the link from R2. > > +jgs: I changed "results" to "may result" because, of course, you might > +get the outcome you want by twiddling the metric and you might not. > +About the only case where you can guarantee you get the outcome you > +hoped for is when you're drying out a link by setting max-metric. No? > KT> Ack > + > This document describes extensions to OSPF Link-Local Signaling (LLS) > [RFC5613] to signal OSPF reverse metrics. Section 4 specifies the > LLS Reverse Metric TLV and Section 5 specifies the LLS Reverse TE > @@ -132,9 +151,9 @@ > > 2. Use Cases > > - This section describes certain use cases that OSPF reverse metric > + This section describes certain use cases that the OSPF reverse metric > helps address. The usage of the OSPF reverse metric need not be > - limited to these cases and is intended to be a generic mechanism. > + limited to these cases; it is intended to be a generic mechanism. > >Core Network >^^ > @@ -156,8 +175,8 @@ > >Figure 1: Reference Dual Hub and Sp
[Lsr] I-D Action: draft-ietf-lsr-ospf-reverse-metric-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : OSPF Reverse Metric Authors : Ketan Talaulikar Peter Psenak Hugh Johnston Filename: draft-ietf-lsr-ospf-reverse-metric-06.txt Pages : 13 Date: 2022-09-02 Abstract: This document specifies the extensions to OSPF that enable a router to use link-local signaling to signal the metric that receiving neighbor(s) should use for a link to the signaling router. The signaling of this reverse metric, to be used on the link to the signaling router, allows a router to influence the amount of traffic flowing towards itself and in certain use cases enables routers to maintain symmetric metrics on both sides of a link between them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-ospf-reverse-metric-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] AD review of draft-ietf-lsr-ospf-bfd-strict-mode-05
Hi John, Please check inline below for responses with KT2 On Thu, Sep 1, 2022 at 10:42 PM John Scudder wrote: > Hi Ketan, > > Thanks for the prompt update. I have one question about your edits. In > Section 6, I had suggested > > OLD: >Implementations MAY >provide a local configuration option to specifically enable BFD >operation in OSPF BFD strict-mode only. > > NEW (my suggestion): >Implementations MAY >provide a local configuration option to require BFD strict-mode. > > NEW (your revision): >Implementations MAY >provide a local configuration option to require BFD operation in OSPF >BFD strict-mode only. > > I’m wrestling with whether this option is supposed to mean “the adjacency > must not establish unless BFD comes up first” or “if the neighbor supports > BFD, then BFD must come up first before the adjacency is allowed to > establish”. KT2> I meant the former. So this is like "force" BFD strict-mode operation. The default mode is negotiation when strict-mode is enabled. > I.e., as written I can make the argument that if my neighbor doesn’t > advertise the B-bit, then it’s fine for the adjacency to come up as long as > BFD isn’t run at all. The former interpretation seems more operationally > useful, but the spec text is ambiguous. > > I’m not sure my proposed text even resolved that problem, on reflection. > In any case, I would be happier if the ambiguity were resolved somehow. > KT2> How about the following? Implementations MAY provide a local configuration option to force BFD operation only in OSPF BFD strict-mode (i.e, adjacency will not come up unless BFD session is established). > > Other comments below. > > > On Sep 1, 2022, at 11:36 AM, Ketan Talaulikar > wrote: > > [snip] > > > Status of This Memo > > @@ -92,10 +92,19 @@ > > protocols like OSPFv2 [RFC2328] and OSPFv3 [RFC5340] to detect > > connectivity failures for established adjacencies faster than the > > OSPF hello dead timer detection and trigger rerouting of traffic > > - around the failure. The use of BFD for monitoring routing protocols > > + around the failure. The use of BFD for monitoring routing protocol > > adjacencies is described in [RFC5882]. > > > > - When BFD monitoring is enabled for OSPF adjacencies, the BFD session > > +jgs: In the paragraph below, I found the flow of reading disrupted by > > +the dawning realization that it's describing the status quo prior to > > +introduction of this spec, i.e. the shortcomings that drove development > > +of the spec. I've proposed an additional first clause that might help > > +mitigate that, feel free to use it if you like. (It's a little > > +inelegant, you might want to do a more intrusive edit instead, up to > > +you.) > > > > KT> Ack. I've modified the text a little differently than your > suggestion. Please let me know if it works. > > Yes, that’s fine, thanks. > > [snip] > > > +jgs: I expect that taken as a whole, this document is clear enough to > > +enable an implementor to do the right thing, and that's the main goal. > > +It does seem to me however that "updating the state machine" by means > > +of putting a few notes into one of the states isn't the most thorough > > +way of doing it -- probably if you were doing this from the get-go you'd > > +introduce a new substate called "waiting for BFD establishment" or > > +something like that, and then transition to it from Init at the > appropriate > > +time. Or something like that, I'm just making things up on the fly > here. > > +Likewise you'd introduce a new "BFD comes up" event that gets you out of > > +your new state and back to the main flow of the state machine. Instead > > +that's encapsulated in the note you've added to Init. > > + > > +I don't want a return to the Bad Old Days where we spent months of our > > +lives wrangling over state machines in the Routing Area (if you missed > > +that time count yourself lucky). However, it would make me feel better > to > > +know that the WG has at least considered the question and decided to > move > > +ahead without doing a full update to the state machine. So, I'd > appreciate > > +a bit of discussion on this point, thanks. > > > > KT> I don't remember this discussion on the mailer. I do remember some > discussion during an initial presentation of this draft to the WG though > not sure if it was during the session or offline. The introduction of a new > state would result in far more intrusive changes to implementations. We > would have this state whether or not the strict-mode is in use (BFD itself > is optional). It was simpler to update the INIT state as proposed by the > draft instead. We've added text in the Operations section so > implementations show this additional BFD wait information along with the > adjacency state and transitions. That should help in troubleshooting and > operations. > > I’m satisfied that you’ve considered it, that the issue has been raised on > the WG list (it has now) and
Re: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02
Hi chairs, all, I strongly support WG adoption: the goal of this bis doc is clarification of an existing RFC in order to ensure (well, at least help) that we have interoperable implementations. - Clarity and interoperability is a clear goal in general, but especially in the context of FlexAlgo where this is used to compute the distributed SPF. - While we could always argue whether a clarification is needed or not, we have found different interpretation in different implementations so to me this is a proof that the previous text could be interpreted differently and hence need clarification. I've already reviewed the document, commented on it, and the authors have already updated the document. I would like to thank the authors for their willingness to do this maintenance work. As such, I would support making their effort easier (discussion and review focused on this maintenance work) Thanks, --Bruno Orange Restricted -Original Message- From: Lsr On Behalf Of Christian Hopps Sent: Monday, August 8, 2022 12:17 PM To: lsr@ietf.org Cc: cho...@chopps.org; lsr-cha...@ietf.org; lsr-...@ietf.org Subject: [Lsr] WG adoption call for draft-ginsberg-lsr-rfc8919bis-02 Hi Folks, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-ginsberg-lsr-rfc8919bis/ Please indicate your support or objections by August 22nd, 2022. Authors, please respond to the list indicating whether you are aware of any IPR that applies to these drafts. Thanks, Chris. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] [IANA #1239131] expert review for draft-ietf-lsr-isis-rfc5316bis (isis-tlv-codepoints)
Hi Sabrina, Approved from my end. Thanks, /hannes > On 01.09.2022, at 23:58, Christian Hopps wrote: > > > "Sabrina Tanamal via RT" writes: > >> Chris and Hannes (cc: lsr WG), > > > Reviewed new addition, looks OK. > > Thanks, > Chris. > >> >> As the designated experts for the Sub-TLVs for TLVs Advertising Neighbor >> Information registry, can you review the proposed registration in >> draft-ietf-lsr-isis-rfc5316bis for us? Please see >> >> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-rfc5316bis >> >> If this is OK, when the IESG approves the document for publication, we'll >> make the registration at >> >> https://www.iana.org/assignments/isis-tlv-codepoints >> >> Les Ginsberg is also an expert for this registry, but he's one of the >> authors of this document. >> >> If you're available, the due date is September 14th. >> >> thanks, >> >> Sabrina Tanamal >> Lead IANA Services Specialist > > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
