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

[Gyan Mishra <[e-mail]>]

Hi Chengli

Very welcome!

Response in-line

Kind Regards

Gyan
On Tue, Sep 28, 2021 at 7:51 AM Chengli (Cheng Li) <[e-mail]> wrote:

> Hi Gyan,



Many thanks for your comments. Please see my reply inline.



However, I have not answer all the comments yet. I think it will be better
to separate the comments into different threads, and we can address them
one by one.

Again! Thank you for your comments!



Respect,

Cheng







*From:* Gyan Mishra [mailto:[e-mail]]
*Sent:* Tuesday, September 28, 2021 5:04 AM
*To:* SPRING WG <[e-mail]>; [e-mail]; j00406941 <
[e-mail]>; [e-mail];
[e-mail]
*Subject:* RE: [Spring] WGLC for
https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/




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.

[Cheng] Many thanks for your support! Yes, Path Segment can be used in many
use cases like you mentioned. Well, they may not need to cite each other as
normative reference I think, we need to discuss one by one. The Data plane
extension drafts of SR-MPLS & SRv6 Path Segment are the basic drafts. They
can be the normative referred at the control plane drafts like PCE and BGP,
that is correct, and we believe we did it. If we miss some reference, you
are welcome to point it out, many thanks for your help! J

I think we do not need to make PCE draft as the normative reference of BGP
extension draft, and vice versa. Because they are not dependencies between
these two protocol. Informative reference is the correct choice.

 Gyan> Agreed.  Informative reference for the base drafts and normative for
the other drafts.

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

[Cheng] This has been adopted, and become
draft-ietf-spring-srv6-path-segment
<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-path-segment/>





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?

[Cheng] BSID is using for shortening the SID list, while the Path Segment
will not be used for this. It is an ID space for path associated services.

 Gyan> My thoughts are BSID binds the candidate path to the forwarding
plane & for inter-as stitching of E2E SR-policy for candidate paths being
instantiated by BSID representing the SID list.  However, that is normal
processing.  BSID bound to the candidate path can be used as a pointer to
reference the SID list so that directing traffic to the SR policy.  So that
any node along the path only need to impose the BSID.  Section 4 first
sentence says the BSID can be used for SID compression.  See above BSID
describtion.

In Section 4 Figure 2 sub paths, here is an example  to define a compressed
version of an E2E path (  (s-PSID1,B-SID) ,(s-PSID2,,BSID2),
(s-PSID3,B-SID3) , e-PSID) E2E path.
    For compression my thoughts are maybe the PSID sub path as it defines
the SID list in a compressed format is my impression from reading the draft
it could be utilized for SID compression to alleviate MSD issues.  Maybe a
SID list with a very long E2E path can be subdivided into sup paths defined
by PSID in the SR-MPLS forwarding plane label stack reducing the size of
the overall E2E stack.  This idea would use PSID compression encoding for
SID list in the label stack instantiated on the source node different from
this draft bottom label use cases.

> *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.
>
>
>
> [Cheng] Using BSID can shorten the SID list. In case like BFD echo mode,
> we may have two solutions to shorten the SID list.
>

  Gyan> Understood

> ·         Using BSID: Putting the BSID of the  reverse direction path at
> the end of the SID list to specify the reverse path.
>
> ·         Using PSID: Putting the PSID of the reverse direction path at
> the end of the SID list to specify the reverse path. In this case, the
> egress node should process the path Segment and encapsulate the reverse SID
> list for the packet. It can work.
>
>  Gyan> Understood. Good idea.
>
> 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.
>
>  [Cheng]thank you for your text, we will consider this J
>
>  Gyan> Welcome!
>
> 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.
>
>
>
> [Cheng]We will consider this at the next update, many thanks!!!
>
>  Gyan> Welcome!
>
> 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.
>
> [Cheng] I think we can separate the comments into different threads for
> discussion. So will answer your above comments in next email.
>
>  Gyan> Will look out for the email.
>
> 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.
>
> [Cheng] this is because of SR-MPLS draft was proposed before SRv6 draft.
> But we do not have dependencies between these two documents. So I think we
> can mention this in the draft as an informative reference, good!
>
>  Gyan> Agreed
>
> 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.
>
> [Cheng] Can add it in the next revision J
>
>
>
> *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.
>
> [Cheng] When considering using the PSID as a routing ID for compression, I think you can read the draft of PPR(Preferred Path Route). But doing so will need to maintain the per-path forwarding statement at nodes, which bring as back to the RSVP-TE I guess. So it will be another way, but not stateless SR.
>
>  Gyan> I was thinking of PSID for SRv6 similar idea as with SR-MPLS
> compression case using PSID as a new encoding of SID list in a compressed
> format version that defines the SR sub path being instantiated by the
> source node.  So in this case no state would exist.  Another idea was for
> inter-as where the path is compressed as s-PSID but can be automatically
> expanded into segment list during processing of active segment.  The idea
> would be similar to inter AS TE for crankback loose hop expansion RFC 4736.
>
> *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 Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*