Hi Joel, If you do this, don't forget RFC 9513 - https://datatracker.ietf.org/doc/rfc9513/
Thanks, Acee > On Nov 28, 2025, at 4:24 PM, Joel Halpern <[email protected]> wrote: > > If the AD and LSR chairs agree that an erratum is acceptable for this, I > would be happy to file one. My concern is that this does not appear to be an > error in the RFC, but rather an evolution in the outside conditions. > > Yours, > > Joel > > On 11/28/2025 4:12 PM, Zafar Ali (zali) wrote: >> Hi Joel, >> >> RFC9800 specifies: "CSID container: A 128-bit IPv6 address that functions >> as a container holding a list of one or more CSIDs and the Argument (if any) >> of the last CSID." >> You are right that as RFC9352 pre-dates RFC9800, it counts the 128-bit >> segment list entries in SRH in the MSD types. >> The clarification needed is along the line that “maximum number of SIDs” in >> RFC9352 means “maximum number of 128-bit segment list entries" >> IMO, such clarification can happen via a RFC9352 Errata. >> >> Thanks >> >> Regards … Zafar >> >> >> On 11/27/25, 6:08 AM, "Vasilenko Eduard" >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> 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 >>> <[email protected] >>> <mailto:[email protected]>> >>> Sent: Thursday, November 27, 2025 13:40 >>> To: Joel Halpern <[email protected] <mailto:[email protected]>>; lsr >>> <[email protected] <mailto:[email protected]>> >>> Cc: Giuseppe Fioccola <[email protected] >>> <mailto:[email protected]>>; Paolo Volpato >>> <[email protected] <mailto:[email protected]>>; Bruno Decraene >>> <[email protected] <mailto:[email protected]>>; Vasilenko >>> Eduard >>> <[email protected] <mailto:[email protected]>> >>> 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 >>> >> Cisco Confidential >>> -----Mensaje original----- >>> De: Joel Halpern <[email protected] <mailto:[email protected]>> >>> Enviado el: jueves, 27 de noviembre de 2025 11:07 >>> Para: lsr <[email protected] <mailto:[email protected]>> >>> 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 -- [email protected] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >>> >>> ________________________________ >>> >>> 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 -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> >> >> >> > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
