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

[Andrew Stone (Nokia)]

Thanks for that explanation Mike. Clear now.  Consider my comment on this 
closed.

Thanks! 
Andrew


On 2024-03-17, 10:40 PM, "Mike Koldychev" mailto:mkold...@proton.me>> wrote:


[You don't often get email from mkold...@proton.me . 
Learn why this is important at 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 
).
 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 
mailto:40proton...@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@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" 
> > mailto:pce-boun...@ietf.org> 
> > mailto:pce-boun...@ietf.org  on behalf of 
> > mkoldych=40proton...@dmarc.ietf.org  
> > mailto:40proton...@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-dra...@ietf.org 
> >  mailto:internet-dra...@ietf.org 
> >   >  mailto:internet-dra...@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

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

[Mike Koldychev]

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 
 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@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" 
> > mailto:pce-boun...@ietf.org on behalf of 
> > mkoldych=40proton...@dmarc.ietf.org mailto:40proton...@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-dra...@ietf.org 
> > mailto:internet-dra...@ietf.org  > mailto:internet-dra...@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  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 m

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

[Mike Koldychev]

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\) 
 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" 
> mailto:pce-boun...@ietf.org on behalf of 
> mkoldych=40proton...@dmarc.ietf.org mailto:40proton...@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-dra...@ietf.org 
> mailto:internet-dra...@ietf.org  mailto:internet-dra...@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  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

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev]

Hi Boris,

Sorry for the late reply...

1.1) Yes, it's basically always going to be set to 1. There isn't expected to 
be any other values there in the future, this field is basically unused.

1.2) I've removed that sentence in version 15. I think the intent was that the 
PCC can have multiple loopbacks, but this text just adds confusion and isn't 
necessary.

1.3) Normally, when the PCE creates a new LSP in a new Association, it can 
choose the Association ID however it wants. So if the ID is some 16-bit number, 
then the PCE can choose a random number for example. But in the SR Policy 
use-case this can lead to a (very rare) race condition when two PCEs both 
decide to create the same SR Policy at exactly the same time. Each PCE would 
choose some random number as the Association ID and each PCE sends its random 
Association ID in its PCInitiate message. Now the PCC would receive two 
PCInitiate messages asking to create the same SR Policy (same color and 
endpoint), but these two messages have different Association IDs. To avoid this 
mess, it's just cleaner to make Association ID == Color + Endpoint, so that the 
two PCEs don't have to pick a "random number" for the Association ID. They 
always send a deterministic value. Hopefully that clears it up?

Thanks,
Mike.

On Tuesday, January 23rd, 2024 at 5:17 AM, Boris Khasanov 
 wrote:

> Hi all,
> Sorry for being late, I fully support the adoption too.
>
> Some small comments for the better understanding:
> 1) Section 4.1 Association parameters
> 1.1) Association ID which should be set to 1, will it never be used and 
> should be kept as '1" ?
>
> 1.2) This sentence sounds confusing, IMO:
> "If the PCC receives a PCInit message with the Association Source set not to 
> the headend IP but to some globally unique IP address that the headend owns, 
> then the PCC SHOULD accept the PCInit message and create the SRPA with the 
> Association Source that was sent in the PCInit message."
>
> Why do we need such dualism here? I mean this other IP-address which should 
> be delivered to PCE in advance etc. Complicates an implementation IMO.
>
> 1.3) Also not exactly clear how these parameters can help to escape "a race 
> condition when multiple PCEP speakers want to create the same SR Policy at 
> the same time." Can you please clarify?
> 2) Can you please add into section 7 (Implementation status) some info/plans 
> about the Invalidation TLV. It is very important mechanism in practice.
>
> Thank you.
>
> SY,
> Boris
>
> 08.01.2024, 13:29, "Dhruv Dhody" :
>
>> Hi WG,
>>
>> This email starts a 2-weeks working group last call for 
>> draft-ietf-pce-segment-routing-policy-cp-12.
>>
>> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/
>>
>> Please indicate your support or concern for this draft. If you are opposed 
>> to the progression of the draft to RFC, please articulate your concern. If 
>> you support it, please indicate that you have read the latest version and it 
>> is ready for publication in your opinion. As always, review comments and 
>> nits are most welcome.
>>
>> The WG LC will end on Monday 22nd January 2024.
>>
>> A general reminder to the WG to be more vocal during the last-call/adoption.
>>
>> Thanks,
>> Dhruv & Julien
>>
>> ,
>>
>> ___
>> 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

Re: [Pce] Shepherd Review of draft-ietf-pce-segment-routing-policy-cp-14

[Mike Koldychev]

Hi Dhruv,

I've incorporated your changes and all the other comments that I have received 
so far. Hopefully I didn't miss anything. Version 15 is uploaded. Thanks a lot 
for your comments and updates!

Thanks,
Mike.

On Saturday, March 9th, 2024 at 8:23 AM, Dhruv Dhody  
wrote:

> Hi Authors,
>
> I have finished the shepherd review of 
> draft-ietf-pce-segment-routing-policy-cp-14. Please handle these comments 
> before we ship this I-D to IESG.
>
> ## Major- Section 5.6, you need to add update: RFC 8231 in the draft 
> metadata. This should also be captured in the abstract. The prefered way is 
> to clearly identify the text in RFC8231 that is changing with "OLD:" and 
> "NEW:" format!
> - Section 8, Security considerations need to also cover the non-SRPA TLVs 
> which are not considered in the current text.
>
> ## Query
> - Section 4.1,
> 
> If the PCC receives a
> PCInit message with the Association Source set not to the headend IP
> but to some globally unique IP address that the headend owns, then
> the PCC SHOULD accept the PCInit message and create the SRPA with the
> Association Source that was sent in the PCInit message.
> 
> What is the purpose of this text? PCC should use the source as set by the PCE 
> - isn't it given? Am I missing something? Boris also pointed this out in his 
> review.
>
> ## Minor
> - Abstract is not very useful for a non-expert. Maybe change something like -
> 
> OLD:
> A Segment Routing (SR) Policy is a non-empty set of SR Candidate
> Paths, which share the same  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.).
> NEW:
> Segment Routing (SR) allows a node to steer a packet flow along any
> path. SR Policy is an ordered list of segments (i.e.,
> instructions) that represent a source-routed policy. Packet flows
> are steered into an SR Policy on a node where it is instantiated
> called a headend node. An SR Policy is made of one or more candidate
> paths.
>
> This document specifies Path Computation Element Communication
> Protocol (PCEP) extension to associate candidate paths of the SR
> Policy. It applies equally to the SR-MPLS and Segment Routing over
> IPv6 (SRv6) instantiations of segment routing.
> END
> 
> - Similarly I find Introduction to be very light on details. Consider adding 
> text by looking through recently published RFCs for instance.
> - Terminology:
> ```
> OLD:
> SRPA: SR Policy Association. PCEP ASSOCATION that describes the SR
> Policy. Depending on discussion context, it refers to a PCEP
> object or to a group of LSPs that belong to the Association.
> NEW:
> SRPA: SR Policy Association. A new association type 'SR Policy
> Association' is used to group candidate paths belonging to the SR
> Policy. Depending on discussion context, it can refer to the PCEP
> ASSOCIATION object of SR Policy type or to a group of LSPs that
> belong to the association.
> END
> ```
> - Section 4, please add this text at the start -
> 
> As per [RFC8697], LSPs are associated with other LSPs with which they
> interact by adding them to a common association group. As described
> in [RFC8697], the association group is uniquely identified by the
> combination of the following fields in the ASSOCIATION object:
> Association Type, Association ID, Association Source, and (if
> present) Global Association Source or Extended Association ID,
> referred to as Association Parameters.
> 
> - Section 4.2, since none of the TLV are multi-instance. Can we simplify this 
> text -
> 
> OLD:
> Unless specifically stated otherwise, the TLVs listed in the
> following sub-sections are assumed to be single instance. Meaning,
> only one instance of the TLV SHOULD be present in the object and only
> the first instance of the TLV SHOULD be interpreted and subsequent
> instances SHOULD be ignored.
> NEW:
> This document specifies four new TLVs to be carried in the SRPA object.
> Only one TLV instance of each type can be carried, and only the first
> occurrence is processed. Any others MUST be ignored.
> 
> Also applicable to section 5!
> - Section 4.2.2, consider changing the SHOULD to MUST in this section. I 
> could not think of a justification for SHOULD here!
> - Section 5.1,
> - please also state what happens if the TLVs are used without the exchange of 
> SRPOLICY-CAPABILITY TLV or the corresponding bit is unset. Without it, what 
> is the use of adding this TLV?
> - Consider updating the description such as "P-flag: If set to '1' by a PCEP 
> speaker, the P flag indicates that the PCEP speaker supports the handling of 
> COMPUTATION-PRIORITY TLV for the SR Policy."
> - please add "Unassigned bits MUST be set to '0' on transmission and MUST be 
> ignored on receipt."
> - Section 5.2, I am unsure about the interaction between the unsetting of 
> P-flag (PCEP speaker d

[Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-15.txt

[internet-drafts]

Internet-Draft draft-ietf-pce-segment-routing-policy-cp-15.txt is now
available. It is a work item of the Path Computation Element (PCE) WG of the
IETF.

   Title:   Path Computation Element Communication Protocol (PCEP) Extensions 
for Segment Routing (SR) Policy Candidate Paths
   Authors: Mike Koldychev
Siva Sivabalan
Colby Barth
Shuping Peng
Hooman Bidgoli
   Name:draft-ietf-pce-segment-routing-policy-cp-15.txt
   Pages:   25
   Dates:   2024-03-17

Abstract:

   Segment Routing (SR) allows a node to steer a packet flow along any
   path.  SR Policy is an ordered list of segments (i.e., instructions)
   that represent a source-routed policy.  Packet flows are steered into
   an SR Policy on a node where it is instantiated called a headend
   node.  An SR Policy is made of one or more candidate paths.

   This document specifies Path Computation Element Communication
   Protocol (PCEP) extension to associate candidate paths of the SR
   Policy.  Additionally, this document updates [RFC8231] to allow
   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
   This document is applicable to both Segment Routing over MPLS and to
   Segment Routing over IPv6 (SRv6).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-15

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-15

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-state-sync-07.txt

[internet-drafts]

Internet-Draft draft-ietf-pce-state-sync-07.txt is now available. It is a work
item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Inter Stateful Path Computation Element (PCE) Communication 
Procedures.
   Authors: Stephane Litkowski
Siva Sivabalan
Cheng Li
Haomian Zheng
   Name:draft-ietf-pce-state-sync-07.txt
   Pages:   35
   Dates:   2024-03-17

Abstract:

   The Path Computation Element (PCE) Communication Protocol (PCEP)
   provides mechanisms for PCEs to perform path computation in response
   to a Path Computation Client (PCC) request.  The Stateful PCE
   extensions allow stateful control of Multi-Protocol Label Switching
   (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using
   PCEP.

   A Path Computation Client (PCC) can synchronize an LSP state
   information to a Stateful Path Computation Element (PCE).  A PCC can
   have multiple PCEP sessions towards multiple PCEs.  There are some
   use cases, where an inter-PCE stateful communication can bring
   additional resiliency in the design, for instance when some PCC-PCE
   session fails.

   This document describes the procedures to allow a stateful
   communication between PCEs for various use-cases and also the
   procedures to prevent computations loops.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-state-sync/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-pce-state-sync-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-state-sync-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] I-D Action: draft-ietf-pce-stateful-pce-optional-08.txt

[internet-drafts]

Internet-Draft draft-ietf-pce-stateful-pce-optional-08.txt is now available.
It is a work item of the Path Computation Element (PCE) WG of the IETF.

   Title:   Extension for Stateful PCE to allow Optional Processing of PCE 
Communication Protocol (PCEP) Objects
   Authors: Cheng Li
Haomian Zheng
Stephane Litkowski
   Name:draft-ietf-pce-stateful-pce-optional-08.txt
   Pages:   12
   Dates:   2024-03-17

Abstract:

   This document introduces a mechanism to mark some of the Path
   Computation Element (PCE) Communication Protocol (PCEP) objects as
   optional during PCEP messages exchange for the Stateful PCE model to
   allow relaxing some constraints during path computation and setup.
   This document introduces this relaxation to stateful PCE and updates
   RFC 8231.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-optional/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-optional-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-optional-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce