[spring] 答复: Review of draft-ietf-spring-mpls-path-segment-00

["Weiqiang Cheng" <[e-mail]>]

Hi Adrian,
Thank you very much for the review and edits suggestion.
We will update the draft based on the editorial comments in new version.
About PHP, the Path Segment is supposed to be known by the egress node. We
will add a paragraph to describe the consideration on some other cases such
as egress is not MPLS-capable and wants to process the payload packet (e.g.,
IP).

B.R.
Weiqiang Cheng

-----邮件原件-----
发件人: Adrian Farrel [mailto:[e-mail]] 
发送时间: 2019年8月28日 18:19
收件人: 'SPRING WG'
抄送: [e-mail]
主题: Review of draft-ietf-spring-mpls-path-segment-00

Hi SPRING and document authors,

Now we've adopted this draft, I thought I should give it a more careful
reading. Here are some thoughts and nits.

Best,
Adrian

=== General thoughts ===

I think that the Abstract and Introduction need to make it clear (as the
title does, and does Section 2) that this document only applies to
SR-MPLS.  I have suggested edits in line.

---

Do we need to cover PHP?

---

In the case of a centralised controller, there is a risk that a Path
Segment will be applied for an egress that does not expect it.  It will
know what to do with the last segment identifier in the path list (i.e.,
pop it) and will then find the path segment label.  The risk is that
that label is somehow in the LFIB (if it is not, then it is unrecognised
and the packet is simply dropped).  Presumably, the important thing is
for the centralised controller to not make this mistake, and there is
nothing the egress can do to protect itself.  The big risk is when a
central controller is allocating Path Segment identifiers and the egress
node is allocating labels from the same space.  It is important to write
something about this.  Probably you can reduce the risk by splitting the
label space. Maybe this all belongs in Section 4.

=== Edits ===

Abstract

OLD
   A Segment Routing (SR) path is identified by an SR segment list, one
   or partial segments of the list cannot uniquely identify the SR path.
   Path identification is a pre-requisite for various use-cases such as
   performance measurement (PM) of an SR path.
NEW
   A Segment Routing (SR) path is identified by an SR segment list.  Only
   the full segment list identifies the full end-to-end path, and one
   segment or a partial set of segments from the list cannot identify
   the SR path and distinguish it from other SR paths that may be
   partially congruent.  But path identification is a pre-requisite for
   various use-cases such as performance measurement (PM) of an SR path.

   In SR for MPLS (SR-MPLS) the segment identifiers are stripped from
   the packet through label popping as the packet transits the network.
   This means that when a packet reaches the egress of the SR path, it
   is not possible to determine on which SR path it traversed the
   network.
END

OLD
   This document defines a new type of segment that is referred to as
   Path Segment, which is used to identify an SR path.  When used, it is
   inserted at the ingress node of the SR path and immediately follows
   the last segment of the SR path.  The Path Segment will not be popped
   off until it reaches the egress node of the SR path.
NEW
   This document defines a new type of segment that is referred to as
   Path Segment, which is used to identify an SR path in an SR-MPLS
   network.  When used, it is inserted at the ingress node of the SR
   path and immediately follows the last segment identifier in the
   segment list of the SR path.  The Path Segment will not be popped
   off until it reaches the egress node of the SR path.
END

OLD
   Path Segment can be used by the egress node to implement path
   identification hence to support various use-cases including SR path
   PM, end-to-end 1+1 SR path protection and bidirectional SR paths
   correlation.
NEW
   A Path Segment can be used by the egress node to implement path
   identification hence to support various use-cases including SR path
   PM, end-to-end 1+1 SR path protection, and bidirectional SR paths
   correlation.
END

---

1.  Introduction

OLD
   Segment Routing (SR) [RFC8402] is a source routed forwarding method
   that allows to directly encode forwarding instructions (called
   segments) in each packet, hence it enables to steer traffic through a
   network without the per-flow states maintained on the transit nodes.
   Segment Routing can be instantiated on MPLS data plane or IPv6 data
   plane.  The former is called SR-MPLS, the latter is called SRv6
   [RFC8402].  SR-MPLS leverages the MPLS label stack to construct SR
   path, and SRv6 uses the a new IPv6 Extension Header (EH) called the
   IPv6 Segment Routing Header (SRH)
   [I-D.ietf-6man-segment-routing-header] to construct SR path.
NEW
   Segment Routing (SR) [RFC8402] is a source routed forwarding method
   that allows to directly encode forwarding instructions (called
   segments) in each packet, hence it enables steering traffic through a
   network without the per-flow states maintained on the transit nodes.
   Segment Routing can be instantiated on an MPLS data plane or an IPv6
   data plane.  The former is called SR-MPLS
   [I-D.ietf-spring-segment-routing-mpls], the latter is called SRv6
   [RFC8402].  SR-MPLS leverages the MPLS label stack to construct SR
   paths.
END

OLD
   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
   that 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
   cannot determine from which SR path the packet comes.
NEW
   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
   that 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
   cannot determine along which SR path the packet came.
END

   However, to support use cases like end-to-end 1+1 path protection
   (Live-Live case), bidirectional path correlation or performance
   measurement (PM), the ability to implement path identification is a
   pre-requisite.
>>> Would be good to give a reason for this pre-requisite.

OLD
   Therefore, this document introduces a new segment that is referred to
   as Path Segment.  A Path Segment is defined to uniquely identify an
   SR path in the context of the egress node.  It is normally used by
   egress nodes for path identification or correlation.
NEW
   Therefore, this document introduces a new segment that is referred to
   as the Path Segment.  A Path Segment is defined to uniquely identify
   an SR path in an SR-MPLS network in the context of the egress node.
   It is normally used by egress nodes for path identification or
   correlation.
END

---

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.
>>> Need a space between the references (to stop idnits complaining)

---

2.  Path Segment

   A Path Segment is a single label that is assigned from the Segment
   Routing Local Block (SRLB) or Segment Routing Global Block (SRGB) of
   the egress node of an SR path.  It means that the Path Segment is
   unique in the context of the egress node of the SR path.  When Path
>>> s/When/When a/
   Segment is used, the Path Segment MUST be inserted at the ingress
   node and MUST immediately follow the last label of the SR path.  The
   Path Segment may be used to identify an SR-MPLS Policy, its
   Candidate-Path (CP) or a SID List (SL)
>>> s/(CP)/(CP),/
   [I-D.ietf-spring-segment-routing-policy] terminating on an egress
   node depending on the use-case.

OLD
   The value of the TTL field of the Path Segment MUST be set to the
   same value of the last segment label of the SR path.  If the Path
   Segment is the bottom label, the S bit MUST be set.
NEW
   The value of the TTL field in the MPLS label stack entry containing
   the Path Segment MUST be set to the same value as the TTL of the last
   label stack entry for the last segment in the SR path.  If the Path
   Segment is the bottom label, the S bit MUST be set.
END

               +--------------------+
               |       ...          |
               +--------------------+
               |      Label 1       |
               +--------------------+
               |      Label 2       |
               +--------------------+
               |       ...          |
               +--------------------+
               |      Label n       |
               +--------------------+
               |     Path Segment   |
               +--------------------+
               |       ...          |
               +--------------------+

>>> Shouldn't the last entry be
               +--------------------+
               ~     Payload        ~
               +--------------------+

      Figure 1: Label Stack with Path Segment

---

6.  Path Segment for Bi-directional SR Path

   With the current SR architecture, an SR path is a unidirectional
   path.  In some scenarios, for example, mobile backhaul transport
   network, there are requirements to support bidirectional path, and
>>> s/path/paths/
   the path is normally treated as a single entity and both directions
   of the path have the same fate, for example, failure in one direction
   will result in switching at both directions.

   MPLS supports this by introducing the concepts of co-routed
   bidirectional LSP and associated bidirectional LSP.  With SR, to
   support bidirectional path, a straightforward way is to bind two
>>> s/path/paths/
   unidirectional SR paths to a single bidirectional path.  Path
   segments can be used to correlate the two unidirectional SR paths at
>>> s/segments/Segments/
   both ends of the paths.

---

7.  Path Segment for End-to-end Path Protection

   For end-to-end 1+1 path protection (i.e., Live-Live case), the egress
   node of an SR path needs to know the set of paths that constitute the
   primary and the secondary(s), in order to select the primary packet
s/y(s)/ies/
   for onward transmission, and to discard the packets from the
   secondary(s).
s/y(s)/ies/

OLD
   It is obvious that this group can be instantiated in the network by
   an SDN controller.
NEW
   It is obvious that this group can be instantiated in the network by
   an SDN controller and that the Path Segment achieves the desired
   function.
END

---