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
---
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
