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

Gyan Mishra <hayabusagsm@gmail.com> Sun, 28 March 2021 19:16 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 7D3673A2413 for <pce@ietfa.amsl.com>; Sun, 28 Mar 2021 12:16:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 pGyPYEDsJeB8 for <pce@ietfa.amsl.com>; Sun, 28 Mar 2021 12:16:21 -0700 (PDT)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 6F0CC3A2412 for <pce@ietf.org>; Sun, 28 Mar 2021 12:16:21 -0700 (PDT)
Received: by mail-pf1-x42e.google.com with SMTP id h3so8440445pfr.12 for <pce@ietf.org>; Sun, 28 Mar 2021 12:16:21 -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=0/9CBqsYKmsU0dc2tmY3/mauXKdWNAJFdpBRr2fu/F8=; b=nL4kLkP13eAFKEEoiFzniB5SRrQXNulyPGA1fSbCyK3eILIAaHrcM/EYRr5ly8UVJn xtnm7cT4crNfFx4tr2RD3tSW7lLvYKb4NceVNCVwSPX2CXmUBpBFbNGzUPLgKQ2PHo1Z cbxLmBCVOnks5+Bi0UkfgCCn6me8VwH78DVjjae7wiwTwjjysfPqbBiCnZHCVTOKDiEc 5y0P1S9c6oc3IPIrYsu4HGhNSH92Dg0gA8U0u7yPIYaWAK6UGlNKBVkptFFo+Syqtddx IqMp1bXe+KuEjsC6E0di5UUZMbG7gI1U7Lq6GdwrcCkU4b98tFNMBgTnUQQ3Y0fqVdki 2/vw==
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=0/9CBqsYKmsU0dc2tmY3/mauXKdWNAJFdpBRr2fu/F8=; b=U+mLbh2ywLPkKZhvycgOrleqAXNVBYtA5HNq3JHipeoKcvIF/blirhbTOzQ2BtDWLS G+sPpLdY/04NEfOQbFTBiqAgjakJTrDcqk9yJiLotDYnsaW8F0pphQt8lA7Dbt78q6Ad I8Ha6BJnp6tvScLaSBrjNHsdgIoC1cJ6HmlnZ3qeSLup6U8VSc1W6dBvsh2WbFjhbCur 5o6bHEC15qNglAXpFZTapQbj9AQNuh0/fulofaNVpR4qruwKIl1p+Us+rXBZS7Q992GQ U2KViWmgkNNf3JX2TooE6M29Bo5M3RWgR1ewVrcgCrlPiNn1G1/kfxuTwOZgAHmIwdjc N1+w==
X-Gm-Message-State: AOAM533zzFH67uNqlphK92RdjAWOoNW6PsR5JSUUAgjqMmF/etfa2E+Z v+POnVwflHMDz4aNM2u/GlDYxYHGFWDN9qqlQB0=
X-Google-Smtp-Source: ABdhPJzY7MjxmHJ3UP3TOufl+Vk4jWAX4SWMS7QCFRIsqooWgFk5+psf4UJF61tIyyAADdlcOQRVSDSRatUMtrqrVmM=
X-Received: by 2002:a63:db02:: with SMTP id e2mr21156545pgg.18.1616958979786; Sun, 28 Mar 2021 12:16:19 -0700 (PDT)
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> <CAB75xn67U9iMraEFh=8t2bc+0rGQ703sQgDtvOVck3=3pf2bqw@mail.gmail.com> <DM6PR08MB39789457277EEBE3BE6E950B91919@DM6PR08MB3978.namprd08.prod.outlook.com> <CAB75xn4GY6BgKHsoX9YbELu_b9fF41tHWgDFzDYuOhjuUR8wcA@mail.gmail.com> <DM6PR08MB39782173FED5F234B21B92D191699@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5ZsAaA_HTja85bk2Ye6v6FXk-=T4=FvAhzuW81uCYUh=A@mail.gmail.com> <00cb01d71fb2$3e5274f0$baf75ed0$@tsinghua.org.cn> <DM6PR08MB3978B85DF67DFE3A05510D7891639@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5Y+eK7uN74reoTLksUE_V7k-PHK9NPnmrCuSLn8=NYVYw@mail.gmail.com>
In-Reply-To: <CAP7zK5Y+eK7uN74reoTLksUE_V7k-PHK9NPnmrCuSLn8=NYVYw@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 28 Mar 2021 15:16:08 -0400
Message-ID: <CABNhwV3Q-e3so3ofegiGzQmjgrb5kN0ud_D+HuyeVnFjzSx-TA@mail.gmail.com>
To: Dhruv Dhody <dd@dhruvdhody.com>
Cc: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <hooman.bidgoli@nokia.com>, "pce@ietf.org" <pce@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b4ce305be9d9904"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/gGDpJEPYqueo3-JTM2GDEBYSNuE>
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: Sun, 28 Mar 2021 19:16:27 -0000

Authors / WG

I will try to help summarize to facilitate  the discussion.  Please let me
know if I am off on the points to help come to consensus.

SR Replication SID for SR P2MP tree is analogous concept to IR Ingress
Replication unicast replication.

SR replication SID uses the same RFC 6513 6514 MVPN instantiation
procedures for X-PMSI PTA p-tree identical to IR RFC 7988 unicast
replication where the parent root unicast the copies to the Chile leaves
with Unicast LSPs.

Similarly with SR Replication SID the root and leaf nodes are known to the
PCE and the root node can replicate the segments, however the intermediate
 nodes that require stitching of the hop by hop replication segments of the
intermediate nodes unicast stitching of the replication segments to
instantiate the P2MP tree.

With PCE CC stateful LSP style the head end has control of the label space
and can instantiate the end to end P2MP LSP.

In the case of SR P2MP policy using replication SID the replication SIDs
are unicast routing hop by hop stitched push/next using RFC 8664 PCE SR
extension SR-ERO object.

https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-04


https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04



3 <https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04#section-3>.
Use Cases

   In the simplest use case, a single Replication segment includes the
   root node of a multi-point service and the egress/leaf nodes of the
   service as all the Downstream Nodes.  This achieves Ingress
   Replication [RFC7988 <https://tools.ietf.org/html/rfc7988>] that
has been    widely used for MVPN [RFC6513
<https://tools.ietf.org/html/rfc6513>]
   and EVPN [RFC7432 <https://tools.ietf.org/html/rfc7432>] BUM
(Broadcast, nknown and Multicast) traffic.

   Replication segments can also be used as building blocks for
   replication trees when Replication segments on the root, intermediate
   Replication Nodes and leaf nodes are stitched together to achieve
   efficient replication.  That is specified in
   [I-D.ietf-pim-sr-p2mp-policy
<https://tools.ietf.org/html/draft-ietf-spring-sr-replication-segment-04#ref-I-D.ietf-pim-sr-p2mp-policy>].


This draft defines the SR-TE P2MP policy of inserting the candidate path
Replication SID list into the forwarding plane and discusses in detail how
to use PCE CC CCI object instantiation or SR replication SID stitched P2MP
tree.

CCI object

https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-14#section-5.5.3.1

SR TE P2MP policy using replication SID

https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/02/

A lot of what is defined in the draft being discussed PCE extension for SR
P2MP is also discussed in the above draft using PCE CC CCI object.

Hope this helps facilitate the discussion to try to get to root of the
technical issue as to why CCI cannot be used for SR P2MP.

It does appear that we should be able to use PCE CC CCI object for the SR
P2MP tunnel however we need dig into the technical issues we are seeing.
>From the thread it seems the issue maybe related to the unicast routing
stitching hop by hop of the replication SIDs to build the P2MP tree,
however that should be able to be accomplished with SR-ERO object with CCI.


Kind Regards

Gyan

On Fri, Mar 26, 2021 at 3:33 AM Dhruv Dhody <dd@dhruvdhody.com> wrote:

> Hi Hooman,
>
> With my chair hat off and speaking as a WG participant. Thanks for
> explaining your point of view and the history.
>
> The PCEP stateful messages are currently being used for -
>
> - LSP operations (LSP instruction/reports to/from head end i.e. stateful
> PCE)
> - PCECC operations (generic instructions/reports to/from any node)
>
> You say-
>
> In addition the replication segment is in “NO WAY” part of an LSP or a
>> P2MP LSP or a static P2MP LSP, it is an individual segment (like a binding
>> SID) programed at a strategic node for sole purpose of replication.
>
>
> You agree that it is not an LSP operation but you don't consider it PCECC
> either! You would like to use the encoding that matches with the P2P LSP
> operations for the replication segment. Since you mentioned binding SID, in
> PCEP, it is a property of the LSP. It is encoded in a TLV inside the LSP
> Object. Even when the binding segment is used on a strategic internal node
> it is for an LSP with the strategic node as the head-end from PCEP's point
> of view.
>
> Regarding the question of why CCI Object, as I mentioned earlier, we could
> have instantiated a static PCECC LSP as a one-hop LSP along the path
> without a new object. The approach that the WG took was to define a new CCI
> Object instead, as the scope of PCECC was bigger and we wanted to have the
> freedom to encode various types of instructions (which can be unrelated to
> LSP operations). For example SR/SRv6 SID programming, Native-IP, etc. This
> has been helpful IMHO. And replication segment fits here well.
>
> You say -
>
> Consistency is great as long as the solution and the implementation does
>> not get complicated and there are obvious benefits to it. The solution is
>> achievable without CCI object, the CCI object and encoding will be there
>> wrapping ERO for no purpose at all.
>
>
> I agree that your solution is achievable without using a CCI object but
> disagree that adding a CCI object Type would make it complicated. Moreover
> to me, it is a PCECC operation (but I-D does not refer to it in any way and
> that is confusing).
>
> Coming back to the question to the WG -- Is the act of programming
> replication segment to a replication node and the leaves, a PCECC operation
> (we seem to agree that it is not an LSP operation)? And should we use a new
> CCI Object type to encode it or not?
>
> Thanks!
> Dhruv (as a WG participant/still chair hat off)
>
> On Wed, Mar 24, 2021 at 8:49 AM Bidgoli, Hooman (Nokia - CA/Ottawa) <
> hooman.bidgoli@nokia.com> wrote:
>
>> Hi Aijun
>>
>>
>>
>> Thanks you for your comments.
>>
>>
>>
>> Inline
>>
>>
>>
>> Regards
>>
>> Hooman
>>
>>
>>
>> *From:* Aijun Wang <wangaijun@tsinghua.org.cn>
>> *Sent:* Tuesday, March 23, 2021 3:01 AM
>> *To:* 'Dhruv Dhody' <dd@dhruvdhody.com>om>; Bidgoli, Hooman (Nokia -
>> CA/Ottawa) <hooman.bidgoli@nokia.com>
>> *Cc:* pce@ietf.org
>> *Subject:* RE: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and
>> action.
>>
>>
>>
>> Hi,
>>
>>
>>
>> My consideration is that if the solution depends on the distribution
>> protocol among the underlay nodes to accomplish the task, then PCE should
>> follow the procedures described in RFC8231, RFC8281 etc. That is to say, in
>> such situation, the instruction from the PCE needs only to be sent to the
>> headend of the path.
>>
>> HB> no underlay distribution for replication SID, as it is not a P2MP
>> LSP. Replication SID is an individual resource, that can be programmed at
>> strategical node for sole purpose of replication. It can be stitched
>> together via unicast SR. Traffic can be steered out of each OIF via unicast
>> Node/Adjacency SID.
>>
>> And, if the solution depends solely on the computation of the PCE, and
>> PCE should interact not only the headend node, but also the transit node,
>> tail-end node, follow the PCECC approach is more clear.
>>
>> Mixed of these two solutions should be avoided.
>>
>> HB> Agreed that the 2 concept can’t be mixed. A bit of history, my
>> apologies for repetition here:
>>
>> 1.            We did look at PCECC and our first implementation and first
>> draft was based on PCECC and CCI object. We found CCI object for
>> replication SID to be cumbersome, it made the solution much more
>> complicated then what it needed to be. The perfect examples are: the FRR
>> protection path, with CCI the protection path had to be downloaded with
>> every single OIF making the message much larger. In addition for an
>> incoming label and set of outgoing OIF, the CCI solution forced the
>> download of the incoming label and the outgoing OIFs/Labels in order with
>> in a message, making the ordering of the labels and the OIFs very
>> complicated. In short we tried to use the CCI object and it did not fit
>> nicely. Hence why we looked at the ERO object with multipath backup TLV for
>> protection. In addition the replication segment is in “NO WAY” part of an
>> LSP or a P2MP LSP or a static P2MP LSP, it is an individual segment (like a
>> binding SID) programed at a strategic node for sole purpose of replication.
>>
>> 2.            I think above point is driven home. The next suggestion was
>> why not wrap the ERO in CCI object. This is where the authors/co-authors
>> didn’t understand what additional improvement this method would bring into
>> the solution. When the question was posed the answer was consistency
>> “only”. Consistency is great as long as the solution and the implementation
>> does not get complicated and there are obvious benefits to it. The solution
>> is achievable without CCI object, the CCI object and encoding will be there
>> wrapping ERO for no purpose at all.
>>
>>
>>
>>
>>
>> Best Regards
>>
>>
>>
>> Aijun Wang
>>
>> China Telecom
>>
>>
>>
>> *From:* pce-bounces@ietf.org <pce-bounces@ietf.org> *On Behalf Of *Dhruv
>> Dhody
>> *Sent:* Monday, March 22, 2021 12:48 PM
>> *To:* Bidgoli, Hooman (Nokia - CA/Ottawa) <hooman.bidgoli@nokia.com>
>> *Cc:* pce@ietf.org
>> *Subject:* Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and
>> action.
>>
>>
>>
>> Hi Hooman,
>>
>>
>>
>> On Thu, Mar 18, 2021 at 10:06 PM Bidgoli, Hooman (Nokia - CA/Ottawa) <
>> hooman.bidgoli@nokia.com> wrote:
>>
>> Hi Dhruv
>>
>> I am very confused by your messaging.
>>
>> Originally it was pointed out that the draft should follow PCECC/CCI.
>> The authors explained why they feel that is not a good fit.
>>
>> Now you are mentioning get in part with RFC 8231, 8281 etc... which is a
>> new input. Thank you.
>>
>>
>>
>> I apologize if I was not clear. As I said in the mail, I still feel PCECC
>> is the way to go. What I want to highlight is that if you consider it as an
>> LSP operation instead, then it should be built on RFC 8623 (P2MP) instead.
>>
>>
>>
>> The 'recap' was to show how the extensions in PCEP have been done for SR
>> and P2MP in the past in a consistent way.
>>
>>
>>
>>
>>
>> The authors/co-authors have  tried to keep the draft in par with all the
>> RFCs that you mentioned as much as possible. As it is mentioned in the
>> draft clearly. That said this is new concept and there is a need for a new
>> PCE concept and deviation, hence the draft 😊 and the purpose of IETF.
>>
>> RSVP-TE P2MP is built via S2Ls.
>> Replication segment is nothing like S2L, replication segment can be
>> connected via unicast SR.
>>
>>
>>
>> If you claim that the replication segment can not use RFC 8623, that
>> gives it more of a reason to not consider it as an LSP operation in the
>> first place.
>>
>>
>>
>> Again we are open for any constructive feedback on how this draft can be
>> improved, in the boundary of
>> https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/
>> https://datatracker.ietf.org/doc/draft-ietf-pim-sr-p2mp-policy/
>>
>>
>>
>> Just to clarify, my feedback is on your choice of PCEP procedure and
>> encoding for the replication segment taking existing PCEP
>> extensions/procedures in mind.  Hope the discussion was useful, it was for
>> me...
>>
>>
>>
>> Thanks!
>>
>> Dhruv (as a WG member)
>>
>>
>>
>> Regards
>> Hooman
>>
>>
>> -----Original Message-----
>> From: Pce <pce-bounces@ietf.org> On Behalf Of Dhruv Dhody
>> Sent: Thursday, March 18, 2021 8:01 AM
>> To: pce@ietf.org
>> Subject: Re: [Pce] draft-hsd-pce-sr-p2mp-policy wiki comments and action.
>>
>> Hi,
>>
>> Speaking as a WG member...
>>
>> Let's continue the discussion on considering the replication segment as
>> an LSP v/s PCECC operation.
>>
>> I just wanted to quickly recap -
>>
>> - We have stateful operations for RSVP-TE: RFC 8231, RFC 8281
>> - We then introduced SR with a minimal extension of new PST and a new
>> SR-ERO subobject: RFC 8664
>> - We supported P2MP stateful operations for RSVP-TE with RBNF change in
>> PCEP messages: RFC 8623
>>
>> We have always tried our best to maintain consistency between RSVP-TE and
>> SR in PCEP.
>>
>> Now, if one considers the Replication segment as an LSP operation, IMHO
>> it needs to be built on RFC 8623 P2MP LSP operations. The current approach
>> does not build on RFC 8623 instead uses the multi-path technique (related
>> to ECMP in P2P [1]). This would deviate from RFC
>> 8623 significantly.
>>
>> On the other hand, considering the replication segment as a PCECC/CCI
>> operation gives you more leeway to choose an encoding with a new CCI Object
>> type for the replication segment and it could be independent of RFC 8623.
>>
>> I *still* feel PCECC makes more sense at the higher level too (because of
>> the additional instruction to the leaves and coordination required). Even
>> if one disagrees with that and considers it an LSP operation, it then needs
>> to build on RFC 8623. The current "mashup"
>> approach (i.e. it is an LSP operation but does not follow P2MP LSP
>> encoding) does not work well in maintaining consistency within our
>> extensions.
>>
>> Thanks!
>> Dhruv (as a WG member)
>> [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/
>>
>> _______________________________________________
>> 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
>>
>> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
-- 

<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*