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