[mpls] 答复: Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID

<xiong.quan@zte.com.cn> Mon, 16 September 2019 08:42 UTC

Return-Path: <xiong.quan@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CE888120863; Mon, 16 Sep 2019 01:42:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wiKy9wiULW22; Mon, 16 Sep 2019 01:42:35 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn []) (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 2DEF9120842; Mon, 16 Sep 2019 01:42:35 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown []) by Forcepoint Email with ESMTPS id C6AC46E9CA786FEE60A3; Mon, 16 Sep 2019 16:42:33 +0800 (CST)
Received: from njxapp02.zte.com.cn ([]) by mse-fl2.zte.com.cn with SMTP id x8G8fZG2051742; Mon, 16 Sep 2019 16:41:35 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Mon, 16 Sep 2019 16:41:34 +0800 (CST)
Date: Mon, 16 Sep 2019 16:41:34 +0800 (CST)
X-Zmail-TransId: 2afd5d7f4abe21fcf29a
X-Mailer: Zmail v1.0
Message-ID: <201909161641345810418@zte.com.cn>
In-Reply-To: <CAB75xn68Ex0TUVQAWKw8K+yfWDV4TG==+WUy4ojF4rB7Oa=Xhg@mail.gmail.com>
References: 201909121505032731162@zte.com.cn, CAB75xn68Ex0TUVQAWKw8K+yfWDV4TG==+WUy4ojF4rB7Oa=Xhg@mail.gmail.com
Mime-Version: 1.0
From: <xiong.quan@zte.com.cn>
To: <dhruv.ietf@gmail.com>
Cc: <loa@pi.nu>, <tsaad.net@gmail.com>, <mpls@ietf.org>, <draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org>
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x8G8fZG2051742
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/YbFKeVBfoXxJZ0qEBx3ssEz4svI>
Subject: [mpls] =?utf-8?b?562U5aSNOiBDb21tZW50cyBhYm91dCBkcmFmdC14aW9u?= =?utf-8?q?g-mpls-path-segment-sr-mpls-interworkingand_difference_between_?= =?utf-8?q?Path_Segment_and_BSID?=
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2019 08:42:42 -0000

Hi Dhruv,

Sorry to reply late! Sorry to misunderstand your comment!

I agree with you.  Path Segment and  Binding SID are different and each serve a specific purpose.

I think the use of the binding SID [RFC8402] is recommended to reduce the size of lable stack in our draft.

But the use of binding SID is not recommended to sticth the inter-domain instead of Path Segment.

The draft proposed two interworking models including Stitching (section-3.1) and Nesting (section-3.2).

For the stitching model, there is no end-to-end Path Segment, the end-to-end path across multiple domanins has been partitioned to several

domain segments and each domain segment is identified as an inter-domain Path Segment (i-Path). These i-Paths can be used to correlate the 

inter-domain paths whcih can be  stitched to an end-to-end path. In the headend node, the i-Path MUST bind the two unidirectional 

paths and correlate the bidirectional path. Moreover, each domain can accomplish the per-segment OAM, PM or protection by using the  i-Path.  

If we use Binding SID to stitch the inter-domain, the per-segment or per-domain OAM/PM/protection can not be achieved.

For the nesting model, an end-to-end Path Segment (e-Path) is existed and the end-to-end OAM/PM/protection can be accomplished by using e-Path.

In this model, sub-path Path Segment (s-Path) MAY also be defined and used to indicate the intra-domain path when the per-segment or per-domain

OAM, PM or protection is requried.  

In both models, the use of the binding SID [RFC8402] is also recommended to reduce the size of lable stack.

Best Regards,



发件人:DhruvDhody <dhruv.ietf@gmail.com>
抄送人:Loa Andersson <loa@pi.nu>;Tarek Saad <tsaad.net@gmail.com>;mpls@ietf.org <mpls@ietf.org>;draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org <draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org>rg>;
日 期 :2019年09月12日 18:18
主 题 :Re: Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID

Hi Quan,

Thanks for your mail and further discussion.

It is not about Path SID v/s Binding SID, both are needed and each serve a specific purpose.

The comment I made during 105 was that you are using Path SID to do the function of Binding SID!

See https://tools.ietf.org/html/draft-xiong-spring-path-segment-sr-inter-domain-00#section-3.1, where you say - 

  The border nodes should
  install the following MPLS data entries for Path segments:

    incoming label: i-Path
       outgoing label: the SID list of the next domain or link + next i-Path

Here you are not using Path SID for OAM/PM but for the functionality of Binding SID! That seems like a wrong thing to do!


On Thu, Sep 12, 2019 at 12:35 PM <xiong.quan@zte.com.cn> wrote:

Hi  all,

I noticed you proposed comments at the IETF#105 MPLS meeting to the draft "draft-xiong-mpls-path-segment-sr-mpls-interworking". Your comment and review is very appreciated!

The Path Segment defined in draft-ietf-spring-mpls-path-segment has been proposed and adopted in Spring WG.

The Path Segment is a path identification for Performance measurement and Bidirectional path correlation and End-to-end Path Protection.

The draft "draft-xiong-mpls-path-segment-sr-mpls-interworking" mainly focus on the SR and MPLS Interworking with Path Segment to provide

end-to-end bidirectional VPN service in inter-domain scenario. 

I noticed the Binding SID is also used in inter-domain scenario. I think the main difference is as follows:

Binding SID indicates a SID List. Selected path by replace the Binding SID to a SID List. Path Segment indicates a path, it can realize OAM,PM,protection. Selected path by path segment correlation.

Binding SID can not replace path segment in bidirectional path, OAM, PM and protection etc. If we use Binding SID, the per-segment or per-domain OAM/PM/protection can not be achieved.

I just start the discussion and comments and suggestions are very welcome!

Best Regards,