And update the OSPF RFC as well presumably. (Assuming all the relevant
chairs agree with this path. It works for me.)
Yours,
Joel
On 12/1/2025 6:17 AM, Adrian Farrel wrote:
So to build on the suggestions here, my proposal is:
* Make draft-ietf-6man-sidlist-clarification also Update RFC9352
* Add a new section to draft-ietf-6man-sidlist-clarification to
contain the necessary clarification
* Include text to say that there is no change to the processing or
encoding of RFC9352
This is contingent on:
1. This WG (LSR) agreeing that it is OK to have the Update done in 6man
2. 6MAN agreeing that it is OK to expand the scope of
draft-ietf-6man-sidlist-clarification
3. 6MAN chairs agreeing to share any last call with LSR
4. The editors of draft-ietf-6man-sidlist-clarification (Suresh and
me) doing the work
First step: LSR chairs, please get an answer to point 1.
Second step: I will talk to 6MAN for points 2 and 3.
Third step: The editors will propose text and share it with this list.
Yes?
Adrian
*From:*Tony Li <[email protected]> *On Behalf Of *Tony Li
*Sent:* 01 December 2025 06:59
*To:* Zafar Ali (zali) <[email protected]>
*Cc:* Adrian Farrel <[email protected]>; Vasilenko Eduard
<[email protected]>; LUIS MIGUEL CONTRERAS
MURILLO <[email protected]>; Joel M. Halpern
<[email protected]>; lsr <[email protected]>; Giuseppe Fioccola
<[email protected]>; Paolo Volpato
<[email protected]>; Bruno Decraene
<[email protected]>; Zafar Ali (zali) <[email protected]>
*Subject:* Re: [Lsr] Where to clarify RFC 9352 relative to SID containers
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 <[email protected]> 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" <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>> 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
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>
Sent: 27 November 2025 11:08
To: LUIS MIGUEL CONTRERAS MURILLO
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>; Joel
Halpern <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>; lsr <[email protected]
<mailto:[email protected]><mailto:[email protected] <mailto:[email protected]>>>
Cc: Giuseppe Fioccola <[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>; Paolo Volpato
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>; Bruno Decraene
<[email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>>
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
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>
Sent: Thursday, November 27, 2025 13:40
To: Joel Halpern
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>; lsr
<[email protected]<mailto:[email protected] <mailto:[email protected]>>>
Cc: Giuseppe Fioccola
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>; Paolo Volpato
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>; Bruno Decraene
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>; Vasilenko Eduard
<[email protected]<mailto:[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
-----Mensaje original-----
De: Joel Halpern
<[email protected]<mailto:[email protected]
<mailto:[email protected]>>>
Enviado el: jueves, 27 de noviembre de 2025 11:07
Para: lsr <[email protected]<mailto:[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]
<mailto:[email protected]>>
To unsubscribe send an email
[email protected]<mailto:[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]><mailto:[email protected] <mailto:[email protected]>>
To unsubscribe send an email [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
_______________________________________________
Lsr mailing list [email protected]
<mailto:[email protected]><mailto:[email protected] <mailto:[email protected]>>
To unsubscribe send an email [email protected]
<mailto:[email protected]><mailto:[email protected]
<mailto:[email protected]>>
_______________________________________________
Lsr mailing list [email protected] <mailto:[email protected]>
To unsubscribe send an email [email protected]
<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
