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

liu.aihua@zte.com.cn Tue, 27 July 2021 07:13 UTC

Return-Path: <liu.aihua@zte.com.cn>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A23A1A70; Tue, 27 Jul 2021 00:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuYxL1hCZhf9; Tue, 27 Jul 2021 00:13:33 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033893A1A6B; Tue, 27 Jul 2021 00:13:32 -0700 (PDT)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 22FED24B8D851EF78453; Tue, 27 Jul 2021 15:13:30 +0800 (CST)
Received: from kjyxapp02.zte.com.cn ([10.30.12.201]) by mse-fl1.zte.com.cn with SMTP id 16R7DGlt006195; Tue, 27 Jul 2021 15:13:16 +0800 (GMT-8) (envelope-from liu.aihua@zte.com.cn)
Received: from mapi (kjyxapp04[null]) by mapi (Zmail) with MAPI id mid13; Tue, 27 Jul 2021 15:13:16 +0800 (CST)
Date: Tue, 27 Jul 2021 15:13:16 +0800
X-Zmail-TransId: 2b0660ffb20ca9c0e7eb
X-Mailer: Zmail v1.0
Message-ID: <202107271513167475122@zte.com.cn>
In-Reply-To: <004a01d77f99$7a654520$6f2fcf60$@com>
References: MN2PR13MB42062237391D7BE769359D30D21A9@MN2PR13MB4206.namprd13.prod.outlook.com, MN2PR13MB42069709E689629DF389F860D2E49@MN2PR13MB4206.namprd13.prod.outlook.com, 1D62FF3C-148F-4C06-B81C-C0A842F916ED@gmail.com, 004a01d77f99$7a654520$6f2fcf60$@com
Mime-Version: 1.0
From: liu.aihua@zte.com.cn
To: chengweiqiang@chinamobile.com, stewart.bryant@gmail.com, spring@ietf.org
Cc: james.n.guichard@futurewei.com, spring-chairs@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 16R7DGlt006195
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/9QOmsmb-680j06VPhQ3VtmVOPAQ>
Subject: Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jul 2021 07:13:38 -0000

Hi Stewart & Weiqiang,


Thanks for Mr Stewart's comments, which are valuable for understanding the Path Segment.



And I agree Weiqiang's responses. One more thing I want to notice that Path Segment could balance the philosophy of SR and MPLS for Path capabilities, such as Path Policy or PM. These capabilities are instinct with SR-Path, it's very different with PW.






Regards,


Aihua







原始邮件



发件人:WeiqiangCheng
收件人:'Stewart Bryant';'James Guichard';
抄送人:spring@ietf.org;spring-chairs@ietf.org;
日 期 :2021年07月23日 16:06
主 题 :Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



Hi Stewart,


Thanks a lot for your comments.


Co-authors have discussed the comments and our feedback is inline below.


 


B.R.


Weiqiang Cheng



发件人: spring [mailto:spring-bounces@ietf.org] 代表 Stewart Bryant
发送时间: 2021年7月22日 22:06
收件人: James Guichard
抄送: Stewart Bryant; spring@ietf.org; spring-chairs@ietf.org
主题: Re: [spring] WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/




 


Once you find yourself needing to include path identifiers in an SR packet, I begin to wonder whether the segment routing design has gone off track.


 


In MPLS we have the ability in both PCE and RSVP to lay out end to end paths in such a way that the forwarding label is the path identifier. If you recall the MPLS-TP approach you could deduce everything about the packet’s origin and path from the arrival label which was not PHPed.



 


Assuming there are technical reasons why such a classic approach is not possible, I wonder why it is necessary to encode the path identifier within label stack itself with all of the constraints that imposes on the size and semantics of the identifier.



 


An alternative approach is to look at the meta/ancillary data work that is going on in MPLS and carry the path identifier below the bottom of stack.



 


[Co-authors] As we know, the meta/ancillary work just started for now, it may be an alternative solution in the future. The solution proposed in the draft was to address a real-world issue, there have been implementations and deployments.


 



At  its most basic level this analogous to the approach to constructing a Pseudowires, with an outgoing label stack, a control word (which can be an extended control word carrying the path information) and then the payload.



 


[Co-authors] From path identification point of view, the Path Segment has the similar function as PW Label, but the control word is not necessary. So, somehow, the path segment is simpler than PW solution, and more important, there is need to construct and maintain a PW for such purpose. 


 



Such an approach would allow the packet designer to carry either the identity of the path, or the actual set of labels use to construct the path, or the reverse path or some combination of these. The latter two approaches are more dynamic than the approach proposed in this draft and more in keeping with the fundamental design philosophy of SR.



 


[Co-authors] The Path segment concept has been actively discussed in SPRING when the idea was proposed, and now SR-MPLS and SRv6 Path segment are adopted by the WG. It is valuable for high quality services of the operators 


 


 


 



- Stewart



 







On 22 Jul 2021, at 14:02, James Guichard <james.n.guichard@futurewei.com> wrote:



 


Dear WG:



 


The WGLC for this document will be extended for a further 2 weeks ending August 4th 2021 so that feedback can be obtained from the WG. Other than the authors there has been little input so please respond on the mailing list with any comments etc. 



 


Thanks!



 


Jim, Joel & Bruno



 



From: James Guichard <james.n.guichard@futurewei.com> 
Sent: Wednesday, July 7, 2021 11:49 AM
To: spring@ietf.org
Cc: spring-chairs@ietf.org
Subject: WGLC for https://datatracker.ietf.org/doc/draft-ietf-spring-mpls-path-segment/





 


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/



 


 


 


 


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring