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

From: Gyan Mishra <[email-masked]>
Date: Mon, 27 Sep 2021 17:04:01 -0400

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 [email-masked] via
<https://support.google.com/mail/answer/1311182?hl=en> ietf.org
Wed, Jul 7, 11:49 AM
to [email-masked], [email-masked]

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 [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Tue, 28 Sep 2021 11:51:54 +0000

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:[email-masked]]
Sent: Tuesday, September 28, 2021 5:04 AM
To: SPRING WG <[email-masked]>; [email-masked]; j00406941 <[email-masked]>; [email-masked]; [email-masked]
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! ☺
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.

SR Path Segment drafts:
SR-MPLS Path Segment

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/>

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.

SR-MPLS Path Segment - WGLC Review:

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.

·         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.

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 ☺

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!!!

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.

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

   [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!

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 ☺

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.

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 [email-masked]<mailto:[email-masked]> via<https://support.google.com/mail/answer/1311182?hl=en> ietf.org<http://ietf.org>

Wed, Jul 7, 11:49 AM

[https://mail.google.com/mail/u/0/images/cleardot.gif]
[https://mail.google.com/mail/u/0/images/cleardot.gif]

to [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>
[https://mail.google.com/mail/u/0/images/cleardot.gif]

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

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 30 Sep 2021 01:28:55 -0400

Hi Chengli

Very welcome!

Response in-line

Kind Regards

Gyan

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.

Respect,

Cheng

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

Dear Rakesh & Authors

[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

SRv6 Path Segment

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

SR Policy Path Segment

[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.

> [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
>
>
>
> 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.
>
>
>
>  [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.
>
>
>
>  Gyan> Welcome!
> 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.
>
>    [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.”
>
>
>
> [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 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
>
>
>
>  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.
>
> 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.
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*