Hello Authors,
be used to describe a SR Policy, a Candidate-Path (CP), or a Segment-
List (SL) [RFC9256]. Therefore, the Path Segment may be used to
identify an SR Policy, its CP, or a SL terminating on an egress node
(PHP), where some labels are be popped off at the penultimate hop of
an SR path, but the Path Segment MUST NOT be popped off until it
stack, for each path (or sub-path), there may be a corresponding Path
Please find below some comments on the draft. I hope these can be addressed to fix/improve the document.
Major:
1) Sec 1: The term "SR path" is not defined in either RFC8402 or RFC9256. It seems this document is trying to introduce this terminology/concept. If so, it needs to be defined more formally with respect to the SR Policy. There is some text about this buried further in the document that perhaps needs to be specified more formally. Most of the document is dependent on this term.
2) Sec 1: One of the key aspects of SR is that the state is on the SR Source Node and not the destination. I think it is important to cover/say
that remains the case for most situations and it is only in very specific cases that this Path Segment and the need to introduce a "per-path" state or awareness may be required at the destination/egress node.3) Sec 1:
QOUTE
However, to support various use-cases in SR-MPLS networks, like end-
to-end 1+1 path protection (Live-Live case) [RFC4426], bidirectional
path [RFC5654], or Performance Measurement (PM) [RFC7799], the
ability to implement path identification on the egress node is a pre-
requisite.
to-end 1+1 path protection (Live-Live case) [RFC4426], bidirectional
path [RFC5654], or Performance Measurement (PM) [RFC7799], the
ability to implement path identification on the egress node is a pre-
requisite.
UNQOUTE
It is very difficult to glean out what parts of these references make the assertion for the need for a Path Segment. More specific references to sections along with text that explains why Path Segment is necessary would help. Perhaps that goes into a use-cases or applicability section?
It is very difficult to glean out what parts of these references make the assertion for the need for a Path Segment. More specific references to sections along with text that explains why Path Segment is necessary would help. Perhaps that goes into a use-cases or applicability section?
4) Sec 2:
QUOTE
If the Path Segment is used by an intermediate node to identify a SR path, the SRGB MUST be used.
UNQOUTE
Is there an assumption that there is no service label (or flow label) following the PSID label? How can an intermediate node know where the PSID label lies in the label stack?
5) Sec 2
QOUTE
The term of SR path used in this document is a general term that canbe used to describe a SR Policy, a Candidate-Path (CP), or a Segment-
List (SL) [RFC9256]. Therefore, the Path Segment may be used to
identify an SR Policy, its CP, or a SL terminating on an egress node
depending on the use-case.
UNQOUTE
See my previous comment. Can it be defined more formally? Who determines what the Path Segment is associated with? The egress
allocates it but it is used by the ingress by associating with a specific SR Policy or specific Candidate Path or specific Segment List?
allocates it but it is used by the ingress by associating with a specific SR Policy or specific Candidate Path or specific Segment List?
6) Sec 2
QOUTE
When Path Segment is allocated from the SRGB pool, an intermediate node MAY see the Path Segment label at the top of the label stack.
UNQOUTE
See previous comment and I am not able to understand how intermediate nodes can figure this out.
7) Sec 2
QOUTE
A Path Segment can be used in the case of Penultimate Hop Popping(PHP), where some labels are be popped off at the penultimate hop of
an SR path, but the Path Segment MUST NOT be popped off until it
reaches at the egress node.
UNQOUTE
How or why would the PH pop path segment? Is there any issue with misrouting if the PSID label was exposed at the top of the label
stack at other than the egress node? Especially if it is not allocated from the SRGB and is not unique in the domain.
stack at other than the egress node? Especially if it is not allocated from the SRGB and is not unique in the domain.
8) Sec 2
QOUTE
There may be multiple paths (or sub-path(s)) carried in the labelstack, for each path (or sub-path), there may be a corresponding Path
Segment carried. A use case can be found in Section 4.
UNQOUTE
Please define what a sub-path is at the beginning of the document.
9) Sec 4
QOUTE
Figure 2 shows the details of the label stacks when PSID and BSID are
used to support both sub-path and end-to-end path monitoring in a
multi-domain scenario.
used to support both sub-path and end-to-end path monitoring in a
multi-domain scenario.
UNQOUTE
What specific monitoring is required/used here when the path is end to end. By using PSID for sub-paths, are we not exposing the issue
to many more nodes in the network. In the figure below, has the scalability impact on a mid-point aggregation node B
through which a large number of SR Paths may be transiting been considered? Does that not go against the SR paradigm?
What specific monitoring is required/used here when the path is end to end. By using PSID for sub-paths, are we not exposing the issue
to many more nodes in the network. In the figure below, has the scalability impact on a mid-point aggregation node B
through which a large number of SR Paths may be transiting been considered? Does that not go against the SR paradigm?
10) Sec 6
QOUTE
In the current SR architecture, an SR path is a unidirectional path
[RFC8402]. In order to support bidirectional SR paths, a
straightforward way is to bind two unidirectional SR paths to a
single bidirectional SR path. Path Segments can then be used to
identify and correlate the traffic for the two unidirectional SR
paths at both ends of the bidirectional path.
[RFC8402]. In order to support bidirectional SR paths, a
straightforward way is to bind two unidirectional SR paths to a
single bidirectional SR path. Path Segments can then be used to
identify and correlate the traffic for the two unidirectional SR
paths at both ends of the bidirectional path.
UNQOUTE
RFC5654 does not seem to justify the need for a Path Segment for the bidirectional use-case. The computation aspect of bidir paths
is already covered and there is no issue there. I don't see the justification for the need of a PSID to be used in the data path. It would help if a description of the use-case about why the egress node needs to know the reverse path context and what it can or may do with it were covered.
is already covered and there is no issue there. I don't see the justification for the need of a PSID to be used in the data path. It would help if a description of the use-case about why the egress node needs to know the reverse path context and what it can or may do with it were covered.
11) Sec 7
QOUTE
There then needs to be a method of binding this SR path identifiers
into equivalence groups such that the egress node can determine for
example, the set of packets that represent a single primary path. It
is obvious that this equivalence group can be instantiated in the
into equivalence groups such that the egress node can determine for
example, the set of packets that represent a single primary path. It
is obvious that this equivalence group can be instantiated in the
network by an SDN controller using the Path Segments of the SR paths.
UNQOUTE
Unlike the other use-cases, there does not seem to be an equivalent description or specification on how this use-case is realized
using PSID for SR Policy
using PSID for SR Policy
Minor:
a) Please consider shortening the abstract. Right now it is almost mirroring the Introduction.
b) Sec 2
QOUTE
In addition, adding a Path Segment to a label stack will increase the
depth of the label stack, the Path Segment should be accounted when
considering Maximum SID Depth (MSD)[RFC8992].
UNQOUTE
depth of the label stack, the Path Segment should be accounted when
considering Maximum SID Depth (MSD)[RFC8992].
UNQOUTE
This is a repetition of text just a few paragraphs above.
Thanks,
Ketan
On Sun, Nov 6, 2022 at 3:48 PM The IESG <iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Path Segment in MPLS Based
Segment Routing Network'
<draft-ietf-spring-mpls-path-segment-08.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-11-20. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
A Segment Routing (SR) path is identified by an SR segment list.
Only the complete segment list can identify the end-to-end SR path,
and a sub-set of segments from the segment list cannot distinguish
one SR path from another as they may be partially congruent. SR path
identification is a pre-requisite for various use-cases such as
Performance Measurement (PM), bidirectional paths correlation, and
end-to-end 1+1 path protection.
In SR for MPLS data plane (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.
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 by 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 is preserved until it
reaches the egress node for SR path identification and correlation.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
The following IPR Declarations may be related to this I-D:
https://datatracker.ietf.org/ipr/5009/
https://datatracker.ietf.org/ipr/3492/
https://datatracker.ietf.org/ipr/3455/
https://datatracker.ietf.org/ipr/5063/
_______________________________________________
IETF-Announce mailing list
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
