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

[Adrian Farrel <[e-mail]>]

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!

---

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.

==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].

---

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

---

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.

---

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!)

---

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." 

---


==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

---

1.

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

---

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"

---

3.1

   This document proposes two types of SRv6 Path Segment format.

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

---

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.

---

4.1

Nothing wrong with Figure 1 (except the alignment of the bit counters)
but it seems overkill to draw what the text says. 

---

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

---