Inline: GV> From: Ketan Talaulikar <[email protected]> Sent: Monday, February 17, 2025 9:05 PM To: Acee Lindem <[email protected]> Cc: John Scudder <[email protected]>; Gunter van de Velde (Nokia) <[email protected]>; The IESG <[email protected]>; [email protected]; lsr-chairs <[email protected]>; lsr <[email protected]>; Christian Hopps <[email protected]> Subject: Re: John Scudder's No Objection on draft-ietf-lsr-ospf-admin-tags-26: (with COMMENT)
CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. < as a LSR WG member > Hi Acee/All, Please check inline below. On Mon, Feb 17, 2025 at 7:16 PM Acee Lindem <[email protected]<mailto:[email protected]>> wrote: +Gunter and Ketan On Feb 17, 2025, at 07:27, Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Hi John, On Feb 16, 2025, at 8:16 PM, John Scudder via Datatracker <[email protected]<mailto:[email protected]>> wrote: John Scudder has entered the following ballot position for draft-ietf-lsr-ospf-admin-tags-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document. I have just a few questions and comments, below. - In Section 4, "An OSPF router supporting this specification MAY be able to advertise and propagate multiple tags." Does "propagate" have some well-known meaning in OSPF that is different from "flood"? Because I assume that any OSPF router MUST flood (propagate!) whatever it's given. (I do see paragraph 4, which hints that the answer is "yes in OSPF 'propagate' always means 'between areas'" but I'd appreciate a confirmation.) Yes. This is the meaning of "propagate" in this context. I can clarify this on the first usage of “propagate”. - specification MAY be able to advertise and propagate multiple tags. The + specification MAY be able to advertise prefixes with multiple tags and propagate prefixes + with multiple tags between areas. The - In Section 4, "Depending on the application, the number of tags supported by the OSPF routers in the OSPF routing domain MAY limit deployment of that application." That seems like a misuse of RFC 2119 MAY -- aren't you just stating a possibility, not giving permission for an implementation choice? I don't feel strongly. The statement is simply to indicate that an implementation can support multiple tags but limit the number supported. I’d like to hear get Gunter’s and Ketan’s opinion as whether to change this from “MAY” to “may”. KT> The use of "may" seems appropriate to me GV> It is indeed more a narrative then describing a formal procedure. However, I do not feel it was bluntly wrong. GV> it seems a tiny detail and using in this case “may” instead of “MAY” seems appropriate. - In Section 4, "When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings MUST be utilized for the first tag." I almost never do this, but... couldn't this be a SHOULD? The case I can think of where you might want to use the Administrative Tag Sub-TLV even as the first tag, is in some future time when Administrative Tag Sub-TLV is ubiquitous and you are looking toward deprecating the old encoding. I suppose a new RFC could be written at that time, to permit the variance, but why not just allow it here with a SHOULD? The thinking here was that we'd always support the existing support for a single AS-External tag in OSPFv2 and OSPFv3 encodings The motivation just isn't that strong since in order to get to ubiquitous deployment, implementations would need to support the existing tag advertisement. Also, like to get Gunter’s and Ketan’s opinion here. Again, I don’t think it would be worth the pain to ever require implementations to support the new encoding for the existing tag. KT> This text is referring to the usage of the base LSAs for both OSPFv2 and v3 - as long as they are used (no option for v2, but there is a possibility for v3 - see further) then for me the MUST in the current text is the right approach for backward compatibility. Now, in OSPFv2, there is no proposal to get rid of the based fixed LSAs - so it doesn't make sense to deprecate the tag field in them. In OSPFv3, we have the base and then the extended LSAs (RFC8362) - there is a path to switch OSPFv3 completely to the use of the extended LSAs and stop using the base LSAs. In that E-LSA only case, for OSPFv3 we will have the Route Tag sub-TLV for a single tag and this new sub-TLV for multiple tags. So, for OSPFv3 we will have 3 ways. One can argue for the deprecation of the Route Tag sub-TLV - but I am aware of implementations. This is anyway orthogonal to the text blob that we are discussing. GV> Using "SHOULD" gives implementers the flexibility to defer this requirement while still remaining compliant with the RFC-to-be, even though it would likely lead to interop issues. GV> I’d prefer to make the current spec as strong as possible from an interop perspective right from the start. We can always revisit and refine this assumption later if a real-world use case emerges. GV> I agree with Acee about this and I’m also doubtful this scenario will ever materialize. Thanks, Ketan Thanks, Acee Thanks, Acee
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
