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. > > - 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. > > - 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. Thanks, Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
