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

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 05 March 2021 04:05 UTC

Return-Path: <dhruv.ietf@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 9E6BA3A1D2A; Thu, 4 Mar 2021 20:05:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 wt9oacvxgUpp; Thu, 4 Mar 2021 20:05:31 -0800 (PST)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 A159F3A1D28; Thu, 4 Mar 2021 20:05:31 -0800 (PST)
Received: by mail-il1-x135.google.com with SMTP id g9so795412ilc.3; Thu, 04 Mar 2021 20:05:31 -0800 (PST)
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=TcCO/6KU/Z+PCJE4gH+62KbTkLEL/2TtNH7GxthPv2Q=; b=kOMrW5/wGx6mJeaOvHzZuZRipV8EJ5dEmRQj82h4IL7rIoQS8X5UQasxWHtfQatJ71 5c2X7Xmu6sxocz1q3cStB8ohU2s3FtxSUsmOKqJHq+N23tIOfPUGaQ2dgpVBNDLhtPfW HWt/JmcngvBDk5pAKwNfS3jD0BKpEm2jqlR4dX+phk0gPbkAq3CmKYxANwxIbQB0q3B0 C0h6hRQOS4ujrSzx7s6VtwKooyUjUnRrjolohsn5kmwn2sEqSQodad3sddnwrKBif/pU oo70+o6ZfW+feNV9dWV7TIFnNWUFdUzdveckXZFDmPD9g97ZUHldleZar6Y9WkEH8EVA +Q4A==
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=TcCO/6KU/Z+PCJE4gH+62KbTkLEL/2TtNH7GxthPv2Q=; b=FSVluyMl/0Wt096+QfOpewx6TkMAVpVi7ohrdzN2fsSl34dEU48Z14ESWwCqNDrsG7 oYroNsVAHCKpprC+mehAPyHEahLl8Sdg8uYYfpmuo5qn8CW/aEWI7SKrNpoFqjfA4F7W PgSM+z/jyPoai8lq9QMdvXyuAxmTAOHK7RE0NIoHdjDe3GNb22JDqFWcfkATfIOtpAcI N+ACezTT37loJmxj+gPMptIPQKzxeJgU2lPpr4Pqvu+jgOEn1tDgILpFjCeTPRl+Ar/3 Ms80BvBZJAD2eh7JFvgYGvLf65hgdzPmvlWddfXiZiG1Nkk50pPm9pm/dvJ6QzvklVBC +PRw==
X-Gm-Message-State: AOAM53286lPGe4yEVOLI6yiZpD3EXyOBy2EexhWi6HFSB5gZv2XeCvTY 5iPTP3t0xG03BQvls1njNEvShEaqBxRA470CtJw=
X-Google-Smtp-Source: ABdhPJylGtrpz1y6W1mAIvp5xfgV/qAhuXDKmlvRapFkhER064Z4OsAMWr0xu1FVW85xJZbeQmEzELYIBJcG3+abQro=
X-Received: by 2002:a05:6e02:12a1:: with SMTP id f1mr6814181ilr.124.1614917127643; Thu, 04 Mar 2021 20:05:27 -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> <CAP7zK5YjxiMTnUT7zVHYDeYqxvQR8ESQf7ydngPYObVPHLU8uA@mail.gmail.com> <DM6PR08MB397847235D7ADDF7C4B7D028919B9@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn7sR7wRTxamEzDJ2baaCq+iNmd1pNA+u+BGit4o4gBo6Q@mail.gmail.com> <DM6PR08MB39783882B8AA6A607416AA4E91999@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn4rAdTk3VQg5OVJB-NxXuPRv3NJ_M8rKC-Gw8WHpmvDog@mail.gmail.com> <DM6PR08MB39782584E9BBB2A30879DAF091989@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB39782584E9BBB2A30879DAF091989@DM6PR08MB3978.namprd08.prod.outlook.com>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 5 Mar 2021 09:34:50 +0530
Message-ID: <CAB75xn67U9iMraEFh=8t2bc+0rGQ703sQgDtvOVck3=3pf2bqw@mail.gmail.com>
To: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>
Cc: Dhruv Dhody <dd@dhruvdhody.com>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bc285105bcc231ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/asTA0OQ9YF3JgDAln1o3bUMCwqM>
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, 05 Mar 2021 04:05:36 -0000

Hi Hooman,

On Wed, Mar 3, 2021 at 6:32 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
hooman.bidgoli@nokia.com> wrote:

> Hi Dhruv
>
> I don't think we are arguing against the usefulness of PCECC ūüėä I am sure
> all of these other draft have leveraged "TECHNICALLY" from PCECC
>
> We are asking what is the advantage of wrapping an ERO object in CCI
> object? Technically we find managing the CCI objects and IDs cumbersome for
> replication segment and not necessary.
> And until now we have "NOT" heard a "SINGLE" technical argument what the
> advantage is. As per our call with yourself (thank you for taking time),
> you mentioned that the only point is the need for us to be in PCECC
> architecture, because of working group mandate/decision that was made while
> back, even if it doesn't bring any technical advantages to the solution.
>
>
I wanted to focus on the question - "Is the act of downloading a
replication segment to the replication node AND the leaves, a PCECC
operation or a stateful operation?". We can discuss encoding once we have
this settled.

I disagree with the above characterization. But let's leave it at
that.  Let's continue the discussion on the key question.



> In addition we are blocked from an adaptation call ūüėČ
>
>
See Julien's response -
https://mailarchive.ietf.org/arch/msg/pce/Vimr_-zn3DjpW2uY8A-hFpZXJg4/



> So far we have heard from yourself only and I think we hear clearly were
> you stand ūüėä We have not heard from any other member of WG that why we
> should use CCI object.
>
>
I agree, lets give time for others to chime in, a week before IETF is a
busy time :)

Thanks!
Dhruv



> If the working group consensus is that the PCECC (CCI Object) is a must,
> even if there is no technical reasons behind it, then it is what it is.
>
> How do we proceed? Do we want to do a adaptation call maybe that will make
> other members more vocal?
>
> Regards
> Hooman
>
>
>
>
> -----Original Message-----
> From: Dhruv Dhody <dhruv.ietf@gmail.com>
> Sent: Wednesday, March 3, 2021 4:54 AM
> To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> Cc: Dhruv Dhody <dd@dhruvdhody.com>om>; pce@ietf.org; pce-chairs@ietf.org
> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>
> Hi Hooman,
>
> Based on quotes, I think you might be looking at
> draft-ietf-pce-pcep-extension-for-pce-controller [1] ONLY which is about
> provisioning labels along the path of a static LSP.
>
> There are actually some other work in the WG in this space -
> 1) SR and SRv6 SID allocation and distribution [2][3]
> 2) Native IP [4]
> 3) Static P2MP LSP [5]
> 4) BIER [6]
>
> And the related usecases discussion in RFC 8283 [7].
>
> Thus the statement "Obviously the PCE-CC is for a continues LSP", "No
> where in the PCE-CC draft I can read that PCE-CC should be used for single
> resource or SID in the network." are not true. See [2] and [3].
>
> I agree with your description of the replication segment. But we arrive at
> a different conclusion on the applicability of PCECC :). The difference in
> view could be because we are looking at the scope of PCECC differently
> (beyond [1]) as well as where we draw the line between a stateful and a
> PCECC operation.
>
> This is a good discussion. I hope this helps us (as a WG) to make an
> informed decision on the questions in the previous post!
>
> Thanks!
> Dhruv (as a WG participant)
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-pce-controller-sr/
> [3]
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-srv6/
> [4]
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-native-ip/
> [5]
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-extension-pce-controller-p2mp/
> [6]
> https://datatracker.ietf.org/doc/draft-chen-pce-pcep-extension-pce-controller-bier/
> [7] https://www.rfc-editor.org/rfc/rfc8283.html
>
> On Tue, Mar 2, 2021 at 6:48 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com> wrote:
> >
> > Hi Dhruv
> >
> > I do not agree with the assertion that the Replication segment does
> > not fit with PCECC architecture. Looking at the figure
> > https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02
> > #section-4, this looks like a typical PCECC operation, irrespective of
> > the choice of PCEP message encoding.
> >
> > HB> you keep looking at a single use case of replication policy which is
> "TREE" and most of your argument is using the tree to justify a replication
> segment fits the PCECC. Where the replication segment has many other use
> cases as explained below. Spray, stand-alone replication segment etc... In
> fact even a "Tree" can be setup via a replication segment at needed nodes
> and unicast SR policy stitching those replication segments many hops away.
> > Quoting from the PCE-CC draft "Thus, the LSP can be calculate/set
> up/initiated". Obviously the PCE-CC is for a continues LSP.
> > Replication segment doesn't need any computation, it has an incoming
> interface and a set of outgoing interface. It can be shared by multiple
> services. It can be setup at a strategic replication node to replicate a
> unicast flow "LSP" to a set of out going unicast flow. It is a resource. No
> where in the PCE-CC draft I can read that PCE-CC should be used for single
> resource or SID in the network.
> > Quoting again from the PCE-CC draft " where LSPs can be provisioned as
> explicit label instructions at each hop on the end-to-end path."
> Replication segment concept is not end-to-end as the authors keep pointing
> out. Even in the case of the "TREE" the replication segment is not
> end-to-end. It is only used were the replication is needed. As an example
> through out the unicast path.
> >
> > HB> To give you a bit of history that might help you, at beginning the
> segment was the "TREE" it self. The SID represented the entire "TREE".
> End-to-end "TREE". We deviated from this simply because we understood the
> benefits of being able to program a single replication resource on a
> strategic node, that can replicate any arriving packet to a set of outgoing
> interface. As long as the resource is identified and the traffic is steered
> into this resource, it does its job and replicates.  How this resource is
> used is up to the service/application. As an example BGP could only program
> this resource on strategic nodes on a unicast path. As such this resource
> is not end-to-end.
> >
> > So IMHO, we should get more inputs from the WG and try to get an
> > agreement on -
> > - Is the act of downloading the replication segment to the nodes
> (including leaves), a PCECC operation or not?
> > - If yes, is it fine to take a different PCEP approach for this one
> use-case deviating from the rest of the PCE WG output?
> >
> > HB> For sure the authors are open for discussion, keeping the facts
> above in mind. We are not trying to deviate as mentioned, we just don't see
> the replication SID breaking the PCE-CC architecture as it doesn't fit into
> that end-to-end architecture.
> >
> > Regards
> >
> > Hooman
> >
> > -----Original Message-----
> > From: Dhruv Dhody <dhruv.ietf@gmail.com>
> > Sent: Tuesday, March 2, 2021 12:31 AM
> > To: Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
> > Cc: Dhruv Dhody <dd@dhruvdhody.com>om>; pce@ietf.org; pce-chairs@ietf.org
> > Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
> >
> > Hi Homman,
> >
> > Thank you for your email and further discussion. Speaking as a WG
> member....
> >
> > On Mon, Mar 1, 2021 at 3:54 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com> wrote:
> > >
> > > Hi Dhruv
> > >
> > >
> > >
> > > As per draft-ietf-spring-sr-replication-segment, a replication segment
> allows a node (henceforth called as Replication Node) to replicate packets
> to a set of other nodes(called Downstream Nodes) or hosts in a Segment
> Routing Domain.
> > >
> > >
> > >
> > > A Replication segment can replicate a packet to directly connected
> > > nodes/hosts or to downstream nodes (without need for state on the
> > > transit routers). In some use cases replication segments can be
> > > stitch directly ‚ÄúTree‚ÄĚ or via a unicast segment routing domain
> > > ‚Äúspraying‚ÄĚ. In other use cases the replication segment can be a
> > > stand alone resource and act as a root and the leaf on the same
> > > node. In short a replication segment is a logical construct and
> > > behaves as a standalone resource, as an example it can be thought of
> > > as a binding SID on that particular node encoded via
> > > draft-ietf-pce-binding-label-sid
> > >
> > >
> > >
> > > This is why the authors on this draft feel a replication segment does
> not fit the PCE-CC Architecture Design, as each replication segment is
> really a head-end resource or a root that does a form of replication
> regardless if it plays the role classified as a root, bud or leaf to
> deliver a multicast service. As well, the authors view is that encoding the
> data in a CCI object does not add enhancements, however introduces further
> complexity with new identifiers to be used in message exchange, new object
> codepoint and capability allocations, when the existing proposal based on
> simply ERO encoding using already defined objects achieves the intended
> goals consistently regardless if one would consider the role a node plays
> in an overall tree.
> > >
> > >
> >
> > If I understand correctly, the proposal is that each Replication segment
> is packaged as an "LSP" at headend from the point of view of PCEP. At the
> leaves, from the PCEP's view, a leaf node of a replication segment could be
> considered as a headend of an LSP with itself in the replication state.
> > This reminds me of the PCECC discussion for static LSP :); at that it
> was said that the per-hop instruction along the path can be considered as a
> 1-hop LSP. But instead of considering it an 1-hop LSP in PCEP encodings, we
> created a new CCI Object. This was done because we had PCECC-SR and other
> use cases in mind where the SR/SRv6 SID allocation/distribution instruction
> were bit diffcult to be viewed as an "LSP". The idea was that each PCECC
> usecase to create a new CCI object-type when needed and maintain some
> consistency in the protocol.
> > This approach also helps to distinguish between the existing stateful
> LSP operation with the headend and the PCECC operations.
> >
> > I do not agree with the assertion that the Replication segment does
> > not fit with PCECC architecture. Looking at the figure
> > https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy-02
> > #section-4, this looks like a typical PCECC operation, irrespective of
> > the choice of PCEP message encoding.
> >
> > So IMHO, we should get more inputs from the WG and try to get an
> > agreement on -
> > - Is the act of downloading the replication segment to the nodes
> (including leaves), a PCECC operation or not?
> > - If yes, is it fine to take a different PCEP approach for this one
> use-case deviating from the rest of the PCE WG output?
> >
> > >
> > > In addition the concept of CCI object will create further complexity
> for the protection paths of the replication segment. The replication
> segment outgoing interfaces can be protected via a single protection ERO.
> The ERO object combined with draft-koldychev-pce-multipath will create the
> perfect solution for this.
> > >
> > >
> >
> > Let's focus on the above discussion first. To me, the
> procedure/information encoded is similar, only the object is different. I
> fail to see how CCI+multipathERO cannot handle this use case.
> >
> > Hope the above discussion helps to make progress.
> >
> > Thanks!
> > Dhruv
> >
> > >
> > > In conclusion to repeats the original point since a replication
> segment is stand alone resource on each node (as an example a shared
> replication segment as per draft-ietf-pim-sr-p2mp-policy) with the function
> of providing a replication instruction on that node it really does not
> break the PCE-CC Architecture.
> > >
> > >
> > >
> > > I hope above clarifies the questions about PCE-CC decision.
> > >
> > >
> > >
> > > Thanks
> > >
> > >
> > >
> > > Hooman
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > From: Dhruv Dhody <dd@dhruvdhody.com>
> > > Sent: Thursday, February 11, 2021 9:00 PM
> > > 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,
> > >
> > >
> > >
> > > 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
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > > _______________________________________________
> > > Pce mailing list
> > > Pce@ietf.org
> > > https://www.ietf.org/mailman/listinfo/pce
>