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

[Joel Halpern]

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 <tony...@tony.li> 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
    <http://40cisco.com> at dmarc.ietf.org <http://dmarc.ietf.org>
    <mailforwa...@cloudmails.net> 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"
    <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk
    <mailto:adr...@olddog.co.uk>>> 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=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org
    <mailto:40huawei....@dmarc.ietf.org>>>
    Sent: 27 November 2025 11:08
    To: LUIS MIGUEL CONTRERAS MURILLO
    
<luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com
    <mailto:luismiguel.contrerasmuri...@telefonica.com>>>; Joel
    Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com
    <mailto:j...@joelhalpern.com>>>; lsr
    <lsr@ietf.org<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
    Cc: Giuseppe Fioccola
    <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com
    <mailto:giuseppe.fiocc...@huawei.com>>>; Paolo Volpato
    <paolo.volp...@huawei.com<mailto:paolo.volp...@huawei.com
    <mailto:paolo.volp...@huawei.com>>>; Bruno Decraene
    <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com
    <mailto:bruno.decra...@orange.com>>>
    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
    
<luismiguel.contrerasmuri...@telefonica.com<mailto:luismiguel.contrerasmuri...@telefonica.com
    <mailto:luismiguel.contrerasmuri...@telefonica.com>>>
    Sent: Thursday, November 27, 2025 13:40
    To: Joel Halpern
    <j...@joelhalpern.com<mailto:j...@joelhalpern.com
    <mailto:j...@joelhalpern.com>>>; lsr
    <lsr@ietf.org<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
    Cc: Giuseppe Fioccola
    <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com
    <mailto:giuseppe.fiocc...@huawei.com>>>; Paolo Volpato
    <paolo.volp...@huawei.com<mailto:paolo.volp...@huawei.com
    <mailto:paolo.volp...@huawei.com>>>; Bruno Decraene
    <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com
    <mailto:bruno.decra...@orange.com>>>; Vasilenko Eduard
    <vasilenko.edu...@huawei.com<mailto:vasilenko.edu...@huawei.com
    <mailto:vasilenko.edu...@huawei.com>>>
    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
    <j...@joelhalpern.com<mailto:j...@joelhalpern.com
    <mailto:j...@joelhalpern.com>>>
    Enviado el: jueves, 27 de noviembre de 2025 11:07
    Para: lsr <lsr@ietf.org<mailto:lsr@ietf.org <mailto:lsr@ietf.org>>>
    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 --lsr@ietf.org<mailto:lsr@ietf.org
    <mailto:lsr@ietf.org>>
    To unsubscribe send an email
    tolsr-le...@ietf.org<mailto:lsr-le...@ietf.org
    <mailto:lsr-le...@ietf.org>>

    ________________________________

    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 --lsr@ietf.org<mailto:lsr@ietf.org
    <mailto:lsr@ietf.org>>
    To unsubscribe send an email
    tolsr-le...@ietf.org<mailto:lsr-le...@ietf.org
    <mailto:lsr-le...@ietf.org>>


    _______________________________________________
    Lsr mailing list --lsr@ietf.org<mailto:lsr@ietf.org
    <mailto:lsr@ietf.org>>
    To unsubscribe send an email
    tolsr-le...@ietf.org<mailto:lsr-le...@ietf.org
    <mailto:lsr-le...@ietf.org>>



    _______________________________________________
    Lsr mailing list --lsr@ietf.org
    To unsubscribe send an email tolsr-le...@ietf.org

    _______________________________________________
    Lsr mailing list -- lsr@ietf.org
    To unsubscribe send an email to lsr-le...@ietf.org


_______________________________________________
Lsr mailing list --lsr@ietf.org
To unsubscribe send an email tolsr-le...@ietf.org

_______________________________________________
Lsr mailing list --lsr@ietf.org
To unsubscribe send an email tolsr-le...@ietf.org_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org