Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.

Dhruv Dhody <dd@dhruvdhody.com> Fri, 12 February 2021 02:00 UTC

Return-Path: <dd@dhruvdhody.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 0BA3D3A106F for <pce@ietfa.amsl.com>; Thu, 11 Feb 2021 18:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=dhruvdhody-com.20150623.gappssmtp.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 Iv9r-xGFbUm5 for <pce@ietfa.amsl.com>; Thu, 11 Feb 2021 18:00:55 -0800 (PST)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 2DF0B3A106D for <pce@ietf.org>; Thu, 11 Feb 2021 18:00:55 -0800 (PST)
Received: by mail-pf1-x431.google.com with SMTP id k13so4871973pfh.13 for <pce@ietf.org>; Thu, 11 Feb 2021 18:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dhruvdhody-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=md4y1ILrqe2vk2IgDyyYcqgHmFCiQ1C9mNbFzQEB8bg=; b=2HtVtk+7XNQZfRiegs1MR5zXiHFi9uETRomgWoxgJu6cciEYPQTR7O/hpK40qJkm1+ hkFTaog7xI5PlqiUzH80o8K4MJENl2cNaN+tTu5cLJAA2PuJ1aAnmWEa8Q4zsPfm7wbj 3WsO84Y6F7ZuIMlEIqHiizqXeIGIa3wwiSapaiQlu57O4ZxuYmkfku8oiWzO4tnd7of+ 7D42wsbFEhfPupZwSm2Xy+lQdW5Gf/Fx1lp9vWOSvpIbWh21SkjWDS6m9zYNIZi9qjyd HBlUOU+5CvB10SDCZ3GKdpUAYcpY00wzaxJjTm1cfa5cV1MDW7jl0pN+b6QBjAUDk11/ Q+zA==
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=md4y1ILrqe2vk2IgDyyYcqgHmFCiQ1C9mNbFzQEB8bg=; b=oCJAd+hu3PsG2C7wz5DtCZhSS9OUBxQt7nbHpPZN4q/NCk5eOybHBW2+Rx6W0NFMNu lwiAW2SlGZUBv6YEA3MSaRjeqkjxyeFqWateD+HHqLY6YY/36BLaIuqukrHSO186EDLJ FykX8a2Zw5XC2qicOvd80U0hMSQLra8Y+7tIdlY8lltNNaQEFvOnOLbgN8hlKpeMHnvW dcfz5J4gc7lhTZWZu2e5NZmIBceAHwNWR3z0K2ZxUcaTcEcvzmVKobWFllEcIUlCDmsZ G3SMNiJ1DoWbaVBNd0BVi6/XpmSlewmGfHoPDAiv7qDrDd+DqK598F/DV0zChJN27pVa nrKA==
X-Gm-Message-State: AOAM531xhSUdA+brjYmTdsl9MprCviyFvd3T3A7MK60iW7c2OLZEEaHW itl4yLui/JcFPcncaWrBHqbd8xnao9ccY4T1FLbgTg==
X-Google-Smtp-Source: ABdhPJwfVF5SxQYGQ5vUDJ6svdDi4iLZQdqPbl8FNPGhDqbmgW3ugmmwHFJxplSlX4D2QPKugMGifUHFmHjCeZJAE+I=
X-Received: by 2002:a63:ce4b:: with SMTP id r11mr995277pgi.148.1613095254438; Thu, 11 Feb 2021 18:00:54 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YUG2HhDqwCXbhAzO27P18GEL6Rdr6nkYBvW9yzCHLHjQ@mail.gmail.com> <DM6PR08MB3978524B94C0FB4D21B6A1CF918E9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5buVgy=HhT-+ZnhYZcE1AYRmOxK9-Md=4FJxqu7BLK3Zg@mail.gmail.com> <DM6PR08MB39780572111C11CDF6EFC7D4918B9@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB39780572111C11CDF6EFC7D4918B9@DM6PR08MB3978.namprd08.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Fri, 12 Feb 2021 07:30:18 +0530
Message-ID: <CAP7zK5YjxiMTnUT7zVHYDeYqxvQR8ESQf7ydngPYObVPHLU8uA@mail.gmail.com>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
Cc: "pce-chairs@ietf.org" <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a1602805bb1a01c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/8b2uRjNEJ1IWfhEPj8xjnRB3jRk>
Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
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: Fri, 12 Feb 2021 02:00:58 -0000

Hi Hooman,

On Fri, Feb 12, 2021 at 5:36 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
hooman.bidgoli@nokia.com> wrote:

> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions
> defined a new object called CCI, with different object-types to be defined
> for various use-cases. There is common handling for all such instructions
> and it is defined once and can be reused across multiple use cases. I
> understand that you want to use the ERO object with multi-path, and that
> *is* fine, you could in fact easily define the RBNF in such a way that both
> CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Hi Dhruv
>
> I am not sure if I understand are you suggesting we include both CCI and
> ERO as an option and vendor chooses? What benefit does this have? How would
> this improve the interop?
>
> No, I did not say "or", it is not a choice!

In PCEP when we communicate with the head-end we use Candidate Path as the unit
of signaling (with Policy as an association). For programming instructions
(and not paths) we use CCI Object. New CCI Object-type for each use
case can be defined.

I think your proposal to program the replication and leaf nodes as (section
3.4.2) -

   <Common Header>
   [<SRP>]
   <LSP>
   [<replication-sid>]
   as described in [draft-sivabalan-pce-binding-label-sid]
   [<ERO-Attributes Object>]
   as per [draft-koldychev-pce-multipath]

* RBNF is not correct, but I get the idea! I.e. you are signaling this as a
path on the branches and leaves :(

=

What I suggested is that for programming the branch and leaf node, we
should use CCI as a unit of signaling and you can include the ERO and
PATH-ATTRIB along with the CCI. Note this is a new CCI Object-type and RBNF
can be updated for it -

   <Common Header>
   <SRP>
   [<LSP>] <- not included for shared case
   <CCI> <- you can carry the replication-sid as TE-binding as a TLV here
   [(<PATH-ATTRIB><ERO>)...] <- this is a list

To Recap
- you needed ERO and PATH-ATTRIB and you get that here!
- the unit of signaling is a programming instruction and not a Path for the
above case!
- aligns with other use cases in PCEP

Hope I am able to explain myself clearly and this helps!

Thanks!
Dhruv



> Thanks
> Hooman
>
> -----Original Message-----
> From: Dhruv Dhody <dd@dhruvdhody.com>
> Sent: Thursday, February 11, 2021 5:01 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> Cc: pce-chairs@ietf.org; pce@ietf.org
> Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Please see inline...
>
> On Tue, Feb 9, 2021 at 8:36 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com> wrote:
> >
> > Hi Dhruv
> >
> > Much appreciate your reply, Inline
> >
> > Thanks
> > Hooman
> >
> >
> > -----Original Message-----
> > From: Dhruv Dhody <dd@dhruvdhody.com>
> > Sent: Tuesday, February 9, 2021 5:28 AM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> > Cc: pce-chairs@ietf.org; pce@ietf.org
> > Subject: Re: draft-hsd-pce-sr-p2mp-policy wiki comments and action.
> >
> > Hi Hooman,
> >
> > Apologies! Missed replying to this email...
> >
> > On Fri, Jan 22, 2021 at 12:27 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com> wrote:
> > >
> > > Dear Chairs
> > >
> > >
> > >
> > > Looking at the wiki page there was a comment on the sr-p2mp-policy
> draft.
> > >
> > >
> > >
> > > draft-hsd-pce-sr-p2mp-policy
> > >
> > > 109; More work is needed - align to PCECC, text needs to aligned to
> > > the PCE WG style
> > >
> > >
> > >
> > > The authors took an action to setup a meeting and discuss the
> alignment with PCECC farther. The final outcome of this meeting was
> unanimous agreement, by all the authors/vendors on the draft, to go forward
> with ERO object.
> > >
> > >
> >
> > As an individual I-D, it is up to the co-authors to decide the content
> of the I-D.
> >
> > The comment (and earlier discussions) was to make sure we maintain
> consistency across all our documents that we produce. RFC 8283 describes
> the PCECC architecture, where the PCE needs to interact with not only the
> head-end routers (the usual stateful/stateless PCE case) but also with the
> egress and the internal P routers. The WG has just sent the first PCECC
> extension for MPLS label allocation along the path to the IESG. For other
> use cases such as SR/SRv6 SID allocation as well as for the branch node in
> the P2MP LSP and Native-IP, all are under the PCECC umbrella. So far all
> use cases where the PCE needs to interact with other nodes beyond the
> ingress and provide instructions to them are using PCECC architecture.
> >
> > So when the PCE is interacting with the head end for SR P2MP Policy, it
> can use the usual stateful PCE extensions but when the PCE is interacting
> with the branch nodes and leaf nodes for replication segment, we strongly
> feel it should be described under the PCECC architecture. So you could use
> the ERO object for encoding the full P2MP path (and SR P2MP Policy) when
> interacting with the root node.
> > But when interacting with other nodes, use the PCECC technique i.e. a
> new CCI object type (which could be used with the ERO if needed). This
> would help you to not reinvent things as well as maintain consistency.
> > To reconfirm, the PCECC comment is related to section 3.3.3 & 4.5 only
> and not the whole document. If you still disagree please list the technical
> reason why so that the WG can evaluate them.
> >
> > HB> As I am sure you do appreciate there are many ways to skin the cat.
> TreeSID can be connected via unicast SR path and not every node needs to be
> programmed. In addition as explained the PCECC did not provide the with
> flexibility to configure backup/fast reroute paths and the current methods
> does provide that capability.
> > Again as mentioned we looked at PCECC very hard and tried to implement
> treeSID via this method but there were major short comings for backup and
> FRR paths.
> > There are multiple implementation in the field that is using the ERO
> object for treeSID with success.
> > Are the chairs suggesting that the working group is only dictating PCECC
> and is not open to any other option but PCECC for the purpose of
> programming the PCC and multicast?
> > We have been asking for adaptation since 3 IETF ago and we keep getting
> pushback because our implementation does not follow the PCECC, why is PCECC
> the only choice on the table? Why isn't the working group open to other
> options to solve the multicast requirements? Given the fact that the ERO
> has been implemented and is in the field and in multiple providers labs
> being tested with successful outcome, I think the WG should have a open
> view to this implantation. Especially when multiple vendors and providers
> (Cisco, Juniper, Nokia, Ciena, Bell Canada) to name a few have agreed to
> this implementation.
> >
> >
>
> [Dhruv]: I feel there is some misunderstanding here. The PCECC extensions
> defined a new object called CCI, with different object-types to be defined
> for various use-cases. There is common handling for all such instructions
> and it is defined once and can be reused across multiple use cases. I
> understand that you want to use the ERO object with multi-path, and that
> *is* fine, you could in fact easily define the RBNF in such a way that both
> CCI and ERO are included for the new CCI object type for SR-P2MP.
>
> Thanks!
> Dhruv
>
> > >
> > > The authors feel ERO object in addition to
> draft-koldychev-pce-multipath-04 - PCEP Extensions for Signaling Multipath
> Information (ietf.org) for backup paths is the easiest and the most
> efficient way to address the programming of a replication segment on PCC
> from to the PCE.
> > >
> > >
> > >
> > > The authors would like to move forward with the adaptation call
> please. In addition the authors are open to discuss the ERO preference in
> an interim open session with the chairs.
> > >
> > >
> >
> > The document has not been updated after 109, last we discussed this, we
> found that the document needed more work because it does not follow the way
> the PCEP extensions are usually defined. It follows a very unusual format
> (e.g. section 5) at places. It is good to provide examples but suggest it
> be done in a way that is more readable. Please follow the RBNF notations
> when specifying PCEP message changes (in a backward-compatible way). Some
> of your co-authors have vast experience in writing documents in this WG, I
> suggest taking their help. Hopefully, a more readable version will help you
> get more reviews.
> >
> > HB> sure this is cosmetics and we will follow the WG suggestion, that
> said this should not stop the adaptation call. The sooner we have
> adaptation call the sooner we can have input.
> >
> > HB> to close, as you mentioned some of the co-authors have vast
> experience in PCE WG and the same co-authors have agreed and recommended
> ERO implementation. As such I ask the chairs for adaptation call again
> ASAP. We will fix the cosmetics to be inline with WG recommendations asap.
> >
> >
> >
> > Hope this helps, and again accept our apologies for missing replying to
> this email earlier.
> >
> > Thanks!
> > Dhruv & Julien
> >
> > >
> > > Regards
> > >
> > > Hooman
> > >
> > >
> > >
> > >
>