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

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 16 September 2019 09:01 UTC

Return-Path: <dhruv.ietf@gmail.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 DFC6612002E; Mon, 16 Sep 2019 02:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 0X_SZb5vvop9; Mon, 16 Sep 2019 02:01:43 -0700 (PDT)
Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9488E120019; Mon, 16 Sep 2019 02:01:43 -0700 (PDT)
Received: by mail-io1-xd43.google.com with SMTP id f12so76821684iog.12; Mon, 16 Sep 2019 02:01:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IPrFuGGABU6azysx+S4Z5ruInccLtn5Le7Vj2Z1sGVc=; b=kxVOI4uFbv45bR0TeD0I7oXMfjDEc0dkKdEyIpOkYe4Nf0Gz2jgsH8RRqTAUnJvDsK wdU+5zcpcoEBqu2w07FB/clNzr56z7Y3fbzeZ2Q6fET6nz1o5b40M3lkLn3Uj78WLUJ7 znCw9myknUzoyRj9pP+yj/iyJA/+qvQHsIIVrX7r2jLWcTiMtULIdhesEUKy1yRl2jnr TVWuEitWyGkIQfYWWdcLmdK5hP8s1k0EZD6rB6utEUAt0dIvxo+UJCPpbekMrcq+5tyq 25d4Nd5+9ifevTymuz5sVnt0gDY3WOb39uyU2Yuunz+O2qMaUwyOrhse0URHBN2ypKoh Q2Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IPrFuGGABU6azysx+S4Z5ruInccLtn5Le7Vj2Z1sGVc=; b=nPhqj/ixhvhfRsKf7xMLLP0FedIaPDvmkEwzPVqeCd9RiZnFBzFNVDnOdhbdnSuwKL zYTjDZ8r43F2bxkPwzsUaI3+Lp18XKUZCPVhKtMYqxV7Qz5hXw9ij9XgTBlTnvV4LyyU uShzlCb5+cDfVX+vSWHoDqOr46GG6s7/zFeIeLOq1Z4kuZPRF6Fm6wnM3ho3m7frES6v CYa97/eOM5IF/Biye8kcfdz5B5qzed0arl48uaH+jIBuOKqbHE74B17G7v1+x/Jsm+u5 gUCjezJB4MKPhPZxsS46wKaNwxnuxv9JdYcbpD+qTN+7zcs9ljICUMzN+fPAwngENYeB AS4g==
X-Gm-Message-State: APjAAAUBvx0R21PhWkJz31aG+F1Q1kjm6T8OkxB9UvvBK17EMqHOD7eO tVN/JLN31FKD7l2APl+zsj3Ae10vgkGwyT8PZ5k=
X-Google-Smtp-Source: APXvYqwBTgMspJaHBRdzTJKZXrgfMoeLKsuEqgdi6DEEBU5G6CM7Wn8UBsuMu7qfxFUeyjQb8vBXKcOBE4l8Geoi7UU=
X-Received: by 2002:a6b:b78b:: with SMTP id h133mr14366808iof.276.1568624502574; Mon, 16 Sep 2019 02:01:42 -0700 (PDT)
MIME-Version: 1.0
References: <CAB75xn68Ex0TUVQAWKw8K+yfWDV4TG==+WUy4ojF4rB7Oa=Xhg@mail.gmail.com> <201909161641345810418@zte.com.cn>
In-Reply-To: <201909161641345810418@zte.com.cn>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 16 Sep 2019 14:31:05 +0530
Message-ID: <CAB75xn5mR9a+yOcohha_8FgzRBhV5Xz767CTd5W7Y-6DWfMFXg@mail.gmail.com>
To: xiong.quan@zte.com.cn
Cc: Loa Andersson <loa@pi.nu>, Tarek Saad <tsaad.net@gmail.com>, mpls@ietf.org, draft-xiong-mpls-path-segment-sr-mpls-interworking@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/aXQ2C1fUK_5Mme7FxSngyRPHxUg>
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: Mon, 16 Sep 2019 09:01:46 -0000

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@ietf.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-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!
>
> 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
>
>