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

Dhruv Dhody <dd@dhruvdhody.com> Tue, 09 February 2021 10:28 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 06C2F3A1539 for <pce@ietfa.amsl.com>; Tue, 9 Feb 2021 02:28:48 -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=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 Z8WU6bN0_uf6 for <pce@ietfa.amsl.com>; Tue, 9 Feb 2021 02:28:46 -0800 (PST)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 85C3C3A19AE for <pce@ietf.org>; Tue, 9 Feb 2021 02:28:35 -0800 (PST)
Received: by mail-pj1-x1035.google.com with SMTP id cl8so1310702pjb.0 for <pce@ietf.org>; Tue, 09 Feb 2021 02:28:35 -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=D3YMmQ4AtxjeThBkxhrn28pM+mqz2SrjSY4DCD40YqQ=; b=bl6ZBGnKc766ikc4mcjZ5Z+hkcnU+yr1WCOqzVUl38JISBbKuWUiuYKSmRvCPDp29J WOdyqzCz+dwss0esHJZAQ1KAeNxOUCwsqkKs8ZHZvuh5+wwor837UQSdXC82JX5oeXyU kBLXIXGQn5Isf/BrEt9AwIreLunHcmatM1ZNY/7+CtwvKFoloIHqEc23+4YHMHzpfxwv CvX2u7YVZfDGbPGSWu7ahrsgX/pVQsiAyWEtr5uQ4cqoD5TTVRL36DBcqI/4MBROup4n TbWJ9tgKozMFBrVGzz8cFQbNwC90Mj5IQWSXqLFj6tbwqNexo2KSruMXaW8TKEr+K4Yo vANQ==
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=D3YMmQ4AtxjeThBkxhrn28pM+mqz2SrjSY4DCD40YqQ=; b=cHhlbrYr2HLqVYxK2VfNRk9TbKY4QGVUS2PEKy9Jbq75zVEDSioWoUwdeYZiSHjvWW HCbOMa3Idd355gqIcyre7auJqy/7WBFpRv5DZ5VbpIbnblCLQ1Jk3syIYaJhwYVOxCx7 H+28zuJVX++gR4lZK+shYXUJ3lR8K/GxKCN8P9B8rIc7yFCawlIWfIup/RjK5tRmU6zs d1580P2EaKR3+RyVvKbwgppxYzzFQJ6poGea2IKf2OIvxrqgjLtjFewUp/YkYwcTYqvM oKl5/hARKHlVLDS26YH8fDdAeOg2wfnhTYe29DJOl4PPiOYMTmo1narClz1xU/a7gu88 kg3A==
X-Gm-Message-State: AOAM531nlTHAuFlPct5Rov57yKoU89uH3PrSGHwhNHPgOFqxcjU8aSAC kz0S3QlvWxTa9OD20PbrBvldZanoPIjyhKBaw3I4mg==
X-Google-Smtp-Source: ABdhPJxG1dOxtdllpvfoggQAqt3ibr33e1nnNl/ep2VUjCgx+YEIddZQJWs1o5o422uBgcrPsx1fEH5aqK1SL2WIOLM=
X-Received: by 2002:a17:902:a40b:b029:e0:1096:7fb with SMTP id p11-20020a170902a40bb02900e0109607fbmr20267459plq.40.1612866514906; Tue, 09 Feb 2021 02:28:34 -0800 (PST)
MIME-Version: 1.0
References: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com>
In-Reply-To: <DM6PR08MB3978834687ACFA7C599AF90C91A10@DM6PR08MB3978.namprd08.prod.outlook.com>
From: Dhruv Dhody <dd@dhruvdhody.com>
Date: Tue, 9 Feb 2021 15:57:58 +0530
Message-ID: <CAP7zK5YUG2HhDqwCXbhAzO27P18GEL6Rdr6nkYBvW9yzCHLHjQ@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/gHIejV0AqCpZbgaqh3b3GrkP8HA>
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: Tue, 09 Feb 2021 10:28:48 -0000

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.

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

Hope this helps, and again accept our apologies for missing replying
to this email earlier.

Thanks!
Dhruv & Julien

>
> Regards
>
> Hooman
>
>
>
>