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 <acee.i...@gmail.com> > Sent: Thursday, December 7, 2023 12:44 PM > To: John Scudder <jgs=40juniper....@dmarc.ietf.org> > Cc: Hannes Gredler <hannes=40gredler...@dmarc.ietf.org>; > stefano.prev...@gmail.com; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; > Clarence Filsfils (cfilsfil) <cfils...@cisco.com>; abashandy.i...@gmail.com; > han...@rtbrick.com; DECRAENE Bruno INNOV/NET > <bruno.decra...@orange.com>; slitkows.i...@gmail.com; Jeff Tantsura > <jefftant.i...@gmail.com>; Peter Psenak (ppsenak) <ppse...@cisco.com>; > Horneffer, Martin <martin.hornef...@telekom.de>; > wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com; > milojevici...@gmail.com; s...@ytti.fi; lsr <lsr@ietf.org> > Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label > > Hi John, > > > On Dec 7, 2023, at 12:22, John Scudder > > <jgs=40juniper....@dmarc.ietf.org<mailto:jgs=40juniper....@dmarc.ietf.org>> > wrote: > > > > Hi Hannes, > > > >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler > <hannes=40gredler...@dmarc.ietf.org<mailto:hannes=40gredler...@dmarc.ietf.org>> > 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 > > Lsr@ietf.org<mailto:Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr