Good point. Thanks. Joel
On 11/28/2025 6:44 PM, Acee Lindem wrote:
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]
