Re: [mpls] [MPLS]Comments aboutdraft-xiong-mpls-path-segment-sr-mpls-interworkinganddifferencebetween Path Segment and BSID

<xiong.quan@zte.com.cn> Wed, 25 September 2019 09:48 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F06F12011D; Wed, 25 Sep 2019 02:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEdY0IeagNhd; Wed, 25 Sep 2019 02:48:55 -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 43771120120; Wed, 25 Sep 2019 02:48:55 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id EBD3289F2B415E1EEA98; Wed, 25 Sep 2019 17:37:08 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id DC47598BEA53629378F9; Wed, 25 Sep 2019 17:37:08 +0800 (CST)
Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse-fl1.zte.com.cn with SMTP id x8P9ZXLD055892; Wed, 25 Sep 2019 17:35:33 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Wed, 25 Sep 2019 17:35:32 +0800 (CST)
Date: Wed, 25 Sep 2019 17:35:32 +0800 (CST)
X-Zmail-TransId: 2afd5d8b34e44497b239
X-Mailer: Zmail v1.0
Message-ID: <201909251735328092982@zte.com.cn>
In-Reply-To: <CAB75xn55E3MaehSNJXwytr_WjZfKRu89HAE99U-Tt=9EPZ_2nA@mail.gmail.com>
References: CAB75xn5mR9a+yOcohha_8FgzRBhV5Xz767CTd5W7Y-6DWfMFXg@mail.gmail.com, CAB75xn55E3MaehSNJXwytr_WjZfKRu89HAE99U-Tt=9EPZ_2nA@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-fl1.zte.com.cn x8P9ZXLD055892
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/iI0UN5aWmwJN5qhuS2-tsJ1tGhw>
Subject: Re: [mpls] =?utf-8?q?=5BMPLS=5DComments_aboutdraft-xiong-mpls-path-s?= =?utf-8?q?egment-sr-mpls-interworkinganddifferencebetween_Path_Segment_an?= =?utf-8?q?d_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: Wed, 25 Sep 2019 09:48:59 -0000

Hi Dhruv and Cheng,






Thanks for your reply! Sorry to reply late!


I agree with you about that using  *BOTH* path segment and binding segment mentioned by Dhruv and


using Path Segment for intra-domain OAM/PM and Binding SID for inter-domain path stitching mentioned by Cheng.


And this mechanism is sepcified in draft "draft-ietf-spring-mpls-path-segment" which has been adopted by Spring WG.


But I think it is just appropriate for nesting model as that draft defined and it proposed the nesting of Path Segments.






The solution is not appropriate for stitching model. The reasons are as follows.


a. In stitching models, the BSID is not appropriate. As defined in RFC8402, the headend of an SR Policy binds a BSID to its policy.


The BSID which  indicates the SID List and selected path of the next domain MUST be pushed in at the ingress node of the prev domain 


and popped out at the ingress node of next domain.  The path  information of two domains ate mixed together, It can not meet the requirement of stitching model.


b.Whatover,the internal information of one domain has been exposed to other domain. It is not appropriate when the domains belong to different operators.


c. In stitching models, I think all the labels in label stack need to be pushed in at the ingress nodes and be popped out at the egress nodes of each domain. 


We can not carry all the BSIDs at the ingress node of ingress domain as nesting model defined.


d. In stitching models, we proposed the stitching of Path Segments.  We proposed the Path segments correlation to realize the inter-domain stitching. And the inter-domain stitching 


is not just the SID List stitching but also the path stitching which can achieve path OAM/PM/protection.






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@ietf.org <draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org>;;
日 期 :2019年09月16日 17:41
主 题 :Re: Comments aboutdraft-xiong-mpls-path-segment-sr-mpls-interworkinganddifferencebetween Path Segment and BSID


Hi Quan,

On Mon, Sep 16, 2019 at 2:55 PM <xiong.quan@zte.com.cn>; wrote:
>
>
> Hi  Dhruv,
>
>
> Thanks for your quick reply!
>
>
> I agree with you that Binding SID can to be used not just for label stack but also stitching in multi-domain scenarios.
>
> The interworking scenario which we proposed also belongs to multi-domain scenarios, but as my last email mentioned,
>
> the Binding SID can not meet our requirement. For example, the bidirectional path correlation and  the per-segment or
>
> per-domain OAM/PM/protection can not be achieved by using  Binding SID.
>
>
> So could you please give us some suggestions to settle this issue?
>
>

I thought I did with -

  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