Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Hannes, Thanks for pointing this out: > On Dec 7, 2023, at 4:38 AM, Hannes Gredler > 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. I checked RFCs 8665 and 8666, and they don't exhibit the same problem. Instead of indirecting the field definition to a different subsection, they take the more usual approach of defining it in line. So, all good as far as this issue is concerned. Thanks, --John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Acee, > On Dec 7, 2023, at 3:44 PM, Acee Lindem wrote: > > 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. I went ahead and filed the erratum with the minimal language suggested by Tony. I don't think that prevents moving ahead with your suggestion also if the working group thinks it's worthwhile, but I didn't want to hold up the simple fix. --John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
John - > OLD: > 2.1.1.1. V-Flag and L-Flag > > NEW: > 2.1.1.1. V-Flag, L-Flag, and the SID/Index/Label Field > Seems reasonable to me. > Absent further discussion, I'll plan to open an editorial erratum with that > proposal; in light of the alleged waves, I will get it done by end of week, > possibly today. Since I'll be the one opening it, and since it's not > completely > uncontentious, I'll ask one of the other ADs to handle verifying or rejecting > it. > Thanx for the prompt attention. Les > -Original Message- > From: John Scudder > Sent: Thursday, December 7, 2023 1:13 PM > To: Les Ginsberg (ginsberg) > Cc: Acee Lindem ; Hannes Gredler > ; stefano.prev...@gmail.com; Clarence Filsfils (cfilsfil) > ; abashandy.i...@gmail.com; han...@rtbrick.com; > DECRAENE Bruno INNOV/NET ; > slitkows.i...@gmail.com; Jeff Tantsura ; Peter > Psenak (ppsenak) ; Horneffer, Martin > ; wim.henderi...@nokia.com; > edc.i...@gmail.com; ro...@google.com; milojevici...@gmail.com; > s...@ytti.fi; lsr > Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label > > Hi Les, > > > On Dec 7, 2023, at 4:03 PM, Les Ginsberg (ginsberg) > wrote: > > > > Let's be careful here. > > Certainly. I don't think we've been proceeding recklessly so far, have we? > > > 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 > > ^ until now > > > 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. > > It's not the direction I had been thinking in, but Tony Li got there first and > suggested [1] a change that I think would get the job done. It has the merit > of > being a minimal update to the published text. The change would be, > > OLD: > 2.1.1.1. V-Flag and L-Flag > > NEW: > 2.1.1.1. V-Flag, L-Flag, and the SID/Index/Label Field > > Absent further discussion, I'll plan to open an editorial erratum with that > proposal; in light of the alleged waves, I will get it done by end of week, > possibly today. Since I'll be the one opening it, and since it's not > completely > uncontentious, I'll ask one of the other ADs to handle verifying or rejecting > it. > > —John > > [1] https://mailarchive.ietf.org/arch/msg/lsr/xIBSCGENJAuPHquywuPvt- > oItIE/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Les, > On Dec 7, 2023, at 4:03 PM, Les Ginsberg (ginsberg) > wrote: > > Let's be careful here. Certainly. I don't think we've been proceeding recklessly so far, have we? > 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 ^ until now > 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. It's not the direction I had been thinking in, but Tony Li got there first and suggested [1] a change that I think would get the job done. It has the merit of being a minimal update to the published text. The change would be, OLD: 2.1.1.1. V-Flag and L-Flag NEW: 2.1.1.1. V-Flag, L-Flag, and the SID/Index/Label Field Absent further discussion, I'll plan to open an editorial erratum with that proposal; in light of the alleged waves, I will get it done by end of week, possibly today. Since I'll be the one opening it, and since it's not completely uncontentious, I'll ask one of the other ADs to handle verifying or rejecting it. —John [1] https://mailarchive.ietf.org/arch/msg/lsr/xIBSCGENJAuPHquywuPvt-oItIE/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Les, > On Dec 7, 2023, at 16:03, Les Ginsberg (ginsberg) wrote: > > 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. Certainly no encoding change is being suggested - just a better clearer definition of the relationship between the L flag, V flag, TLV length, and TLV values (label, index, value). Thanks, Acee > > Thanx. > >Les > > > > -Original Message- > > From: Acee Lindem mailto:acee.i...@gmail.com>> > > Sent: Thursday, December 7, 2023 12:44 PM > > To: John Scudder > <mailto:jgs=40juniper@dmarc.ietf.org>> > > Cc: Hannes Gredler > <mailto:hannes=40gredler...@dmarc.ietf.org>>; > > stefano.prev...@gmail.com <mailto:stefano.prev...@gmail.com>; Les Ginsberg > > (ginsberg) mailto:ginsb...@cisco.com>>; > > Clarence Filsfils (cfilsfil) > <mailto:cfils...@cisco.com>>; abashandy.i...@gmail.com > > <mailto:abashandy.i...@gmail.com>; > > han...@rtbrick.com <mailto:han...@rtbrick.com>; DECRAENE Bruno INNOV/NET > > mailto:bruno.decra...@orange.com>>; > > slitkows.i...@gmail.com <mailto:slitkows.i...@gmail.com>; Jeff Tantsura > > mailto:jefftant.i...@gmail.com>>; Peter Psenak > > (ppsenak) mailto:ppse...@cisco.com>>; > > Horneffer, Martin > <mailto:martin.hornef...@telekom.de>>; > > wim.henderi...@nokia.com <mailto:wim.henderi...@nokia.com>; > > edc.i...@gmail.com <mailto:edc.i...@gmail.com>; ro...@google.com > > <mailto:ro...@google.com>; > > milojevici...@gmail.com <mailto:milojevici...@gmail.com>; s...@ytti.fi > > <mailto:s...@ytti.fi>; lsr mailto: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 > > <mailto:jgs=40juniper@dmarc.ietf.org>> > > wrote: > > > > > > Hi Hannes, > > > > > >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler > > > <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 so
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
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 > Sent: Thursday, December 7, 2023 12:44 PM > To: John Scudder > Cc: Hannes Gredler ; > stefano.prev...@gmail.com; Les Ginsberg (ginsberg) ; > Clarence Filsfils (cfilsfil) ; abashandy.i...@gmail.com; > han...@rtbrick.com; DECRAENE Bruno INNOV/NET > ; slitkows.i...@gmail.com; Jeff Tantsura > ; Peter Psenak (ppsenak) ; > Horneffer, Martin ; > wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com; > milojevici...@gmail.com; s...@ytti.fi; lsr > Subject: Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label > > Hi John, > > > On Dec 7, 2023, at 12:22, John Scudder > > mailto:jgs=40juniper@dmarc.ietf.org>> > wrote: > > > > Hi Hannes, > > > >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler > 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
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi John, > On Dec 7, 2023, at 12:22, John Scudder > wrote: > > Hi Hannes, > >> On Dec 7, 2023, at 4:38 AM, Hannes Gredler >> 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-of-leopard-douglas-adams-quote.html > > [2] https://www.rfc-editor.org/errata-definitions/ > ___ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Hannes, > On Dec 7, 2023, at 4:38 AM, Hannes Gredler > 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. 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-of-leopard-douglas-adams-quote.html [2] https://www.rfc-editor.org/errata-definitions/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi John, Section 2.1 defines also the bits to be used in the flags field: where: [ ... ] V-Flag: Value Flag. If set, then the Prefix-SID carries a value (instead of an index). By default, the flag is UNSET. L-Flag: Local Flag. If set, then the value/index carried by the Prefix-SID has local significance. By default, the flag is UNSET. [ ... ] When the Prefix-SID is an index (and the V-Flag is not set), the value is used to determine the actual label value inside the set of all advertised label ranges of a given router. This allows a receiving router to construct the forwarding state to a particular destination router. -- We have used similar textblocks for the OSPFv2 and OSPFv3 SR extensions and I am not aware of any questions from implementators around ambiguity. 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. /hannes On Wed, Dec 06, 2023 at 09:13:15PM +, John Scudder wrote: | Hi Authors and Contributors who "should be considered as coauthors”, | | Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier (Prefix-SID) Sub-TLV, in Section 2.1, as: | | SID/Index/Label as defined in Section 2.1.1.1. | | But when I look at Section 2.1.1.1 I see that it defines "V-Flag and L-Flag”, not SID/Index/Label at all. It relates to the interpretation of SID/Index/Label, yes, but it doesn’t define the field. | | It seems as though an erratum is needed to provide a useful definition. I don’t have text to suggest. Can one of you suggest text, and either raise the erratum yourself, or if you send text, I can raise it? Alternatively, if you can help me understand how section 2.1.1.1 actually does define this field, I'm all ears. | | Thanks, | | --John | ___ | Lsr mailing list | Lsr@ietf.org | https://www.ietf.org/mailman/listinfo/lsr ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Les, Thanks for the speedy reply, and I take your point. I do still think an erratum is called for, but I think it's editorial or "hold for document update", not technical. Now that you've applied the clue bat I think I can compose one. I'll do so by and by and you can see what you think. --John > On Dec 6, 2023, at 4:25 PM, Les Ginsberg (ginsberg) > wrote: > > > John - > > The meaningful bits of the SID and the size (number of octets) depend upon > the flags. As Section 2.1.1.1 states (emphasis added): > > The following settings for V-Flag and L-Flag are valid: > > The V-Flag and L-Flag are set to 0: > The SID/Index/Label field is a 4-octet index defining the offset in the > SID/Label space advertised by this router using the encodings defined in > Section 3.1. > > The V-Flag and L-Flag are set to 1: > The SID/Index/Label field is a 3-octet local label where the 20 rightmost > bits are used for encoding the label value. > > Do you still believe some change/clarification is needed? > >Les > > > -Original Message- > > From: John Scudder > > Sent: Wednesday, December 6, 2023 1:13 PM > > To: stefano.prev...@gmail.com; Les Ginsberg (ginsberg) > > ; Clarence Filsfils (cfilsfil) ; > > abashandy.i...@gmail.com; han...@rtbrick.com; DECRAENE Bruno > > INNOV/NET ; slitkows.i...@gmail.com; Jeff > > Tantsura ; Peter Psenak (ppsenak) > > ; Horneffer, Martin ; > > wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com; > > milojevici...@gmail.com; s...@ytti.fi > > Cc: lsr > > Subject: Bug in RFC 8667 definition of SID/Index/Label > > > > Hi Authors and Contributors who "should be considered as coauthors”, > > > > Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier > > (Prefix-SID) Sub-TLV, in Section 2.1, as: > > > > SID/Index/Label as defined in Section 2.1.1.1. > > > > But when I look at Section 2.1.1.1 I see that it defines "V-Flag and > > L-Flag”, not > > SID/Index/Label at all. It relates to the interpretation of > > SID/Index/Label, yes, > > but it doesn’t define the field. > > > > It seems as though an erratum is needed to provide a useful definition. I > > don’t > > have text to suggest. Can one of you suggest text, and either raise the > > erratum > > yourself, or if you send text, I can raise it? Alternatively, if you can > > help me > > understand how section 2.1.1.1 actually does define this field, I'm all > > ears. > > > > Thanks, > > > > --John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Bug in RFC 8667 definition of SID/Index/Label
John - The meaningful bits of the SID and the size (number of octets) depend upon the flags. As Section 2.1.1.1 states (emphasis added): The following settings for V-Flag and L-Flag are valid: The V-Flag and L-Flag are set to 0: The SID/Index/Label field is a 4-octet index defining the offset in the SID/Label space advertised by this router using the encodings defined in Section 3.1. The V-Flag and L-Flag are set to 1: The SID/Index/Label field is a 3-octet local label where the 20 rightmost bits are used for encoding the label value. Do you still believe some change/clarification is needed? Les > -Original Message- > From: John Scudder > Sent: Wednesday, December 6, 2023 1:13 PM > To: stefano.prev...@gmail.com; Les Ginsberg (ginsberg) > ; Clarence Filsfils (cfilsfil) ; > abashandy.i...@gmail.com; han...@rtbrick.com; DECRAENE Bruno > INNOV/NET ; slitkows.i...@gmail.com; Jeff > Tantsura ; Peter Psenak (ppsenak) > ; Horneffer, Martin ; > wim.henderi...@nokia.com; edc.i...@gmail.com; ro...@google.com; > milojevici...@gmail.com; s...@ytti.fi > Cc: lsr > Subject: Bug in RFC 8667 definition of SID/Index/Label > > Hi Authors and Contributors who "should be considered as coauthors”, > > Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier > (Prefix-SID) Sub-TLV, in Section 2.1, as: > > SID/Index/Label as defined in Section 2.1.1.1. > > But when I look at Section 2.1.1.1 I see that it defines "V-Flag and L-Flag”, > not > SID/Index/Label at all. It relates to the interpretation of SID/Index/Label, > yes, > but it doesn’t define the field. > > It seems as though an erratum is needed to provide a useful definition. I > don’t > have text to suggest. Can one of you suggest text, and either raise the > erratum > yourself, or if you send text, I can raise it? Alternatively, if you can help > me > understand how section 2.1.1.1 actually does define this field, I'm all ears. > > Thanks, > > --John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Bug in RFC 8667 definition of SID/Index/Label
Hi Authors and Contributors who "should be considered as coauthors”, Your RFC defines the SID/Index/Label field of the Prefix Segment Identifier (Prefix-SID) Sub-TLV, in Section 2.1, as: SID/Index/Label as defined in Section 2.1.1.1. But when I look at Section 2.1.1.1 I see that it defines "V-Flag and L-Flag”, not SID/Index/Label at all. It relates to the interpretation of SID/Index/Label, yes, but it doesn’t define the field. It seems as though an erratum is needed to provide a useful definition. I don’t have text to suggest. Can one of you suggest text, and either raise the erratum yourself, or if you send text, I can raise it? Alternatively, if you can help me understand how section 2.1.1.1 actually does define this field, I'm all ears. Thanks, --John ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
