Re: [spring] I-D Action: draft-ietf-spring-mpls-path-segment-15.txt

[[e-mail]]

Hi Cheng,

Thanks for your reply.
Please see inline [Bruno]

>
> From: Cheng Li <[e-mail]>
> Sent: Friday, October 6, 2023 12:07 PM
>
> Hi Bruno,
>
> Please see my reply inline. I provide some text to address your comments, any suggested text is appreciated
>
> Thanks,
> Cheng
>
>

Orange Restricted

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Friday, October 6, 2023 11:12 AM
> To: Cheng Li <[e-mail]>; Stewart Bryant <[e-mail]>
> Cc: Xipengxiao <[e-mail]>; [e-mail]
> Subject: RE: [spring] I-D Action: draft-ietf-spring-mpls-path-segment-15.txt
>
> [+Stewart]
>
> Thank you Stewart for your review and thank you Cheng for the updated draft.
>
> 1 comment on the new section "2.1.  Equal-Cost Multipath Considerations"
>
> > It is worthy to note that when EL labels are used in packets, the forwarding path of packets may be different due to load balancing. In this case, the SID list (without Entropy Label Indicator and Entropy Label) cannot directly reflect the actual forwarding path.
>
> Regarding 1rst sentence, I'm not sure whether you mean either:
> - different compared to not using EL
> - different depending on the actual EL label (i.e. multiple paths are used for a given SR policy)
> - both
> - something else
> [Cheng]different compare to not using EL, yes, if it will steer the packets to another link/path comparing to the original one. Different depending on the actual EL label, yes for sure. See below text.
>
>
> Regarding 2nd sentence, you seem to say that without EL, there is no ECMP forwarding. I'm not sure to agree with this. (e.g. some implementations looks beyond the MPLS label stack and hash based on the (assumed) IP packet header if they believe that this is an IP packet).
> That would seem to imply that the path segment does not identify a "forwarding path" but an "SR path" (as per §1 & §2). The latter could follow different forwarding paths in case of ECMP.
>
> [Cheng]Ha, I see your point, it is valid. How about the following modification? Your proposed text will be very appreciated.
>
> __OLD__
> It is worthy to note that when EL labels are used in packets, the forwarding path of packets may be different due to load balancing. In this case, the SID list (without Entropy Label Indicator and Entropy Label) cannot directly reflect the actual forwarding path. Therefore, a PSID can only identify the SID list (without Entropy Label Indicator and Entropy Label) instead of the actual forwarding path.
>
> __NEW__
> It is worthy to note that when an Entropy label is used in packets, the forwarding path of packets may be different comparing to the original one that not using the entropy label. When using different Entropy labels in the packets, the forwarding path of packets may be different also due to load balancing. In this case, the SID list (without Entropy Label Indicator and Entropy Label) cannot directly reflect the actual forwarding path of the packets using EL. Similarly, when other ECMP mechanisms are using, the actual forwarding path cannot be identified by the SID list. Therefore, a PSID can only identify the SID list instead of the actual forwarding path in ECMP scenarios.
>
> Thoughts?

[Bruno] I feel that this could be summarized as the ECMP point is the same with or without EL. Reusing your OLD text as input, I would propose:
NEW: It is worthy to note that in case of ECMP, with or without the use of EL, the SR Path may be forwarded over multiple paths. In this case, the SID list cannot directly reflect the actual forwarding path and the PSID can only identify the SID list rather than the actual forwarding path.

Possibly " with or without the use of EL," could also be removed. Up to you.

Thanks
Regards,
--Bruno


>
> May be it would be an interesting precision to add in section 2.
> Especially given some of the expressed use cases (e.g. §3.1 Performance measurement). I also believe this is along the comments already expressed by Stewart but I won't speak for him.
>
> Thanks,
> Regards,
> --Bruno
>
>
> Orange Restricted
>
> -----Original Message-----
> From: spring <[e-mail]> On Behalf Of Cheng Li
> Sent: Thursday, October 5, 2023 6:33 PM
> To: [e-mail]
> Cc: Xipengxiao <[e-mail]>
> Subject: Re: [spring] I-D Action: draft-ietf-spring-mpls-path-segment-15.txt
>
> Hi SPRING,
>
> This update addressed the comments from Stewart, many thanks to Stewart for your professional review.
>
> Main updates:
> * Reorganized the content of section 2, making ECMP consideration as a sub-section
> * Added info references for helping readers understand how a Path Segment will be used in control plane.
> * Added a Path Segment of sub-path in illustration for better understanding.
> * Refined security consideration section
> * Some editorial modifications
>
> Thanks to the experts who have paid attention to this draft. Your comments make the draft better significantly.
>
> Comments are welcome.
>
> Respect,
> Li Cheng
>
> -----Original Message-----
> From: spring <[e-mail]> On Behalf Of [e-mail]
> Sent: Thursday, October 5, 2023 6:25 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [spring] I-D Action: draft-ietf-spring-mpls-path-segment-15.txt
>
> Internet-Draft draft-ietf-spring-mpls-path-segment-15.txt is now available. It is a work item of the Source Packet Routing in Networking (SPRING) WG of the IETF.
>
   > Title:   Path Segment in MPLS Based Segment Routing Network
   > Authors: Weiqiang Cheng
            > Han Li
            > Cheng Li
            > Rakesh Gandhi
            > Royi Zigler
   > Name:    draft-ietf-spring-mpls-path-segment-15.txt
   > Pages:   17
   > Dates:   2023-10-05
>
> Abstract:
>
   > A Segment Routing (SR) path is identified by an SR segment list.  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), and end-to-end 1+1 path protection.
>
   > In SR for MPLS data plane (SR-MPLS), an Egress node can not determine
   > on which SR path a packet traversed the network from the label stack
   > because the segment identifiers are stripped from the label stack as
   > the packet transits the network.
>
   > This document defines Path Segment to identify an SR path on the
   > egress node of the path.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-spring-mpls-path-segment-15.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-mpls-path-segment-15
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.