< 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]> wrote: > +Gunter and Ketan > > On Feb 17, 2025, at 07:27, Acee Lindem <[email protected]> wrote: > > Hi John, > > On Feb 16, 2025, at 8:16 PM, John Scudder via Datatracker < > [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 > > > > > > - 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. Thanks, Ketan > > Thanks, > Acee > > > > > Thanks, > Acee > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
