[IPv6]Re: Ketan Talaulikar's Discuss on draft-ietf-6man-sidlist-clarification-02: (with DISCUSS and COMMENT)

[Adrian Farrel <[e-mail]>]

Hi Ketan,

 

Suresh and I had a chat.

 

I remain in complete disagreement with you, but I’m not going to fight.

 

We can easily delete section 3.4 and move on.

 

Cheers,

Adrian

 

From: Ketan Talaulikar <[e-mail]> 
Sent: 13 May 2026 23:12
To: [e-mail]
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [IPv6]Ketan Talaulikar's Discuss on draft-ietf-6man-sidlist-clarification-02: (with DISCUSS and COMMENT)

 

Hi Adrian,

 

Please see the inline comments for clarifications.

 

 

On Wed, May 13, 2026 at 8:30 PM Adrian Farrel <[e-mail] <mailto:[e-mail]> > wrote:

Thanks for thoughtful and detailed comments, Ketan.

I am pondering the difference between a SID and a Segment List entry.

You are quite right that 8754 section 4.3 discusses a single SID with its specific Endpoint Behavior. There is nothing about that Endpoint Behavior that needs to be changed, and this document does not make any such change.

 

KT> This document (in section 3.4) updates S16 of the pseudocode for the SID behavior specified in section 4.3.1.1 of RFC8754. This particular behavior cannot "derive" things, it very strictly and specifically copies the next 128-bit entry from the SL in the SRH into the IPv6 DA. The same is the case with the End behavior in https://www.rfc-editor.org/rfc/rfc8986.html#section-4.1 (see S14. Update IPv6 DA with Segment List[Segments Left]). There is no vague mapping or derivation. Everything in the pseudocode needs to be very precise.  In contrast, the "derivation" logic is specifically clarified in the "End with REPLACE-CSID" in https://www.rfc-editor.org/rfc/rfc9800.html#section-4.2.1 (see https://www.rfc-editor.org/rfc/rfc9800.html#appendix-A.6 for the complete pseudocode).

 


However, the description of the processing of the Segment List in the SRH does need to be changed because, quite simply, the SID that needs to be processed is not necessarily found directly in the Segment List. It cannot be blindly copied out but must be "derived" where the derivation function may be a copy or may be some other function.

 

KT> This discussion is only about removing section 3.4. The rest of the document is accurate and effectively clarifies these aspects. 

 

Thanks,

Ketan

 



The point is that the Segment List is just an encoding of the SIDs not an explicit listing of them. That is, in fact, the whole point of this document.

Cheers,
Adrian

-----Original Message-----
From: Ketan Talaulikar via Datatracker <[e-mail] <mailto:[e-mail]> > 
Sent: 13 May 2026 20:08
To: The IESG <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: [IPv6]Ketan Talaulikar's Discuss on draft-ietf-6man-sidlist-clarification-02: (with DISCUSS and COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-6man-sidlist-clarification-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-sidlist-clarification/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for taking up this document to clarify and
update RFC8754.

There is one specific update/change that I would like to discuss. This is
section 3.4 which updates contents in RFC8754
https://www.rfc-editor.org/rfc/rfc8754.html#section-4.3.1.1 and is not
necessary but also inappropriate.

Section 4.3.1 of RFC8754 says "This document and section define a single SRv6
SID. Future documents may define additional SRv6 SIDs." What is specified in
this section 4.3.1 (and its subsection) is actually an SRv6 Endpoint Behavior
(value 32767 "The SID defined in [RFC8754]" -
https://www.iana.org/assignments/segment-routing/segment-routing.xhtml#srv6-endpoint-behaviors)

This SRv6 Endpoint Behavior does not need to be update since it does not need
to support or be compatible with (say as an example) CSID-REPLACE flavor of
SRv6 Endpoint Behaviors. CSID-REPLACE is a new/different flavor of behaviors
that were specified by RFC9800. There are also a bunch of other SRv6 Endpoint
Behaviors specified by RFC8986 which were not "updated" or modified for
CSID-NEXT or CSID-REPLACE - those don't work with CSID-REPLACE. What was
instead done is that RFC9800 defined new SRv6 Endpoint Behaviors for those new
CSID flavors.

In summary, the SRv6 Segment Endpoint Behavior with value 32767 is "burnt"
(i.e., in-use) and cannot be modified. That pseudocode does not need to be
changed and hence the section 3.4 of this document can be deleted.

If this aspect is not clear to some readers of RFC8754, this may be clarified
with suitable text in this document.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also have a comment to share which may be DISCUSS-worthy but seemed to be
more editorial in nature to me.

This document uses the words "mapped" or "mapping" to describe how the IPv6 DA
is determined from the contents of the SRH SL entry. I would say that "map"
limits the scope of operations and something like "derived" is more suitable as
it allows for a wider range of procedures (which one would expect to be
specified as SRv6 Endpoint Behaviors' pseudocode).

I will note that the document already used "derived" in sections 3.4 and 3.5.
Perhaps it can be used consistently in other places as well?



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail] <mailto:[e-mail]> 
List Info: https://mailman3.ietf.org/mailman3/lists/[e-mail]/
--------------------------------------------------------------------