Folks -
Let's be careful here. SR-MPLS has been deployed for several years, there are multiple implementations which have demonstrated interoperability, and clearly the correct encoding of the SID is a key element of that interoperability. As a co-author, I am happy to listen to relevant feedback, but any textual change which has the potential to even suggest that an actual change has been made in encoding is clearly undesirable. John - I note you have already acknowledged any errata (or erratum š) would be an editorial one - but given the above context and the fact that no one over these many years has publicly voiced any concerns argues for caution. I am sure you have more pressing issues, but as your post has already started to cause waves, I would appreciate resolving this sooner rather than later. Thanx. Les > -----Original Message----- > From: Acee Lindem <[email protected]> > Sent: Thursday, December 7, 2023 12:44 PM > To: John Scudder <[email protected]> > Cc: Hannes Gredler <[email protected]>; > [email protected]; Les Ginsberg (ginsberg) <[email protected]>; > Clarence Filsfils (cfilsfil) <[email protected]>; [email protected]; > [email protected]; DECRAENE Bruno INNOV/NET > <[email protected]>; [email protected]; Jeff Tantsura > <[email protected]>; Peter Psenak (ppsenak) <[email protected]>; > Horneffer, Martin <[email protected]>; > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; lsr <[email protected]> > Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label > > Hi John, > > > On Dec 7, 2023, at 12:22, John Scudder > > <[email protected]<mailto:[email protected]>> > wrote: > > > > Hi Hannes, > > > >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler > <[email protected]<mailto:[email protected]>> > wrote: > >> > >> We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions > and I am not aware > >> of any questions from implementators around ambiguity. > > > > Thanks for the pointer, Iāll take a look at those, too. > > > >> IMO there is clear enough language to describe proper encoding of the > prefix-SID subTLV and > >> I am not sure why an "erratum" is required. > > > > I agree that, after reconsidering the text in light of Lesās reply, itās > > not a > technical error (or ābugā as I put it in the subject line). However, offline > feedback from a couple of other experienced protocol implementors indicates > to me that Iām not the only one who finds the presentation of the information > to be unclear [1] and not as helpful as it could be to someone using the > document as a reference instead of doing an in-depth read-through. > > Weāll probably never BIS these RFCs but I would agree that it would be good > for one of the RFC authors to provide a clearer definition of the relationship > between the L flag, V flag, TLV length, and TLV values (label, index, value). > Since it seems a single flag indicating whether the value is an MPLS label or > index into an MPLS label range would have sufficed, this description would > certainly be beneficial to those new to IGP segment routing. Also, it is > unclear > why an index/value ever needs to be 4 octets when the value is bounded by > the MPLS label space itself. > > Thanks, > Acee > > > > > > BTW if thereās some nuance to the quotation marks you used around > āerratumā Iām missing it. Errata are a normal part of our process, and erratum > is just the singular of errata. [2] > > > > Thanks, > > > > āJohn > > > > [1] This quote doesnāt quite apply, but itās a humorous way of illustrating > that information can be provided without being made available as clearly as it > could be. > http://hitchhikerguidetothegalaxy.blogspot.com/2006/04/beware-<http://hitchhikerguidetothegalaxy.blogspot.com/2006/04/beware-of-leopard-douglas-adams-quote.html> > of-leopard-douglas-adams-quote.html<http://hitchhikerguidetothegalaxy.blogspot.com/2006/04/beware-of-leopard-douglas-adams-quote.html> > > > > [2] https://www.rfc-editor.org/errata-definitions/ > > _______________________________________________ > > Lsr mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
