Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

Gyan Mishra <hayabusagsm@gmail.com> Mon, 29 March 2021 13:50 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943813A1330; Mon, 29 Mar 2021 06:50:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oodQXy_JYTq5; Mon, 29 Mar 2021 06:50:52 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 5A6773A132F; Mon, 29 Mar 2021 06:50:52 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id kr3-20020a17090b4903b02900c096fc01deso5941264pjb.4; Mon, 29 Mar 2021 06:50:52 -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; bh=F0GigEG8lYmv84FKxk07R/4tggx1bmYkdiaI2L6+xXI=; b=ntYtE1pRaYJWae1UWazpA0TU8+t+SrZv/IITNktb0ediXt9ZqNkIske9i4VDXOluf+ n8ZmxIOwqRYfUb9l1a/N3ElSasRyD7xSUoZkMq4pQZezuMq6B4awlPEif2rMg2OoSNBM JdKA/DHIWo9Uc8BVAdfBPhMxjVzimcl1Pu7+qiRuDERkFftIvwXVMwO4JvhXP9y6EHg9 sW+B66XfzAeDEroschxNYwXKnqmrDocf9DmXXthhhfVhMTGQsNoY9eoB67xyJwnkqeO1 1FTI4aRao5aCu8KeZxlqpuTCNH6QV7m2WTywn//mDeCPOKUIbmYLTUZbIylRb/AbCc9S Z+rw==
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; bh=F0GigEG8lYmv84FKxk07R/4tggx1bmYkdiaI2L6+xXI=; b=BsAJTIjuxrRj6TapSjZnGrDuonqCme1VV4DFF+BT8Vf3w2KEFdeX3vsbNXDT5TwdhY lHO0TmejAgmbW2OaiUf/PYlWK9+Vbwiza9FD/KRF7HUOCW/Xfae5cX5MC4ITpl7EwArx 1P1Z8Nd1sRWTUZhRn453JK/mk93d2R8JIPjkhPyQkN4rGpDGMInt/kI4Qx8mFeTS2lNY ZZ03GpxMUHFdhFCQNaNLDqa1pWB8jNhZCcaSiIFnazXeGw3Myi9n0grPH4cc8dSCkfq3 kO0xtJEPT7YA8SX+rgZz+dQuk101SNFt3LlIQ6Z2leCxDRj7rTtPbSvO18ZMyMs9RCpa ONTQ==
X-Gm-Message-State: AOAM530hmHyHFqJPrbnQRf1yBt83Mhjodw78j8u+k1e1HC+GbaSmG8Ec g4fwJMwGuJSEG8Tg9Db45wgZoSENNiGqDnFeaQ8=
X-Google-Smtp-Source: ABdhPJyrCqr+omOCHax5RSOfDz0Z59MH7zL3aUTMrbLZNo2K//sbykcm0ejzHs33QbXciXutLoDg6Ez2YE1ork6RYAY=
X-Received: by 2002:a17:90a:7a8b:: with SMTP id q11mr26951336pjf.215.1617025850665; Mon, 29 Mar 2021 06:50:50 -0700 (PDT)
MIME-Version: 1.0
References: <7010_1616065722_605334BA_7010_19_1_3f1d8d24-af98-f962-95ea-0e6ec46b738c@orange.com> <375C800D-2014-4D14-830E-0D15439B9F20@nokia.com> <a2f9686490a34a39af5f977cf59230b7@huawei.com> <B3B06655-1F99-416A-AF8F-9FA53E6DB0BB@nokia.com> <be741e7913304da8a3afd9b1f3cbd1fb@huawei.com> <CABNhwV044vY4tQP6OJhwDWAkMYnD+i=OVKURb1y8eJeMLSHL_A@mail.gmail.com> <CANJFx2T8ZBucUDM+D5UrJ-eF_EKA3Y-Qd2R-6ksX5U_vDJJzhw@mail.gmail.com> <CABNhwV2anNySChRZ_SyE4Fx6+0CeU=R+ZzLPDM3BDhspkOUZMw@mail.gmail.com> <CANJFx2TPPP6ffisALzgkHh6q_x9CpxyxZbf+qiPx62dCbd_RrA@mail.gmail.com> <CABNhwV3ZgXhGwO56fz4Wxz2tYT9DW14KmB_v8q4sf-mLUkZDWw@mail.gmail.com> <DM6PR11MB3802D4EB230F0B94546EF400D37E9@DM6PR11MB3802.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3802D4EB230F0B94546EF400D37E9@DM6PR11MB3802.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 29 Mar 2021 09:50:39 -0400
Message-ID: <CABNhwV1a+z-JWx9p=MXeq-F=qcTdXz-Nu40K3_9G2tR=TkAcJQ@mail.gmail.com>
To: "Mike Koldychev (mkoldych)" <mkoldych@cisco.com>
Cc: Siva Sivabalan <msiva282@gmail.com>, "Stone, Andrew (Nokia - CA/Ottawa)" <andrew.stone@nokia.com>, "draft-ietf-pce-binding-label-sid@ietf.org" <draft-ietf-pce-binding-label-sid@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/related; boundary="0000000000006c42ae05bead2bbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/KBjDKFW0aUyEef7n1Lzl4jpdUHw>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 13:50:58 -0000

Hi Mike

Is the usage for BSID only for control plane signaling as I described it.

What other use cases exist and maybe we should add to the draft.

Thanks

Gyan

On Mon, Mar 29, 2021 at 4:50 AM Mike Koldychev (mkoldych) <
mkoldych@cisco.com> wrote:

> Hi,
>
>
>
> I think that BSID is a concept that applies equally well to RSVP-TE and
> SR-TE. There are many use-cases for RSVP tunnels having a BSID and we
> definitely DO NOT want to limit it to just SR-TE.
>
>
>
> Thanks,
>
> Mike.
>
>
>
> *From:* Pce <pce-bounces@ietf.org> *On Behalf Of * Gyan Mishra
> *Sent:* Sunday, March 28, 2021 7:53 PM
> *To:* Siva Sivabalan <msiva282@gmail.com>
> *Cc:* pce@ietf.org; draft-ietf-pce-binding-label-sid@ietf.org; Stone,
> Andrew (Nokia - CA/Ottawa) <andrew.stone@nokia.com>
> *Subject:* Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
>
>
>
>
>
> Hi Siva
>
>
>
> I believe  I was missing the signaling aspect for the PCE to build the
> contiguous end to end LSP and that requires BSID to be signaled over
> RSVP-TE which is although agnostic to data plane BSID component binding the
> candidate path to the forwarding plane, is a requirement for end to end
> control plane signaling for the single LSP end to end path instantiation.
>
>
>
> The BSID signaling concept is somewhat analogous concept to LDP tunneling
> over RSVP-TE tunnel stitching for an end to end LSP instantiation.
>
>
>
> Thank you Siva for the clarification.
>
>
>
> Gyan
>
>
>
> On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan <msiva282@gmail.com> wrote:
>
> Hi Gyan,
>
>
>
> This ID is all about signaling BSID for RSVP-TE tunnels and SR policies
> via PCEP.
>
>
>
> Please do not confuse signaling aspects with how BSID is used.
>
>
>
> There is no change required in the ID.
>
>
>
> Thanks,
>
> Siva
>
>
>
>
>
> On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
>
> All
>
>
>
> After further review with Siva the use case is for connecting SR islands
> over RSVP-TE core.
>
>
>
> So this is for stitching SR-TE on the edge islands binding SID to core
> RSVP-TE tunnel.
>
>
>
> One major gap  of RSVP-TE is the VRF / VPN coloring capability that in
> order to achieve per VRF coloring mapping of VRF to a discrete TE tunnel
> requires a separate loopback and static routes to egress PE so it does not
> scale.  So for as many RSVP mapped tunnels that exist you need that many
> loopbacks and static routes for the next hop rewrite to the RSVP tunnel
> next hop.
>
>
>
> So this Major gap is filled with SR VRF and app flow coloring capability
> that with SR-TE Policy BSID bound to candidate path can provide the
> scalability per VRF coloring.
>
>
>
> So at the edges you may have many 100s of colored RSVP tunnels but as the
> core does not scale you can not provide a 1-1 mapping of SR-TE tunnel to
> RSVP tunnel.  So you would have many to 1 mappings of SR-TE tunnels to
> single or aggregate.
>
>
>
> So in my mind to only way the BSID would come into play is if you could do
> a 1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not
> possible.
>
>
>
> For PCE to compute end to end path in this scenario does RSVP-TE require
> the BSID for the stitching even if a many SR-TE colors to single RSVP-TE
> tunnel mapping. I would not think so.
>
>
>
> If we think that for PCE to build the end to end path even for the end to
> end path in this scenario requires BSID binding to the RSVP-TE single path
> to make contiguous end to end then I agree technically we do need to make
> this inclusive of RSVP-TE.
>
>
>
> I think we need to clear this up and if this use case is really not
> feasible then we should remove any mention of BSID use with RSVP-TE tunnel.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan <msiva282@gmail.com> wrote:
>
> Hi Gyan,
>
>
>
> BSID can be allocated for RSVP-TE as well, and yes, there are use-cases
> for that. The proposed PCEP extension is equally applicable to both SR-TE
> and RSVP-TE.
>
>
>
> Thanks,
>
> Siva
>
>
>
> On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
>
>
>
> I support WG LC advancement of this draft for publication.
>
>
>
> I see there are a lot of comments related to a mix of verbiage related to
> MPLS label binding and Binding label SID confusion.
>
>
>
> Few comments.
>
>
>
> The draft title states “carrying binding label/sid in PCE based networks”
>
>
>
> In the abstract it states it is possible to associate a BSID with a RSVP
> signaled path.
>
>
>
> I don’t recall any RSVP extension to support concept of BSID usage on an
> active Candidate Path option ERO.  Can you refer me to the RFC that states
> how BSID is used with RSVP TE.
>
>
>
> For more clarity with this draft can we replace
>
>
>
> s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion
> where SR is SR.  When mentioned traffic engineered path please spell out or
> say SR path for clarity.
>
>
>
> Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”.
>
>
>
> The word “binding” is very confusing as it’s used interchangeably with
> label binding and binding SID.
>
>
>
> So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID
> TLV”.  Makes it clear and concise the TLV is for SR-TE.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) <c.l@huawei.com> wrote:
>
> Thanks again for your help!
>
> Cheng
>
>
>
> -----Original Message-----
> From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com]
> Sent: Saturday, March 27, 2021 2:42 AM
> To: Chengli (Cheng Li) <c.l@huawei.com>om>; julien.meuric@orange.com;
> pce@ietf.org
> Cc: draft-ietf-pce-binding-label-sid@ietf.org
> Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07
> (and Code Point Allocation)
>
> Hi Cheng,
>
> Thanks for clarifying the text in the document. Diff content looks good to
> me, much clearer. Consider my comments resolved.
>
> Thanks!
> Andrew
>
> On 2021-03-25, 10:49 PM, "Pce on behalf of Chengli (Cheng Li)" <
> pce-bounces@ietf.org on behalf of c.l@huawei.com> wrote:
>
>     Hi Andrew,
>
>     Thanks for your comments, please see my reply inline.
>
>     Also, the diff is attached.
>
>     Respect,
>     Cheng
>
>
>
>
>     -----Original Message-----
>     From: Stone, Andrew (Nokia - CA/Ottawa) [mailto:andrew.stone@nokia.com]
>
>     Sent: Saturday, March 20, 2021 4:21 AM
>     To: julien.meuric@orange.com; pce@ietf.org
>     Cc: draft-ietf-pce-binding-label-sid@ietf.org
>     Subject: Re: [Pce] WG Last Call for
> draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)
>
>     Hi all,
>
>     Overall Support WGLC. It's an important document in the world of SRTE,
> and the document goes to good lengths to describe the various scenarios and
> combinations.
>
>     Only one question I have for the authors and WG, for any further
> clarification on the following text (section 4):
>
>
>       The absence of TE-PATH-BINDING TLV in PCUpd message
>        means that the PCE does not specify a binding value in which case
> the
>        binding value allocation is governed by the PCC's local policy.
>
>
>     I find the "governed by PCC local policy" a bit too vague and could
> lead to implementation interop differences. Assuming a PCInitiated LSP that
> been established with a BSID: If the PCE wants to withdraw the binding SID
> , I interpret the document as the PCE would send a PCUpdate without the
> TLV, but the behaviour is now up to PCC as per that text. if the PCC local
> policy/implementation is to do nothing, how can the PCE explicitly
> force-remove the BSID with a PCUpdate? In a similar manner, If the PCE does
> not want to change the value but PCC local policy is to treat missing TLV
> as remove, then PCE should always send the TLV in every PCUpdate (which I'm
> okay with) which is not stated, otherwise the local policy/implementation
> may interpret it as a removal compared to an implementation which may
> interpret it as being okay to not send the TLV on every PCUpdate since
> there was "no change".
>
>     In summary: might need a bit of a wording to further detail "PCE
> wishes to withdraw" case.
>
>     [Cheng] You are correct, there was some issues with multiple
> TE-PATH-BINDING TLV. This has been updated. See the diff.
>
>     The above text has been updated to -
>
>        The absence of TE-PATH-BINDING TLV in PCUpd message means that the
>        PCE does not specify a binding value in which case any previous
>        allocated binding values are withdraw.
>
>     Further, the PCC's local policy aspect has been seperated out as -
>
>        In the absence of any instruction from the PCE, the PCC's local
>        policy dictates how the binding allocations are made for a given
> LSP.
>
>     Thanks!
>
>
>     Thanks!
>     Andrew
>
>     On 2021-03-18, 7:09 AM, "Pce on behalf of julien.meuric@orange.com" <
> pce-bounces@ietf.org on behalf of julien.meuric@orange.com> wrote:
>
>         Hi all,
>
>         This message initiates a 2-week PCE WG Last Call for
>         draft-ietf-pce-binding-label-sid-07. Please review and share your
>         feedback, whatever it is, using the PCE mailing list. This WGLC
> will end
>         on Thursday April 1st (no kidding).
>
>
>         Moreover, we have received a request from the authors for a code
> point
>         allocation to support interoperability testing.
>
>         RFC 7120 requires to meet the following criteria to proceed:
>
>         b. The format, semantics, processing, and other rules related to
>         handling the protocol entities defined by the code points
>         (henceforth called "specifications") must be adequately described
>         in an Internet-Draft.
>         c. The specifications of these code points must be stable; i.e., if
>         there is a change, implementations based on the earlier and later
>         specifications must be seamlessly interoperable.
>
>         If anyone believes that the draft does not meet these criteria, or
>         believes that early allocation is not appropriate for any other
>         reason, please send an email to the PCE mailing list explaining
> why. If
>         the chairs hear no objections by Thursday, March 25th, we will
> kick off
>         the "early" allocation request.
>
>         Thanks,
>
>         Dhruv & Julien
>
>
>
> _________________________________________________________________________________________________________________________
>
>         Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
>         pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu ce message par erreur, veuillez le signaler
>         a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration,
>         Orange decline toute responsabilite si ce message a ete altere,
> deforme ou falsifie. Merci.
>
>         This message and its attachments may contain confidential or
> privileged information that may be protected by law;
>         they should not be distributed, used or copied without
> authorisation.
>         If you have received this email in error, please notify the sender
> and delete this message and its attachments.
>         As emails may be altered, Orange is not liable for messages that
> have been modified, changed or falsified.
>         Thank you.
>
>         _______________________________________________
>         Pce mailing list
>         Pce@ietf.org
>         https://www.ietf.org/mailman/listinfo/pce
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: Image removed by sender.] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*