Hi Bruno,
Please see my reply inline. I provide some text to address your comments, any
suggested text is appreciated
Thanks,
Cheng
-----Original Message-----
From: bruno.decra...@orange.com <bruno.decra...@orange.com>
Sent: Friday, October 6, 2023 11:12 AM
To: Cheng Li <c...@huawei.com>; Stewart Bryant <stewart.bry...@gmail.com>
Cc: Xipengxiao <xipengx...@huawei.com>; spring@ietf.org
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?
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 <spring-boun...@ietf.org> On Behalf Of Cheng Li
Sent: Thursday, October 5, 2023 6:33 PM
To: spring@ietf.org
Cc: Xipengxiao <xipengx...@huawei.com>
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 <spring-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org
Sent: Thursday, October 5, 2023 6:25 PM
To: i-d-annou...@ietf.org
Cc: spring@ietf.org
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
____________________________________________________________________________________________________________
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.
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
