Re: [spring] [Spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

[Gyan Mishra <[e-mail]>]

Dear Rakesh & Authors

I replied during WGLC on July 29th supporting publication of this draft,
but did not hear back from the authors.

I have since added some additional comments in this email related to this
SR-MPLS draft as well as other Path Segment related drafts and how they
reference each other as normative references as well as how each of the
drafts help explain the entire path segment solution and how  SR-MPLS and
SRv6 path segment solutions related to the extensions for PCE and SR policy
updates.



This draft can be very useful for operators and provides an RSVP-TE record
route style function in a new Path SID that can be leveraged for IOAM PM
use case as well as BIDIR path association and 1+1 protection solution.



As all of these drafts relate to each other from a SR PSID path segment
perspective I would like to comment on all of the drafts below as it
relates to this draft WGLC as well as progressing the other drafts listed
below also provide some synchronization and parity between the drafts:

All 5 drafts as they define the overall SR Path Segment solution, I believe
they all should have normative mentions of each of the other drafts.  I
reviewed all 5 drafts and they do except for any noted below.

SR Path Segment drafts:

SR-MPLS Path Segment

https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05



SRv6 Path Segment

https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-07



PCE SR extension for PSID path Segment

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04



PCE SR extension for BIDIR PSID Path Segment

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path



SR Policy Path Segment

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment



SR MSD as it applied to SR-MPLS & SRv6 Compression & how Path Segment can
be used to alleviate MSD issues:

Can the Path Segment solution be used to help with MSD issues for both
SR-MPLS  & SRv6 very long strict paths by being able to reference inter-as
paths as PSID/BSID sub paths instead of the expanded path?



*SR-MPLS Path Segment - WGLC Review: *



https://datatracker.ietf.org/doc/html/draft-ietf-spring-mpls-path-segment-05



Recommendation to update the verbiage to state that 1+1 path protection is
an SR-MPLS specification optimization using PSID solution.



Since PSID can be used for 1+1 path protection my thoughts are that maybe
PSID can be used to help overall in MSD SID depth issues on the primary
active path for very long paths to help with SID depth and reduce the size
SID path length with PSID/BSID nested sub path segments.

PSID could also be stated as an optimization for MSD issues for very long
strict paths to help in the reduction of the size of the SID list in an
SR-TE policy to define the path using the BSID/PSID path vector to compress
the explicit path.  My thoughts are that Sub paths created by PSID/BSID
keys can be used for inter-as paths across multiple domains, a similar
concept of RFC 4736 lose hop expansion can be used for longer paths to help
compress and cutdown on the E2E Path containing all the SIDs.  In cases
where the intra-as path is very long the path can be broken up into
PSID/BSID sub paths regions within a domain.  I believe this could apply to
both SR-MPLS & SRv6 very long E2E strict paths that cross many AS’s and
domains.



Abstract section:

OLD TXT



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 will not be popped off
until it reaches the egress node of the SR path.  The Path Segment

then can be used by the egress node to implement SR path
identification and correlation.





NEW TXT



Segment Routing (SR)  [RFC8402
<https://datatracker.ietf.org/doc/html/rfc8402>] leverages the
source-routing paradigm to steer packets from a source node through a
controlled set of instructions, called segments, by prepending the
packet with an SR header in the MPLS data plane SR-MPLS [RFC8660
<https://datatracker.ietf.org/doc/html/rfc8660>] through a label stack
or IPv6 data plane using an SRH header via SRv6 [RFC8
<https://datatracker.ietf.org/doc/html/rfc8402>986] to construct an SR
path. The MPLS forwarding plane does not preserve the path state at
the egress node that maybe use for various optimization and path
correlation use cases similar to what is provided by RSVP-TE record
route object.



   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.



This document defines a new path segment that enables SR path
identification which is a pre-requisite for various use-cases such as
Performance Measurement (PM), bidirectional paths correlation, as well
as SR-MPLS specification optimizations such as end-to-end 1+1 path
protection and SR path list compression for MSD optimizations.



Introduction section:



OLD TXT

Segment Routing (SR) [RFC8402
<https://datatracker.ietf.org/doc/html/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 [RFC8660 <https://datatracker.ietf.org/doc/html/rfc8660>], the
latter is called SRv6 [RFC8402
<https://datatracker.ietf.org/doc/html/rfc8402>].  SR-MPLS leverages
the MPLS label stack to construct an SR path.



NEW TXT



Segment Routing (SR)  [RFC8402
<https://datatracker.ietf.org/doc/html/rfc8402>] leverages the
source-routing paradigm to steer packets from a source node through a
controlled set of instructions, called segments, by prepending the
packet with an SR header in the MPLS data plane SR-MPLS [RFC8660
<https://datatracker.ietf.org/doc/html/rfc8660>] through a label stack
or IPv6 data plane using an SRH header via SRv6 [RFC8
<https://datatracker.ietf.org/doc/html/rfc8402>986] to construct an SR
path.



In the SRv6 PSID draft PSP must be disabled in SRv6 PGM.


For SR-MPLS PSID draft  PHP implicit null does not need to be disabled as
long as the BOS S bit is set and the TTL is set to last label in label
stack.  Agreed.



Since the label stack for L2/L3 VPN is 2 labels deep with topmost label as
topological label and bottom label as the service label.



Would the Path segment appear as the last label in the set of labels or SR
label stack representing the topological path or below the service label
and in that case would have the BOS bit S set.   Would the path segment
label only be the bottom label for Global table routing where no service
label exists but if a L2/L3 VPN service label exists then the S bit would
not be set on the PSID?

In figure 1 it shows the PSID label as the last label, below the Service
labels.  If that is the case then the BOS S bit would be set.

Can we state explicitly if the path label will always be the bottom label
or are there certain circumstances where it would not be the bottom label.

How does the PSID label TTL change in PHP enabled versus disabled mode with
respect to pipe and uniform mode RFC 3443.



RFC 8662 states that the entropy label ELI/EL would be placed at readable
depths within the label stack section 10.5.



 “Entropy label and Entropy Label Indicator (ELI) as described in

   [RFC8662 <https://datatracker.ietf.org/doc/html/rfc8662>] for
SR-MPLS path, can be placed before or after the Path Segment label in
the MPLS label stack.”



So how would you prevent the PSID label from being popped in the PHP case
if it’s Entropy label is placed before or after the PSID label?



 Also I am not sure how that would work if per RFC 8662 the placement of
the ELI/EL for load balancing and issues with DPI and processing is placed
at per section 10.5 at readable depths?

The introduction section of the SRv6 Path draft mentions the SR-MPLS path
segment solution & as they both are drafts and similar maturity states the
SR-MPLS path segment draft should mention the SRv6 path segment draft as
well to be complete.


Section 6 should mention PCE bidir path segment draft.  I don't see it
mentioned.

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path

Section 7 E2E path protection it would be helpful to have a picture similar
to section 4 with sub paths and depicting a similar scenario with access,
aggregation & core E2E path with the BSID/PSID path nested sub paths and
how they 1+1 protection of the E2E would be instantiated.



*SRv6 Path segment draft - Comments:*

https://datatracker.ietf.org/doc/html/draft-li-spring-srv6-path-segment-07

In the SR-MPLS Path segment draft can the section 4 Nesting of paths
segments concept with PSID/BSID path vector sub paths apply to SRv6?  I
think this would help tremendously with SRv6 compression for long inter-as
paths. Also as stated above can the path segments be used for not only 1+1
path protection, but also for defining the E2E path with a minimal number
of SIDs thereby compression of the overall SID path and help eliminate MSD
issues & be a possible SRv6 compression solution.

It would be useful to have a section on 1+1 path protection mechanism
graphical depiction with PSID/BSID sub-paths similar to my SR-MPLS path
draft comment.



*PCE SR extension for PSID path Segment  Comments:*

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-path-segment-04

Draft is well written.  No comments



*PCE SR extension for BIDIR PSID Path Segment Comments:*

https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-bidir-path

Draft is well written.  No comments



*SR Policy Path Segment Comments:*

https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-path-segment

Draft is well written.  No comments

Kind Regards

Gyan

James Guichard [e-mail] via
<https://support.google.com/mail/answer/1311182?hl=en> ietf.org
Wed, Jul 7, 11:49 AM
to [e-mail], [e-mail]

Dear WG:



This email starts a 2 week Working Group Last Call for
draft-ietf-spring-mpls-path-segment [1].



Please read this document if you haven’t read the most recent version and
send your comments to the SPRING WG list no later than July 21st 2021.



If you are raising a point which you expect will be specifically debated on
the mailing list, consider using a specific email/thread for this point.



Lastly, if you are an author or contributor please response to indicate
whether you know of any undisclosed IPR related to this document.



Thanks!



Jim, Joel & Bruno



[1] https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*