[spring] Re: [Re]Some comments on draft-ietf-spring-srv6-path-segment

[Cheng Li <[e-mail]>]

It seems that the attachment were blocked(1 XML file and 1 Diff html file).
The diff html file seems ok in the email to Bruno, so I added it once more here.

I may try to use Github link to share the diff next time to avoid sending attachments to the list.

Thanks,
Cheng


From: Cheng Li
Sent: Monday, September 2, 2024 9:56 PM
To: [e-mail]; '[e-mail]' <[e-mail]>
Cc: [e-mail]
Subject: [Re][spring] Some comments on draft-ietf-spring-srv6-path-segment

This is a thread to discuss the comments from Adrian. Thanks to Adrian!

I made a mistake that only discuss with co-authors and Adrian( who kindly reviewed the draft and provided his valuable comments), and then submitted the draft revision 04 directly.
I copied the content of Adrian's original email below, since the email was too long ago and cannot be found locally.

Hi Adrian, please review the revision 04 or the latest revision to see if your comments are addressed. If you have further comments(since this is a fly-by review), you are welcome to share for sure!
I also attach the latest revision(10, to be uploaded), please review.

Thanks,
Cheng



====================================================

Hi,



This is a bit of a "fly-by" review. I happened to need to read the draft

to check on the use of SRH flags, so here are a few quick comments.

I hope they are useful.



Best,

Adrian



==Medium==



General



Some of my points below are cleared up when I finally got to Section 7

and discovered that you are asking for a new Endpoint Behavior to be

assigned. I think that means it *is* possible to detect that a PSID is

present at the wrong place in the stack *if* the processing node knows

enough to look at the endpoint behaviour and understand it. However, the

only (clear) mention of the new endpoint behaviour is in Section 7: TBA1

should be mentioned in the text somewhere!

[Cheng]You are correct. I added a simple sentence in section 3.1.1 as below.



__OLD__

SRv6 Path Segment can follow the format, where the LOC part identifies the egress node that allocates the Path Segment, and the FUNCT part is a unique local ID to identify an SRv6 Path and its endpoint behavior, which is END.PSID (End Function with Path Segment Identifier).



__NEW__

SRv6 Path Segment can follow the format, where the LOC part identifies the egress node that allocates the Path Segment, and the FUNCT part is a unique local ID to identify an SRv6 Path and its endpoint behavior, which is END.PSID (End Function with Path Segment Identifier). The code point of END.PSID is 100.



The code point has been registered cause the value is FCFS,  please see https://www.iana.org/assignments/segment-routing/segment-routing.xhtml





4.1



Here you are attempting to state which bit is used as the P-flag.

But there is a registry for the SRH Header flags (at

https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#segme

nt-routing-header-flags)

so you should leave this as bit number TBD, and specifically ask IANA

to assign *a* bit.



You do actually do this in Section 7 but it is in conflict with 4.1.



Note that the registry is IETF review which does allow early assignment

if you want to get the flag agreed for early implementation and interop

etc.



[Cheng]Ok, Bruno also suggested to remove the bit from the figure, so I will do it in the next revision. Please see the diff.



My another mistake is that I mistakenly deleted one more paragraph in IANA in revision 05, which is about the P-flag, oh my god, how it could happen...

https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-path-segment-04&url2=draft-ietf-spring-srv6-path-segment-05&difftype=--html



I have added back the text.







==Minor==



Section 1



   In an SR-MPLS network, when a packet is transmitted along an SR path,

   the labels in the MPLS label stack will be swapped or popped, so no

   label or only the last label may be left in the MPLS label stack when

   the packet reaches the egress node.  Thus, the egress node can not

   determine from which ingress node or SR path the packet came from.

   Therefore, to identify an SR-MPLS path, a Path Segment is defined in

   [I-D.ietf-spring-mpls-path-segment].



   Likewise, a path needs to be identified in an SRv6 network for

   several use cases such as binding bidirectional paths

   [I-D.ietf-pce-sr-bidir-path] and end-to-end performance measurement

   [I-D.gandhi-spring-udp-pm].



This all reads like the main use case in SR-MPLS is source

identification, and that bidirectional path binding and PM are special

for SRv6. I suggest reversing the order of the paragraphs so...



   In SR, a path needs to be identified for several use cases such as

   binding bidirectional paths [I-D.ietf-pce-sr-bidir-path] and end-to-

   end performance measurement [I-D.gandhi-spring-udp-pm].



   Additionally, in an SR-MPLS network, when a packet is transmitted

   along an SR path, the labels in the MPLS label stack will be swapped

   or popped, so no label or only the last label may be left in the MPLS

   label stack when the packet reaches the egress node.  Thus, the

   egress node can not determine from which ingress node or SR path the

   packet came from.  To identify an SR-MPLS path, a Path Segment is

   defined in [I-D.ietf-spring-mpls-path-segment].



[Cheng]updated accordingly.



---

[]

1.



   An SRv6 Path Segment MUST NOT be copied to the IPv6 destination

   address, so it is not routable.



I think this is back-to-front...



   An SRv6 Path Segment is not routable (it is just an abstract 128 bit

   identifier) so it MUST NOT be copied to the IPv6 destination address.



---



Usually, we don't use BCP 14 language (you have MAY and MUST NOT) in the

Introduction. It is supposed to be introducing the concepts not

defining behaviour.



There are ways around this:

- use lower case (and sometimes reword)

- reduce the Introduction and move the normative language to later

[Cheng]Thank you, updated already, please check

---



4.1



   o  P-bit: set when SRv6 Path Segment is inserted.  It MUST be ignored

      when a node does not support SRv6 Path Segment processing.



Well, some nodes not supporting SRv6 Path Segment processing don't

understand the P flag and have never read this document. So you can't

tell them in this document what to do!



You have to refer them back to 8754 with something like



   o  P-bit: set when SRv6 Path Segment is inserted.  A node that does

      not understand the P-bit will ignore it as described in [RFC8754].

      A node that understands the P-flag but does not support SRv6 Path

      Segment processing MUST ignore the P-bit.



However, what is missing, I think is what happens at an egress node

when the P-flag is set and the egress either doesn't understand or

doesn't support SRv6 Path Segments. In this case, the P-flag will be

ignored, but what will happen to the PSID? Will processing be attempted?

You might argue that "A Path Segment is a local segment allocated by an

egress node, so this situation cannot happen." But I would say that is

"should not happen" because there are ingress errors, and there are

timing windows. So you need to describe this edge case.

[Cheng]Ack, please see the update

---



5.



   When a Path Segment is allocated by the egress, it MUST be

   distributed to the ingress node of the path that identified by the

   path segment.  In this case, only the egress will process the Path

   Segment, and other nodes specified by SIDs in the segment list do not

   know how to process the Path Segment.



   Depending on the use case, a Path Segment may be distributed to the

   SRv6 nodes along the SRv6 path.  In this case, the SRv6 nodes that

   learned the Path Segment may process the Path Segment depending on

   the use case.



This is pretty unclear about how the distribution happens. I think you

either need to describe or reference the mechanisms, or you have to be

clear that the distribution mechanisms are for future study (although,

in that case, it is debatable whether there is any value to this

document!)

[Cheng]Please see the update, we leave this to other drafts.



---



6.



      An SRv6 Path

      Segment that appears at any other location in the SID list will be

      treated as an error.



Will it, though? Or will an attempt be made to treat it as some other

form of SID causing unpredictable behaviour? That is, regardless of the

P-flag, if a PSID is inserted into the middle of a SID stack, an

attempt will be made to process it (possibly resulting in an error, or

possibly resulting in the packet being forwarded on an address that

should not be treated as routable). But is there any way to know that

the PSID is at the wrong location (or present multiple times)?



So, I think you are fine to say "MUST be bottom of stack" and "MUST NOT

appear at other locations." But all that you can say beyond that is

that "placing a PSID at any location in the SID list will result in

unpredictable forwarding behavior."

[Cheng]Ack please see the update

---





==Nits==



Section 1



OLD

from which ingress node or SR path the packet came from.

NEW

from which ingress node or SR path the packet came.

END

[Cheng]OK

---



1.



s/called "SRv6 Path Segment"/called the "SRv6 Path Segment"/



---

[Cheng]OK

1.2



You don't need to include terms that appear at in the RFC Editor's list

at https://www.rfc-editor.org/materials/abbrev.expansion.txt marked with

an asterisk (*).



In this case, that's "MPLS"

[Cheng]Deleted

---



3.1



   This document proposes two types of SRv6 Path Segment format.



Be future-proof! "This document defines..."

[Cheng]OK

---



3.1.1



Here you appear to say that the SRv6 Path Identifier can be routable

(i.e., is built with as LOC:FUNCT), but in the Introduction you are

adamant that it is not routable.

[Cheng]We do not prevent the operator to allocate a routable value to it, but we do not use it in routing.

---



4.1



Nothing wrong with Figure 1 (except the alignment of the bit counters)

but it seems overkill to draw what the text says.

[Cheng]Already updated. Please see the latest revison. https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-path-segment-09



---



Please decide "P-flag" or "P-bit". Probably flag.

[Cheng]OK, P-flag

---



  *   [spring] Some comments on draft-ietf-spring-srv6-...<https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/>  Adrian Farrel





https://mailarchive.ietf.org/arch/msg/spring/AsRF1-XMAbT3yu3GUbvnnU2dyBk/