> On Feb 17, 2025, at 09:05, Ketan Talaulikar <[email protected]> wrote: > > < 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
Yes - I mistakenly looked at another “MAY” in the document. For this limiting application usage, I agree and will change to “may”. > >> >> >>> >>> >>>> >>>> - 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. In any case, I think that if we were to deprecate usage solely for the OSPFv3 Extended LSA case, it would require a separate document. I’m going to leave this as a “MUST”. Thanks, Acee > > Thanks, > Ketan > >> >> Thanks, >> Acee >> >> >> >>> >>> Thanks, >>> Acee >>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
