[Lsr] Re: Where to clarify RFC 9352 relative to SID containers

[Acee Lindem <[e-mail]>]

I agree with Yingzhen on both counts - that the compressed SID enhancements should not be
documented in an Errata and that the augmentations to the IS-IS and OSPFv3 encodings can
be documented in the 6MAN document including the compressed SID semantics that LSR reviews. 

Thanks,
Acee

> On Dec 4, 2025, at 1:25 PM, Yingzhen Qu <[e-mail]> wrote:
> 
> I don't think this should be filed as an errata. The document was correct when published. People implementing RFC 9352 understand that "number of SIDs" means "number of 128 bits" and would not confuse it with the number of SIDs that include compressed SIDs. 
> 
> I prefer Adrian's suggestion, clarifying this in draft-ietf-6man-sidlist-clarification. Otherwise we should handle this in a -bis document.
> 
> Thanks,
> Yingzhen
> 
> On Thu, Dec 4, 2025 at 1:54 AM Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail]> wrote:
> Apologies for the late response. The note got filtered into a an unsuspected folder.
> 
> There is an IESG statement about processing errata:  
> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
> 
> This statement advises that the rules are strong guidelines, not immutable rules.  
> 
> The first rule says:
> "
>     • Errata are items that were errors at the time the document was published -- things that were missed during the last call, approval, and publication process. If new information, new capabilities, or new thinking has come up since publication, or if you disagree with the content of the RFC, that is not material for an errata report. Such items are better brought to relevant working groups, technical area discussions, or the IESG.
> " 
> 
> Looking at this rule, it appears that the observation (SID not always 128 bits after RFC 9800) is not really an errata, but rather a consequence of the updated SID size flexibility introduced by RFC 9800. 
> 
> The errata rule is not immutable, and the changes required to correct rfc9352 are obvious. Hence, if the WG agrees to resolve this via an errata, I’ll process it as a technical erratum. If not, it should be handled in a -bis document. Let’s make sure the WG have clear consensus on the list first.
> 
> G/  
> 
> 
> From: Joel Halpern <[e-mail]>
> Sent: Tuesday, December 02, 2025 11:05 PM
> To: Gunter van de Velde (Nokia) <[e-mail]>
> Cc: Adrian Farrel <[e-mail]>; lsr <[e-mail]>; Tony Li <[e-mail]>; Ketan Talaulikar <[e-mail]>; James Guichard <[e-mail]>
> Subject: Re: [Lsr] Re: Where to clarify RFC 9352 relative to SID containers 
> 
>   CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>  
> As far as I can tell, Gunther is the responsible AD.  As such, Gunther, do you agree that this should be handled as a pair of errata?  And if so, do you want me to file them?
> Yours,
> Joel
> On 12/2/2025 9:09 AM, Joel Halpern wrote:
> Those changes are the clarification I am asking for.
> Yours,
> Joel
> On 12/2/2025 6:51 AM, Ketan Talaulikar wrote:
> < only as co-author of RFC9513 and contributor to RFC9352 > 
> 
> Hi All,
> 
> I believe a technical errata on these documents is appropriate and a bis is not necessary.
> 
> As Adrian notes, "number of SIDs in SRH" and "number of segments in SRH" were used interchangeably in some places in documents that were published before CSID RFC9800. I see a technical error with this mix up in the MSD context since RFC8754 that specified the SRH talks about Segments in the SRH and Segment List in the SRH.
> 
> Now, the MSD types in question are all referring to SRH (refer https://www.rfc-editor.org/rfc/rfc9352.html#section-4 and https://www.rfc-editor.org/rfc/rfc9513.html#section-4) and so the errata would be something like below:
> - Maximum Segments Left MSD Type (no errata needed)
> - Maximum End Pop MSD Type : s/number of SIDs in the SRH/number of Segments in the SRH
> - Maximum H.Encaps MSD Type: s/number of SIDs that can be added to the segment list of an SRH/number of Segments that can be added to the segment list of an SRH .... and also s/SRH up to the advertised number of SIDs/SRH up to the advertised number of Segments
> - Maximum End D MSD Type: s/number of SIDs present in an SRH/number of Segments present in an SRH
> 
> The actual "update" and clarifications to "Segments Left" and "Segment List" are already being done in draft-ietf-6man-sidlist-clarification and applied to RFC8754 which is the base that these OSPF and ISIS specs are referencing. Therefore, I don't see the need for a bis for the LSR specs.
> 
> Joel, have I understood your point correctly?
> 
> Just my view ...
> 
> Thanks,
> Ketan
> 
> 
> On Mon, Dec 1, 2025 at 12:29 PM Tony Li <[e-mail]> wrote:
> 
> Hi all, 
> 
> IMHO, this is not an appropriate use of the Errata mechanism.  The intent of that mechanism is to report technical and editorial errors in the document.
> 
> In this case, we’re talking about extending the text (albeit in an obvious way) to cover the case of a compressed segment list.  This deserves to be in a separate document and have WG scrutiny.  It would not be inappropriate to consider a 9352bis.
> 
> Regards,
> T
> 
> 
> On Nov 30, 2025, at 7:11 PM, Zafar Ali (zali) - zali=40cisco.com at dmarc.ietf.org <[e-mail]> wrote:
> 
> Hi Adrian, Joel, WG,
> 
> I agree with Adrain, "that in 9352, MSD should be interpreted to mean the maximum number of 128-bit entries in the Segment list, and not the number of SIDs represented". Depending on AD/ chairs preference, a clarification along these lines can be made in draft-ietf-6man-sidlist-clarification or as an RFC9352 Errata.
> 
> Thanks
> 
> Regards … Zafar
> 
> 
> On 11/30/25, 5:54 AM, "Adrian Farrel" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Hi,
> 
> 
> Coming to this thread late a wilfully jumping in half way through.
> 
> 
> Can I point you to draft-ietf-6man-sidlist-clarification?
> 
> 
> The problem identified there is that there was originally some "wooliness" with regard to terminology in 8754.
> - Both "SID list" and "Segment list" are used.
> - There is an implication (which, certainly, no longer applies) that entries in the Segment list are 128 bit IPv6 addresses.
> This is no attack on the authors (we were all in the room when the text was agreed) and the clarification doesn't change the technology one iota.
> 
> 
> I think that 9352 carried on this slight fuzziness. Again, no attack on the authors or the technology - we all reviewed the text.
> I would agree that in 9352, MSD should be interpreted to mean the maximum number of 128-bit entries in the Segment list, and not the number of SIDs represented.
> 
> 
> Cheers,
> Adrian
> 
> 
> 
> Cisco Confidential
> -----Original Message-----
> From: Vasilenko Eduard <vasilenko.eduard=[e-mail] <mailto:[e-mail]>>
> Sent: 27 November 2025 11:08
> To: LUIS MIGUEL CONTRERAS MURILLO <[e-mail] <mailto:[e-mail]>>; Joel Halpern <[e-mail] <mailto:[e-mail]>>; lsr <[e-mail] <mailto:[e-mail]>>
> Cc: Giuseppe Fioccola <[e-mail] <mailto:[e-mail]>>; Paolo Volpato <[e-mail]<mailto:[e-mail]>>; Bruno Decraene <[e-mail] <mailto:[e-mail]>>
> Subject: [Lsr] Re: Where to clarify RFC 9352 relative to SID containers
> 
> 
> Hi all,
> Pay attention that RFC 9532 is the normative document, all documents in BMWG are informative.
> 
> 
> I am not sure I have understood the context. I do not see the problem.
> Compressed SID is the "SID" too.
> 128bit entry inside the SRH is called "Segment List" in the RFC 8754.
> Hence, no problems because names are different.
> Eduard
> -----Original Message-----
> From: LUIS MIGUEL CONTRERAS MURILLO
> <[e-mail] <mailto:[e-mail]>>
> Sent: Thursday, November 27, 2025 13:40
> To: Joel Halpern <[e-mail] <mailto:[e-mail]>>; lsr <[e-mail] <mailto:[e-mail]>>
> Cc: Giuseppe Fioccola <[e-mail] <mailto:[e-mail]>>; Paolo Volpato
> <[e-mail] <mailto:[e-mail]>>; Bruno Decraene
> <[e-mail] <mailto:[e-mail]>>; Vasilenko Eduard
> <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [Lsr] Where to clarify RFC 9352 relative to SID containers
> 
> Hi Joel,
> 
> Not sure if this would be what you are looking for (especially because is an
> outcome of BMWG and not LSR), but draft-ietf-bmwg-sr-bench-meth includes
> proposal of segment list scale testing that could serve for the purpose you
> comment (that is, adding maximum number of 128 bit pieces as an aspect to
> be considered during the benchmarking process). So maybe the point that you
> raise can be included here.
> 
> I copy my co-authors in case they want to complement with additional
> comments.
> 
> Best regards
> 
> Luis
> 
> -----Mensaje original-----
> De: Joel Halpern <[e-mail] <mailto:[e-mail]>>
> Enviado el: jueves, 27 de noviembre de 2025 11:07
> Para: lsr <[e-mail] <mailto:[e-mail]>>
> Asunto: [Lsr] Where to clarify RFC 9352 relative to SID containers
> 
> AVISO/WARNING: Este correo electrónico se originó desde fuera de la
> organización. No haga clic en enlaces ni abra archivos adjuntos a menos que
> reconozca al remitente y sepa que el contenido es seguro / This email has
> been originated from outside of the organization. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
> 
> 
> First, to be clear, what I am describing is NOT an error in RFC 9352.
> Thus, I don't think an erratum is the appropriate way to document for future
> readers this additional aspect of the intent of certain maximum segment depth
> advertisements for SRv6.
> 
> RFC 9352 talks about the maximum number of SIDs. However, when SIDs are
> carried in compressed SID containers, the number that matters for some
> (maybe all?) of the maximum segment depths is the number of 128 bit
> pieces, not the number of SIDs. Apparently, several implementations
> are consistent with that. It seems a bit odd to write another RFC just to say
> that. Is there some document in process that could sensibly capture this.
> 
> (As RFC 9352 predates the Compressed SID RFC it makes sense that this case is
> not disucssed there.)
> 
> Yours,
> 
> Joel
> 
> _______________________________________________
> Lsr mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> ________________________________
> 
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso exclusivo
> de la persona o entidad de destino. Si no es usted. el destinatario indicado,
> queda notificado de que la lectura, utilización, divulgación y/o copia sin
> autorización puede estar prohibida en virtud de la legislación vigente. Si ha
> recibido este mensaje por error, le rogamos que nos lo comunique
> inmediatamente por esta misma vía y proceda a su destrucción.
> 
> The information contained in this transmission is confidential and privileged
> information intended only for the use of the individual or entity named above.
> If the reader of this message is not the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this communication
> is strictly prohibited. If you have received this transmission in error, do not
> read it. Please immediately reply to the sender that you have received this
> communication in error and then delete it.
> 
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo da
> pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem
> autorização pode estar proibida em virtude da legislação vigente. Se recebeu
> esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente
> por esta mesma via e proceda a sua destruição
> _______________________________________________
> Lsr mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> _______________________________________________
> Lsr mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> 
> 
> 
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> 
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> _______________________________________________
> Lsr mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]