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

[Ketan Talaulikar <[e-mail]>]

Hi Mike,

Thanks for sharing the exercise we did for this sync between the PCEP and
IDR documents.

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-15.html#section-6.5
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-04#section-8.4

Can you please align the allocation policy in the PCEP document to match
the BGP-LS document which more closely follows the practice in the SR
parameters registry group?

Right now, the initial allocations in the PCEP document are a subset of the
BGP-LS document. This was intentional and reflects the code points used by
the respective documents.

Whichever of these documents progresses first to publication, will end up
creating this new registry under "Segment Routing Parameters" with the
initial allocations in that document while the other document will probably
need to simply update their IANA section suitably. The authors of the two
documents should keep in close touch as these documents progress.

The BGP-LS document has a note to this effect in the IANA section and I
suggest a similar note be added to the PCEP document as well.

Also copying IDR chairs to keep them informed.

Thanks,
Ketan


On Mon, Mar 18, 2024 at 8:38 AM Andrew Stone (Nokia) <andrew.stone=
[e-mail]> wrote:

> Thanks for that explanation Mike. Clear now.  Consider my comment on this
> closed.
>
> Thanks!
> Andrew
>
>
> On 2024-03-17, 10:40 PM, "Mike Koldychev" <[e-mail] <mailto:
> [e-mail]>> wrote:
>
>
> [You don't often get email from [e-mail] <mailto:
> [e-mail]>. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification <
> https://aka.ms/LearnAboutSenderIdentification> ]
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
>
>
>
> 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
> <
> 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=
> [e-mail] <mailto:[e-mail]>> 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=[e-mail] <mailto:[e-mail]>
> 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
> <
> 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" <
> [e-mail] <mailto:[e-mail]> mailto:
> [e-mail] <mailto:[e-mail]> on behalf of mkoldych=
> [e-mail] <mailto:[e-mail]> mailto:
> [e-mail] <mailto:[e-mail]>> 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>
>
> 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, [e-mail]
> <mailto:[e-mail]> mailto:[e-mail] <mailto:
> [e-mail]> <[e-mail] <mailto:
> [e-mail]> mailto:[e-mail] <mailto:
> [e-mail]>> 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>
>
> 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/>
> 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>
>
> 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>
>
> 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
> > > [e-mail] <mailto:[e-mail]> mailto:[e-mail] <mailto:
> [e-mail]>
> > >
> > > https://www.ietf.org/mailman/listinfo/pce <
> https://www.ietf.org/mailman/listinfo/pce>
> https://www.ietf.org/mailman/listinfo/pce <
> https://www.ietf.org/mailman/listinfo/pce>
> > >
> > > _______________________________________________
> > > Pce mailing list
> > > [e-mail] <mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/pce <
> https://www.ietf.org/mailman/listinfo/pce>
>
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce
>