Re: [Last-Call] Last Call: <draft-ietf-spring-mpls-path-segment-08.txt> (Path Segment in MPLS Based Segment Routing Network) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux