Re: [Pce] New Version Notification for draft-ietf-pce-segment-routing-policy-cp-13.txt

Mike Koldychev <mkoldych@proton.me> Mon, 18 March 2024 02:40 UTC

Return-Path: <mkoldych@proton.me>
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 247A7C14F695 for <pce@ietfa.amsl.com>; Sun, 17 Mar 2024 19:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=proton.me
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QivhAYsLrx8R for <pce@ietfa.amsl.com>; Sun, 17 Mar 2024 19:40:12 -0700 (PDT)
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99BC8C14F697 for <pce@ietf.org>; Sun, 17 Mar 2024 19:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1710729610; x=1710988810; bh=/Cpa6QBUM/Pa3SLvsw9kgBs1OIITUdUGPXtUBuhU/b8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Y1vwPA1CLJTVJAqpyqwM+VVoePv1Wa2DzGnHXVAVBqUXro97bIMzXCxOeYf/pAcBY PSKU6bOVm78zGovD3H6uJ0uvK7FFlaAC6g+GyWohoHuyenoCVwvn0Bl2vSZ9zde3PC 1/0UmWC6bdNEybIaj+ydlWdz4LbLVyOLoboLixeKchbrxVMIhztO2gZJ1RcYMArjtH 029+roM97MFN9cMdEsSpDIjMwPEoA/yni350C1MfX0MNon9eyoW+8DoSeOTCeBWmfG nNtbm3cX/kLQtmMrGZ+T8cSSTxnYvhVwWDhdquVchE9VfB8YZ7RoQoVuA+MYW8aKkF An3uUSLwrLtkQ==
Date: Mon, 18 Mar 2024 02:40:00 +0000
To: Mike Koldychev <mkoldych=40proton.me@dmarc.ietf.org>
From: Mike Koldychev <mkoldych@proton.me>
Cc: "Andrew Stone \\\\\\(Nokia\\\\\\)" <andrew.stone@nokia.com>, "pce@ietf.org" <pce@ietf.org>
Message-ID: <ysPlP4pwP5EKP2ehh1Vj_wKGbPVrtYjXzsSJBliG99_6AwyzWM6RRuX-7knDO9DLVJAo4o1slRhJ6GeQwy1wgaGpptLKk_H_NWslBdW96XM=@proton.me>
In-Reply-To: <7YZN_owTAWfKgXRToONjOuVlns88isBhhCV6-o0z7JnCsqDn-VNCX3Ww9oqBBXw7YuNjSjzKmSRt7A4-eSkUf9wuXGP9LgXCkIhnItkKxHA=@proton.me>
References: <170545250417.45332.14942466113369417174@ietfa.amsl.com> <BSdxctqZqshX3SWQgTDO8TfmlQK4ntm6Hfa1xI-CskFYGZcgnVeCcx8aHRW9HuKMoobavQryzgYmZZBkqQy64U5GyWzNqmix4CR0OGJBcPE=@proton.me> <C33DB899-8537-434F-8843-0329487CAEFE@nokia.com> <7YZN_owTAWfKgXRToONjOuVlns88isBhhCV6-o0z7JnCsqDn-VNCX3Ww9oqBBXw7YuNjSjzKmSRt7A4-eSkUf9wuXGP9LgXCkIhnItkKxHA=@proton.me>
Feedback-ID: 98235495:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/BxoxPuedm01s7j1Vg0fR_Le83Rk>
Subject: Re: [Pce] New Version Notification for draft-ietf-pce-segment-routing-policy-cp-13.txt
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 18 Mar 2024 02:40:17 -0000

Hi Andrew,

(sorry my email client glitched)

We did keep in sync with the IDR draft authors. The intent is to make the registry the same. There was an issue with interpretation of the Protocol Origin values 10, 20, 30 from RFC 9256. In PCEP we interpreted them as being actual code-points and some implementations have gone that way already. While in BGP, different code-points were used (1,2,3) instead of (10,20,30). This is why the IDR draft has separate codepoints for PCEP and non-PCEP (https://www.rfc-editor.org/rfc/rfc9256.html#name-protocol-origin-of-a-candid). It's a way to workaround the original misinterpretation without breaking the implementations.

Thanks,
Mike.

On Sunday, March 17th, 2024 at 10:35 PM, Mike Koldychev <mkoldych=40proton.me@dmarc.ietf.org> wrote:

> 
> 
> Hi Andrew,
> 
> We did keep in sync with the IDR draft authors. The intent is to make the registry the same. There was an issue with interpretation of the Protocol Origin values 10, 20, 30 from RFC 9256. In PCEP we interpreted them as being actual code-points and some implementations have gone that way already. While in BGP, different code-points were used. This is why the IDR draft has
> 
> 
> 
> 
> On Wednesday, January 17th, 2024 at 10:23 AM, Andrew Stone \(Nokia\) andrew.stone=40nokia.com@dmarc.ietf.org wrote:
> 
> > Hi Mike,
> > 
> > Thanks for addressing the comments, looks good to me.
> > 
> > Regarding section 6.5 - is it worth making the text identical to match https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-03#section-8.4 since I assume the intent is for both of these docs to use the same registry under Segment Routing? Naturally makes sense to not define values outside of the PCEP scope, however might be worth making sure the descriptions match even if they may appear redundant (i.e code point 1, 10, 20, 30). Comparing the two it's also not clear to me what code point value 1 is in IDR vs unassigned in PCEP.
> > 
> > With that said, considering IDR was proposing similar and the origins can be common amongst many different protocols, think it makes sense to have the registry under Segment Routing.
> > 
> > Thanks
> > Andrew
> > 
> > On 2024-01-16, 11:48 PM, "Pce on behalf of Mike Koldychev" <pce-bounces@ietf.org mailto:pce-bounces@ietf.org on behalf of mkoldych=40proton.me@dmarc.ietf.org mailto:40proton.me@dmarc.ietf.org> wrote:
> > 
> > Hi WG,
> > 
> > I addressed all comments that I received so far (let me know if I missed anything).
> > 
> > I copied some text from [I-D.ietf-idr-segment-routing-te-policy] into Section 5.3, to avoid making a normative reference to that draft. So we should probably review it again in more detail.
> > 
> > Also, we need to double check Section 6.5 (https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5), to make sure it's a good idea to create the new registry under Segment Routing instead of under PCEP.
> > 
> > Thanks,
> > Mike.
> > 
> > Sent with Proton Mail secure email.
> > 
> > On Tuesday, January 16th, 2024 at 7:48 PM, internet-drafts@ietf.org mailto:internet-drafts@ietf.org <internet-drafts@ietf.org mailto:internet-drafts@ietf.org> wrote:
> > 
> > > A new version of Internet-Draft
> > > draft-ietf-pce-segment-routing-policy-cp-13.txt has been successfully
> > > submitted by Mike Koldychev and posted to the
> > > IETF repository.
> > > 
> > > Name: draft-ietf-pce-segment-routing-policy-cp
> > > Revision: 13
> > > Title: PCEP Extensions for SR Policy Candidate Paths
> > > Date: 2024-01-16
> > > Group: pce
> > > Pages: 23
> > > URL: https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-13.txt https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-13.txt
> > > Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
> > > HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp
> > > Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-13 https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-13
> > > 
> > > Abstract:
> > > 
> > > A Segment Routing (SR) Policy is a non-empty set of SR Candidate
> > > Paths, which share the same <headend, color, endpoint> tuple. SR
> > > 
> > > Policy is modeled in PCEP as an Association of one or more SR
> > > Candidate Paths. PCEP extensions are defined to signal additional
> > > attributes of an SR Policy. The mechanism is applicable to all SR
> > > forwarding planes (MPLS, SRv6, etc.).
> > > 
> > > The IETF Secretariat
> > 
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org mailto:Pce@ietf.org
> > 
> > https://www.ietf.org/mailman/listinfo/pce https://www.ietf.org/mailman/listinfo/pce
> > 
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce