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

"Chengli (Cheng Li)" <chengli13@huawei.com> Tue, 17 September 2019 07:24 UTC

Return-Path: <chengli13@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7421200F8; Tue, 17 Sep 2019 00:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 OIa_DG3GZmGF; Tue, 17 Sep 2019 00:24:17 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 30B481200F7; Tue, 17 Sep 2019 00:24:17 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E94689F0435FF2F52432; Tue, 17 Sep 2019 08:24:13 +0100 (IST)
Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 17 Sep 2019 08:24:13 +0100
Received: from lhreml717-chm.china.huawei.com (10.201.108.68) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 17 Sep 2019 08:24:13 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 17 Sep 2019 08:24:13 +0100
Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.58]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0439.000; Tue, 17 Sep 2019 15:24:02 +0800
From: "Chengli (Cheng Li)" <chengli13@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, "xiong.quan@zte.com.cn" <xiong.quan@zte.com.cn>
CC: "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>
Thread-Topic: [mpls] Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID
Thread-Index: AQHVbG1wKbngt0uTtUGgjqPnpJcubacvcw5w
Date: Tue, 17 Sep 2019 07:24:01 +0000
Message-ID: <C7C2E1C43D652C4E9E49FE7517C236CB026DB60D@dggeml529-mbx.china.huawei.com>
References: <CAB75xn68Ex0TUVQAWKw8K+yfWDV4TG==+WUy4ojF4rB7Oa=Xhg@mail.gmail.com> <201909161641345810418@zte.com.cn> <CAB75xn5mR9a+yOcohha_8FgzRBhV5Xz767CTd5W7Y-6DWfMFXg@mail.gmail.com>
In-Reply-To: <CAB75xn5mR9a+yOcohha_8FgzRBhV5Xz767CTd5W7Y-6DWfMFXg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.130.185.75]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/JT21sYTimf7dTDyPBC50-aCZCSE>
Subject: Re: [mpls] Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between 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: Tue, 17 Sep 2019 07:24:20 -0000

Agree. Binding SID and Path Segment are both needed. 

There are no doubt that they have different functionalities and usages:

* Binding SID maps a SID to an SID list, and this mapping action will be done by the mapping node, which is the beginning of the NEXT path (represented by the SID lists). The mapping node is the ingress node of the associated path.

* Path SID  maps a SID to a SID list, and this mapping is used at control plane only, there will not be any new SID list to be inserted introduced by Path SID. The path segment will be processed by the egress node of the associated path.

If you combine these two SIDs into one, then troubles come. The OAM/PM based on Path Segment will dependent on the other domains, since this path segment also identify the next path in the next domain. But the OAM/PM should be domain-independent.  

How to solve this?
Use Path Segment for intra-domain OAM/PM
Use Binding SID for inter-domain path stitching.

Best, 
Cheng



-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Dhruv Dhody
Sent: Monday, September 16, 2019 5:01 PM
To: xiong.quan@zte.com.cn
Cc: mpls@ietf.org; draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org
Subject: Re: [mpls] Comments about draft-xiong-mpls-path-segment-sr-mpls-interworkingand difference between Path Segment and BSID

Hi Quan,

Thanks for your email..

On Mon, Sep 16, 2019 at 2:12 PM <xiong.quan@zte.com.cn> wrote:
>
>
> 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.
>

But Binding SID was meant to be used not just for label stack reduction, but also for multi-domain scenarios.

See -
https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-00#section-1
https://tools.ietf.org/html/draft-filsfils-spring-sr-policy-considerations-03#section-6

The key question is - Why are you NOT using binding segment for stitching? I think you try to explain that below -

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

May be you need to use *BOTH* path segment and binding segment then!!
But associating the functionality of a binding SID to a path SID is not correct!

Thanks!
Dhruv

>
> 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,
>
> Quan
>
>
>
>
> 原始邮件
> 发件人:DhruvDhody <dhruv.ietf@gmail.com>
> 收件人:熊泉00091065;
> 抄送人: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@iet
> f.org <draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org>;
> 日 期 :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-d
> omain-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!
>
> Thanks!
> Dhruv
>
> 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,
>>
>> Quan
>
>

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