Hi all,
I reviewed this document a couple of times as it progressed through the
working group, and my comments were addressed.
Here is an additional, small point. In Section 2 you have:
When Path Segment is not allocated from the SRGB pool, the
intermediate nodes MUST not see the Path Segment label at the top of
the label stack. A Path Segment presenting to an intermediate node
in this case is an error condition. 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.
Three things arise...
1. You need to clean up the use of BCP 14 language here:
a. s/MUST not/MUST NOT/
2. The use of "MUST NOT" would normally apply to what an implementation
does. Telling an implementation that it MUST NOT see something is hard
to implement! What is the coder supposed to do? "MUST NOT see" sounds
like "The implementation MUST close its eyes!"
But, I think the point here is that "labels are labels." Any node that
is not
the egress sees a label and assumes it is a forwarding a label. And the
processing is as simple as knowing that any label that erroneously
rises
to the top of stack will cause a forwarding error. This is not an error
that
can be detected by the forwarding node if the same label has been
allocated for use by the forwarding node. In order to detect this
error, it
is RECOMMENDED that MPLS OAM mechanisms are used to identify
mis-delivery. The Path Segment may enhance such tools.
2. In PHP, the Path Segment label may rise to the top of stack and so *will*
be seen. The key here, however, is that the node that sees it is not an
intermediate node, it is the egress. You might make that clear in the
text.
3. s/MAY/might/
That is, it is not an implementation choice, just a fact.
In Section 3.
For PHP (and notwithstanding the previous mention of PHP) I am concerned
that PHP is often use in a "pop-and-go" form so that the payload (e.g., IP)
is exposed for processing at the egress node. Now, what you are mandating
here is that the egress node must be capable of recognising the MPLS
encapsulation. This limits the utility of this approach since some nodes
cannot participate. This issue just needs to be called out by noting that
"...if an egress cannot support the use of the Path Segment Label, it MUST
reject the attempt to configure the label."
Cheers,
Adrian
-----Original Message-----
From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG
Sent: 06 November 2022 10:18
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: andrew-ietf@xxxxxxxxxxx; draft-ietf-spring-mpls-path-segment@xxxxxxxx;
james.n.guichard@xxxxxxxxxxxxx; spring-chairs@xxxxxxxx; spring@xxxxxxxx
Subject: Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path
Segment in MPLS Based Segment Routing Network) to Proposed Standard
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
