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

Dhruv Dhody <dd@dhruvdhody.com> Thu, 11 February 2021 10:01 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 0E2DF3A142C for <pce@ietfa.amsl.com>; Thu, 11 Feb 2021 02:01:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 UB7IZMsTktkS for <pce@ietfa.amsl.com>; Thu, 11 Feb 2021 02:01:30 -0800 (PST)
Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 65E483A142B for <pce@ietf.org>; Thu, 11 Feb 2021 02:01:30 -0800 (PST)
Received: by mail-pf1-x42c.google.com with SMTP id m6so3398576pfk.1 for <pce@ietf.org>; Thu, 11 Feb 2021 02:01:30 -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:content-transfer-encoding; bh=KbfJkxmj5je0xs0xn3aKGnzEU56T1/2TPgv3ounX6QY=; b=qLWDbqjGfZ+ly+FEXuJGjmDFX5n2cjNYGDZVgQpSrYfFw/neSlOobLzteQkxpz9EJw fJ2fpMKyrsq38IUi+hG3aCwsu1AesiDPtbbH8L8YhOUOUc+7ao9lrA6kicfm4UNwXyMH VKOBmdfpww8ZFYBEExv/FPUXuVfjWlKhDpKqwehDeovnHlmYZtcDJ9PG3+XM5O4li+vO UZZbv9KKG/tLm+lsAKyvOocQSKmO/IEiU7kxbvY51f3W8wr4DRJxqxhKLRwuOrBTS5Ui RqakaJ44llJnKZG1XeYc0KEnT6K350GIxclED8nJbqdUJ00oLb/ICkfFNlcqwEGWWe10 noKA==
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=KbfJkxmj5je0xs0xn3aKGnzEU56T1/2TPgv3ounX6QY=; b=hL8ccY+iJMNadBOZozVsfh83j+7Mkl3bhvD26HZX1a23OM1U74h2RY8Amk5L1Onaqj G6ShBbUaIxOAYo7RZs1p+4N9TebdUxsv/rrgJ9Pf8S+qi7Nbnu42akzyIeZe3lE3bnOC iSkIyEEOV6Adys2e5/UJhsi3TC8M/XbaGmQO0KgF0zMtLzp/0KEtA5cQpXGcTcBC7j19 mimnV/KqVhnIn/5WqSgd3C1PJsO/RIXw2WimZknu2WN1SSTlDQ0IUuXD+bD/1ToSgb99 HXhvJ62BWhrujsC7yw7+xZxD7FRdTteih19L8VSb/YZRFBJPgYnl0GgSMXr/CPORkOwM XHLg==
X-Gm-Message-State: AOAM532AMlqNxb8ZHXynkcw5K6fCrfqGkBdULDtN3OQw9i8WdnrWB1cP xq68T5AZLBbQ1IjCRhNsw/VioTzQZJIRcc8XG+OvfQ==
X-Google-Smtp-Source: ABdhPJxO2RvEECt+6hb08LLSLriL5DCEuPm6/WD/TgG2s5vVX55DwcKmNNVQE4NyyZ7oMFQXuYG+fnRkwEvUb7ZJWN0=
X-Received: by 2002:a62:7e8c:0:b029:1e1:6431:7ce with SMTP id z134-20020a627e8c0000b02901e1643107cemr7501965pfc.6.1613037689125; Thu, 11 Feb 2021 02:01:29 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com> <CAP7zK5YUG2HhDqwCXbhAzO27P18GEL6Rdr6nkYBvW9yzCHLHjQ@mail.gmail.com> <DM6PR08MB3978524B94C0FB4D21B6A1CF918E9@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB3978524B94C0FB4D21B6A1CF918E9@DM6PR08MB3978.namprd08.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Thu, 11 Feb 2021 15:30:52 +0530
Message-ID: <CAP7zK5buVgy=HhT-+ZnhYZcE1AYRmOxK9-Md=4FJxqu7BLK3Zg@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: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/YARC75PVWAtyDBMtOzxFFM1bAjk>
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: Thu, 11 Feb 2021 10:01:33 -0000

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