Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Dhruv,

Sure, I’ll take note and update in -14 version.

Thanks,
Mike.

From: Dhruv Dhody 
Sent: Wednesday, January 24, 2024 12:59 AM
To: Mike Koldychev (mkoldych) 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org
Subject: Fwd: Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp-12

Hi Mike,

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-13.html#section-6.2

Can the TBD4 SR-POLICY-CAPABILITY be changed to  SRPOLICY-CAPABILITY to match 
the naming style for other TLVs?

Thanks!
Dhruv

-- Forwarded message -
From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Wed, Jan 24, 2024 at 11:21 AM
Subject: Re: Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp-12
To: mailto:pce@ietf.org>>
Cc: 
mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>,
 pce-chairs mailto:pce-cha...@ietf.org>>

Hi WG,

We received no objections and thus will be going ahead with the early 
allocation process.

Thanks!
Dhruv & Julien

On Wed, Jan 10, 2024 at 6:53 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

We have received a request from the authors of 
draft-ietf-pce-segment-routing-policy-cp for an early code point allocation for 
the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.2
 (TBD1-4)
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.3
 (TBD6-8)
https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-12.html#section-6.4
 (TBD9)
Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8GtjtxNWeA9MxpySx6J7XZKmlUc/
Note that the draft is also undergoing a parallel WGLC - 
https://mailarchive.ietf.org/arch/msg/pce/ert_k7k5iYq3LWbaTc-aMwRRAbs/

RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Wednesday, Jan 24th, we will kick off the early allocation request.

Thanks!
Dhruv & Julien
___
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 (mkoldych)]

Hi Dhruv,

There are still a few minor pending comments that I plan to address, so we will 
need a version -14.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 22, 2024 11:26 PM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

The WGLC has ended. Thanks to everyone who contributed with review comments 
during this last call discussion. These are very helpful to gauge the consensus 
of the WG to move the draft forward towards publication.

Authors,

Thanks for posting -13. Is there a need for another version update to handle 
any pending comments or are we ready to go?

Thanks!
Dhruv & Julien





On Mon, Jan 8, 2024 at 3:58 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
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

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

[Mike Koldychev (mkoldych)]

Hi Cheng,

Thanks for your review! Comments inline with .

Thanks,
Mike.


From: Cheng Li 
Sent: Tuesday, January 16, 2024 11:09 AM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and support the WGLC.
However, I also have some minor comments below.


1.
Abstract

A Segment Routing (SR) Policy 
[RFC9256] is a non-empty set of SR 
Candidate Paths, that share the same  tuple.
1.Nits: s/that/which.

Sure.


2.share the same <> tuple?

Sorry, not clear what your comment is here? The text is referring to the 
3-tuple that identifies the SR Policy, from here: 
https://www.rfc-editor.org/rfc/rfc9256.html#name-identification-of-an-sr-pol


3.This document extends [RFC8664] to 
fully support the SR Policy construct.
fully? suggest to remove this world. The SR policy is developing, so it can not 
be fully supported now I guess.

Sure, I will remove the “fully”.



4.
Introduction

PCEP Extensions for Segment Routing 
[RFC8664] specifies extensions that 
allow PCEP to work with basic SR-TE 
paths.¶
s/specifies/specify

Sure, I can just use the RFC Number, instead of the full name.


PCEP Extensions for Establishing Relationships Between Sets of LSPs 
[RFC8697] introduces
s/introduces/introduce because of extensions?  or you only wanto to list the 
name of the RFC here? anyway, all are nits. Normally, we use RFC as the 
subject directly.

Sure, I can just use the RFC Number, instead of the full name.


5. again. Suggest to delete 'fully' in the last paragraph of Introduction.

Will do.


6.
SR Policy Association. PCEP ASSOCATION that describes the SR Policy. Can refer 
to the PCEP object or to the group of LSPs that belong to the Association. This 
should be clear from the 
context.¶

suggest to rephrase this description to be more formal? , too casual to me.

Sure, will rephrase. There was a prior comment about this as well.


7.When these rules are not satisfied, the PCE MUST send a PCErr message with 
Error-Type = 26 "Association Error", Error Value = TBD8

Only the PCE sends? do we have any case that a PCC may send this error?

True, it should be “PCEP speaker”, not “PCE”. Thanks.


8.

This Association Type is dynamic in nature, thus operator-configured 
Association Range MUST NOT be set for this Association type and MUST be 
ignored.¶

Sorry I do not understand this paragraph. What do you mean this association 
type is dynamic in nature?

It’s referring to this: https://www.rfc-editor.org/rfc/rfc8697.html#section-3.4 
. The text is basically saying that this Association Type is fully dynamic. I’m 
not sure if this is necessary to say, or if we can rephase it to be clearer? 
Any suggestions?


9.
·Association ID (16-bit): set to 
"1".¶
why the ID must be set as 1? do you mean a association is identified by 
association source, color, and endpoint in extended association ID TLV? so we 
do not need Association ID?
or you like to use This ID 1 to avoid the race case between multiple PCE?

Yes, the association is identified by , so this 16-bit 
field is not useful. We set it to “1” to avoid using “0”, which is a reserved 
value for that field. I can put a sentence to clarify this in the text.



10.

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  ~   SR Policy Name  ~
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 
2:
 The SRPOLICY-POL-NAME TLV 
format

Though I can not image what may be added to this TLV now. But I think reserving 
0 bits for a new TLV is not a good decision.
same for "SRPOLICY-CPATH-NAME" TLV

It’s not reserving 0 bits. If you read the description of the TLV, it encodes a 
policy name string.



11. secti

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

[Mike Koldychev (mkoldych)]

Hi Quan,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Pce  On Behalf Of xiong.q...@zte.com.cn
Sent: Sunday, January 14, 2024 10:01 PM
To: d...@dhruvdhody.com; draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce@ietf.org; pce-cha...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12




Hi PCE WG, Authors,

I have reviewed the latest version in details and I feel this draft is good 
written and I support the progression to RFC.

And I have two minor suggestions.

A，I noticed the [I-D.ietf-idr-segment-routing-te-policy] and 
[I-D.ietf-pce-multipath] are in the Normative References. I am not sure if the 
two drafts should be moved to Informative References when progess to RFC.

Good suggestion, thanks.


B, AS per [RFC9256] section 8.1, an SR policy is invalid when all candidate 
paths are invalid and the SR policy should  transit to invalid state including 
removing the SR Policy and BSID and so.

Maybe it is better to consider or clarify that in the PCEP SR policy. Thanks!

Sorry, what do you mean to clarify it? Isn’t it already clear from RFC9256?


Best Regards,

Quan

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

[Mike Koldychev (mkoldych)]

Hi Samuel,

IMO, it’s nice to have explicit and granular capability advertisement, so that 
the PCEP speakers are aware of what the other side supports. It’s not purely 
informational, some of these TLVs modify the PCC behavior, so the PCE may want 
to know in advance whether PCC will follow instructions or just ignore them.

Thanks,
Mike.

From: Samuel Sidor (ssidor) 
Sent: Friday, January 12, 2024 3:37 AM
To: Mike Koldychev (mkoldych) ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

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

Thanks Mike,

Agreed. Just one response to capability part:

Do we even need flags in SR Policy Capability TLV for advertising support of 
those various TLVs then? Or is that purely for informational (with no impact on 
processing of actual TLV)? If it is pure informational, then maybe consider 
adding some simple statement specifying it explicitly.) Because my 
understanding is that purpose of rule for ignoring unknown TLVs by default is 
specifically to avoid unnecessary capabilities.

Regards,
Samuel

From: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Sent: Thursday, January 11, 2024 7:22 PM
To: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Samuel Sidor (ssidor) mailto:ssi...@cisco.com>>
Sent: Wednesday, January 10, 2024 4:25 AM
To: 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; Dhruv Dhody 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?

Yes they are, I will add that statement to Section 5 as well, thanks.



  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?

I think generic PCEP behavior for treating unknown TLVs (ignore them) is 
correct when a PCEP speaker receives a TLV that it did not advertise capability 
for. Do we agree? If we agree, then I don’t see a need to add a statement 
re-iterating generic PCEP behavior.



  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?

I think your question is answered in the SR Policy Architecture RFC: 
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.1-6
“””
An implementation MAY allow the assignment of a symbolic name comprising 
printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to 
serve as a user-friendly attribute for debugging and troubleshooting purposes. 
Such symbolic names may identify an SR Policy when the naming scheme ensures 
uniqueness. The SR Policy name MAY also be signaled along with a candidate path 
of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names 
associated with it in the scenario where the headend receives different SR 
Policy names along with different candidate paths for the same SR Policy via 
the same or different sources.
“””
The unit of signaling in PCEP (and BGP-TE) is the Candidate Path. If we had 
another unit of signaling per-Association, then we could put the Policy Name 
there.



  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.

Thanks, I’ll update that.



  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks, I’ll fix tha

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

[Mike Koldychev (mkoldych)]

Hi Gyan,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Gyan Mishra 
Sent: Friday, January 12, 2024 1:31 AM
To: Dhruv Dhody 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs 

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


I support publication.

I have reviewed v12 and have a few minor comments.

At the end of the abstract section you could say forwarding planes of SR 
instead of dataplane.  As the data planes of SR would be MPLS and IPv6.

Old
The mechanism is applicable to all data planes of SR (MPLS, SRv6, etc.).

New

The mechanism is applicable to SR forwarding planes of SR (SR-MPLS SRv6, etc.).

OK thanks. I wasn’t aware of this terminology: data plane vs forwarding plane.



My understanding is that as RFC 8664 is the base PCEP extension for SR and this 
draft is an add on to the base SR PCEP extension to provide the CP support.

My thoughts was a more appropriate name for the draft as "PCEP extension for SR 
Policy Candidate paths" or "PCEP SR Extension for Candidate paths"


I think we can go with “PCEP Extensions for SR Policy Candidate Paths”, if 
nobody objects.


Kind Regards


[Image removed by sender.]

Gyan Mishra

Network Solutions Architect

Email gyan.s.mis...@verizon.com

M 301 502-1347



On Mon, Jan 8, 2024 at 5:29 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Mike Koldychev (mkoldych)]

Hi Haomian,

Thanks for your review! Comments inline with .

Thanks,
Mike.

From: Zhenghaomian 
Sent: Thursday, January 11, 2024 10:57 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi WG,

I read the document and think it’s in good shape.

Two minor comments as follow:


1.  In section 4.2 there is a new Error-Value TBD6 “Missing Mandatory TLV” 
(which is also inconsistent with the name in section 6.3), however for existing 
Error-Value under Error-Type “Mandatory Object Missing”, the missed TLVs are 
explicitly specified, so probably we can rename it as “SR policy Cpath ID 
missing” or something similar.

I would like to name the error value as “Missing SR Policy Mandatory TLV”, so 
that we can use the same error value for any other TLVs that are missing, to 
avoid creating a lot of code-points. I’ll make the name consistent with the 
text, thanks.



2.  In section 5.1 there are a few flags defined, do we need to show the 
‘flags’ fonts in the TLV format in Fig. 6? I mean the following:
   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Flags|L|S|I|E|P|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Sure, I can add that. Thanks.


Best wishes,
Haomian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 6:29 PM
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

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

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

[Mike Koldychev (mkoldych)]

Hi Huaimo,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

-Original Message-
From: Huaimo Chen  
Sent: Wednesday, January 10, 2024 11:12 AM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi Everyone,

I read through the document and have the following comments.

  1.  In Abstract, there are three references (one [RFC9256 ], two [RFC8664]s). 
It seems better to remove these references by rephrasing.
 
Sure, let me see if I can avoid references in the Abstract.


  2.  It seems that an SR Policy has one identifier which consists of Headend, 
color and endpoint.
 *   Should "SR Policy Identifiers uniquely identify the SR Policy within 
the network." in section 3.1 be changed to "An SR Policy Identifier uniquely 
identifies an SR Policy within the network. "?
 *   Should "SR Policy Identifiers consist of:" in section 3.1 be changed 
to "An SR Policy Identifier consists of:"?
 *   "Identifiers" in other sections may be changed accordingly.

Hmmm, I see your point. I guess "SR Policy Identifiers" can be misinterpreted 
to mean that each entry is a separate identifier on its own. 

Sure, I can change 'Identifiers" -> "Identifier" if nobody objects to it.



  1.  It seems that an SR Policy Candidate Path has one Identifier, which 
consists of  Protocol Origin, Originator and  Discriminator.
 *   Should "SR Policy Candidate Path Identifiers uniquely identify the SR 
Policy  Candidate Path within the context of an SR Policy." in section 3.2 be 
changed to "An SR Policy Candidate Path Identifier uniquely identifies an SR 
Policy  Candidate Path within the context of an SR Policy."?
 *   Should "SR Policy Candidate Path Identifiers consist of:" be changed 
to "An SR Policy Candidate Path Identifiers consists of:"?
 *   "Identifiers" in other sections (e.g., section 4.2.2) may be changed 
accordingly.

Sure, I can change 'Identifiers" -> "Identifier" if nobody objects to it.



  1.  In the second sentence of section 5.4, "streering" seems a typo.

Thanks, will fix.


Best Regards,
Huaimo
From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, January 8, 2024 5:29 AM
To: pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

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

___
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 (mkoldych)]

Hi Samuel,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Samuel Sidor (ssidor) 
Sent: Wednesday, January 10, 2024 4:25 AM
To: draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce-chairs ; pce@ietf.org; Dhruv Dhody 

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

Hi all,

Thanks a lot, to authors for doing this work. It is really important for 
supporting SR policies in PCEP. I support progress of this document to RFC.

A few minor comments:


  *   For TLVs in association section, there is explicitly mentioned that those 
are “single instance” TLVs (single instance processed, other instances 
ignored), but I don’t see it mentioned for TLVs in Section 5. Are those “single 
instance” TLVs as well?

Yes they are, I will add that statement to Section 5 as well, thanks.



  *   “SR Policy Capability TLV” is defining capabilities for 
TLVs/functionality in Section 5. It may be good to specify how those 
capabilities should be handled – e.g. if P flag (indicates support for 
“COMPUTATION-PRIORITY TLV”) is not set in “SR Policy Capability TLV”, but PCEP 
peer received that TLV. Is PCEP peer supposed to reject it or it is still 
acceptable to use it? If it should be rejected, what should be the PCError to 
reject it (unknown TLVs should be ignored by default)?

I think generic PCEP behavior for treating unknown TLVs (ignore them) is 
correct when a PCEP speaker receives a TLV that it did not advertise capability 
for. Do we agree? If we agree, then I don’t see a need to add a statement 
re-iterating generic PCEP behavior.



  *   “SR Policy name” is defined as CP attribute in section “SR Policy 
Candidate Path Attributes”. Is there any reason for that? I would assume that 
it is policy attribute and not CP attribute. Can policy name be different for 
different candidate-path of same policy?

I think your question is answered in the SR Policy Architecture RFC: 
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.1-6
“””
An implementation MAY allow the assignment of a symbolic name comprising 
printable ASCII [RFC0020] characters (i.e., 0x20 to 0x7E) to an SR Policy to 
serve as a user-friendly attribute for debugging and troubleshooting purposes. 
Such symbolic names may identify an SR Policy when the naming scheme ensures 
uniqueness. The SR Policy name MAY also be signaled along with a candidate path 
of the SR Policy (refer to Section 2.2). An SR Policy MAY have multiple names 
associated with it in the scenario where the headend receives different SR 
Policy names along with different candidate paths for the same SR Policy via 
the same or different sources.
“””
The unit of signaling in PCEP (and BGP-TE) is the Candidate Path. If we had 
another unit of signaling per-Association, then we could put the Policy Name 
there.



  *   Terminology section is defining abbreviation “SRPA” for SR Policy 
Association, but “SR Policy Association (SRPA)” or “SR Policy Association”is 
then used in a few places in the document. It may be better to replace it.

Thanks, I’ll update that.



  *   “SR-POLICY-CAPABLITY” -> “SR-POLICY-CAPABILITY” in section 5.1 (typo)

Thanks, I’ll fix that.


Thanks a lot,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Monday, January 8, 2024 11:29 AM
To: pce@ietf.org
Cc: pce-chairs mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: [Pce] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

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

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

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks for the feedback! Comments inline with .

Thanks,
Mike.

From: Andrew Stone (Nokia) 
Sent: Tuesday, January 9, 2024 2:05 PM
To: Dhruv Dhody ; pce@ietf.org
Cc: pce-chairs ; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: WGLC for draft-ietf-pce-segment-routing-policy-cp-12

Hi PCE WG, Authors,

I’ve read the latest version and it was a straight forward read and looks to be 
in good shape. In addition, comments I had during original adoption were also 
all addressed. I support progression of the document. Some minor 
comments/feedback below.

Thanks
Andrew



- Terminology section adjustment:

ORIGINAL
"Can refer to the PCEP object or to the group of LSPs that belong to the 
Association. This should be clear from the context.""

NEW
"Depending on discussion context, it refers to a PCEP object or to a group of 
LSPs that belong to the Association"


Good suggestion, thanks.



- At first I wondered why 'should' instead of must in the below text and 
wondered when would this occur. Realized PCC could determine destination from 
the ERO and occur with PcInit. Perhaps worth giving an example scenario?

ORIGINAL
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV"

NEW
"... PCEP speaker SHOULD extract the destination from the Endpoint field in the 
SRPA Extended Association ID TLV. For example, a PcInit message does not carry 
LSP-IDENTIFIERS and may not carry an END-POINTS object[RFC8281], therefore PCC 
SHOULD use the destination from the Endpoint field. "


I was unsure about using SHOULD vs MUST in the absence of LSP-IDENTIFIERS and 
END-POINTS. But perhaps it would be better to change it to MUST use Endpoint 
field of SRPA in this case, just to avoid unexpected/divergent behavior in 
implementations. There should be no ambiguity about what the destination of the 
policy is. What do we think about this?

For PCInit, the text in RFC8281 about inferring the destination from the ERO 
refers specifically to RSVP-TE implementations, but in SR-TE it may be 
difficult/impossible to do that inference from the SIDs.



From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Date: Monday, January 8, 2024 at 5:29 AM
To: "pce@ietf.org" mailto:pce@ietf.org>>
Cc: pce-chairs mailto:pce-cha...@ietf.org>>, 
"draft-ietf-pce-segment-routing-policy...@ietf.org"
 
mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>
Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: mailto:julien.meu...@orange.com>>, 
mailto:andrew.st...@nokia.com>>, 
mailto:d...@dhruvdhody.com>>
Resent-Date: Monday, January 8, 2024 at 5:29 AM


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

Re: [Pce] IPR poll for draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Mike.

From: Andrew Stone (Nokia) 
Sent: Monday, January 8, 2024 1:28 PM
To: pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Mike 
Koldychev (mkoldych) ; Sivabalan, Siva 
; cba...@juniper.net; pengshup...@huawei.com; Hooman 
Bidgoli (Nokia) ; Dhruv Dhody ; 
chengl...@huawei.com; Samuel Sidor (ssidor) 
Cc: pce-cha...@ietf.org
Subject: IPR poll for draft-ietf-pce-segment-routing-policy-cp

Hi Authors,

In preparation for WGLC on this draft, we'd like all authors and contributors 
to confirm on the list that they are in compliance with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

- I am not aware of any IPR applicable to this draft that should be disclosed 
in accordance with IETF IPR rules.
- I am aware of the IPR applicable to this draft, and it has already been 
disclosed to the IETF.
- I am aware of IPR applicable to this draft, but that has not yet been 
disclosed to the IETF. I will work to ensure that it will be disclosed in a 
timely manner.

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

Re: [Pce] WG Adoption of draft-chen-pce-bier-11

[Mike Koldychev (mkoldych)]

I Support the WG Adoption.

BIER-TE is a useful technology and could be naturally integrated with PCEP.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, September 25, 2023 12:49 PM
To: pce@ietf.org
Cc: draft-chen-pce-b...@ietf.org
Subject: [Pce] WG Adoption of draft-chen-pce-bier-11

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-bier-11.

https://datatracker.ietf.org/doc/draft-chen-pce-bier/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 9th Oct 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[Mike Koldychev (mkoldych)]

I support the WG adoption. It has been useful when implementing a 
proof-of-concept.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Tuesday, June 20, 2023 3:47 AM
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

Hi all,

It has been a while since draft-dhody-pce-stateful-pce-vendor started to 
document how to extend the scope of RFC 7470. It is now time to consider its 
adoption by the WG.
Do you think draft-dhody-pce-stateful-pce-vendor-16 [1] is ready to become a 
PCE work item? Please express your support and/or concerns using the mailing 
list.

Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-dhody-pce-stateful-pce-vendor

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law; they should not be distributed, used 
or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
___
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] I-D Action: draft-ietf-pce-segment-routing-policy-cp-11.txt

[Mike Koldychev (mkoldych)]

Hi WG,

Adding some enhancements to the draft:

* Added SR-POLICY-CAPABILITY TLV to signal whether a PCEP peer supports the 
extra TLVs/mechanisms that are defined in the draft.
* Added a section about making Stateless PCEP (PCReq/PCRep) OPTIONAL for SR 
Policy, thus updating RFC 8231.
  * Stateful bringup was previously in pce-operational draft, where it was for 
ALL LSP types. But defining it for all LSP types may not be a wise choice 
because the scope is very large. PCEP has many applications and new ones will 
be added.
  * To reduce the scope of the update to RFC8231, we allow stateful bringup on 
a per-application basis, rather than PCEP-wide.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 20, 2023 1:15 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-11.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Path Computation Element (PCE) WG of 
the IETF.

   Title   : PCEP extension to support Segment Routing Policy Candidate 
Paths
   Authors : Mike Koldychev
 Siva Sivabalan
 Colby Barth
 Shuping Peng
 Hooman Bidgoli
   Filename: draft-ietf-pce-segment-routing-policy-cp-11.txt
   Pages   : 22
   Date: 2023-06-20

Abstract:
   A Segment Routing (SR) Policy [RFC9256] is a non-empty set of SR
   Candidate Paths, that share the same 
   tuple.  This document extends [RFC8664] to fully support the SR
   Policy construct.  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, which are not covered
   by [RFC8664].  The mechanism is applicable to all data planes of SR
   (MPLS, SRv6, etc.).

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

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

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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-multipath-08.txt

[Mike Koldychev (mkoldych)]

Hi WG,

Summary of changes:
*   Remove reference to "PCEP Tunnel".
*   Provide a use case for using Reverse Path information.
*   Move the Capability section and reword it.
*   Added Forward Class for the Composite CP.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Monday, May 1, 2023 2:26 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-multipath-08.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Path Computation Element (PCE) WG of 
the IETF.

   Title   : PCEP Extensions for Signaling Multipath Information
   Authors : Mike Koldychev
 Siva Sivabalan
 Tarek Saad
 Vishnu Pavan Beeram
 Hooman Bidgoli
 Bhupendra Yadav
 Shuping Peng
 Gyan Mishra
   Filename: draft-ietf-pce-multipath-08.txt
   Pages   : 24
   Date: 2023-05-01

Abstract:
   Certain traffic engineering path computation problems require
   solutions that consist of multiple traffic paths, that together form
   a solution.  Returning just one single traffic path does not provide
   a valid solution.  This document defines a mechanism to encode
   multiple paths for a single set of objectives and constraints.  This
   is a generic PCEP mechanism, not specific to any path setup type or
   dataplane.  The mechanism is applicable to both stateless and
   stateful PCEP.

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

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

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-multipath-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

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

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

[Mike Koldychev (mkoldych)]

Changes summary:
*   Remove the RRO section, as it seems to be causing controversy.
*   Re-word some sections.
*   Mention that ASSOC-Type-List TLV MUST be used with SR Policy 
Association.
*   Add some clarification about how destination is determined.
*   Add some clarification about how CP ID TLV is filled.
*   Add some explanation of how the Invalidation TLV is used.
*   Add IANA section for Protocol Origin, new registry under Segment 
Routing, will be common between PCE and IDR (BGP-LS, BGP-TE).

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Friday, April 21, 2023 2:08 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-10.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the Path Computation Element (PCE) WG of 
the IETF.

   Title   : PCEP extension to support Segment Routing Policy Candidate 
Paths
   Authors : Mike Koldychev
 Siva Sivabalan
 Colby Barth
 Shuping Peng
 Hooman Bidgoli
   Filename: draft-ietf-pce-segment-routing-policy-cp-10.txt
   Pages   : 21
   Date: 2023-04-21

Abstract:
   A Segment Routing (SR) Policy [RFC9256] is a non-empty set of SR
   Candidate Paths, that share the same 
   tuple.  This document extends [RFC8664] to fully support the SR
   Policy construct.  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, which are not covered
   by [RFC8664].  The mechanism is applicable to all data planes of SR
   (MPLS, SRv6, etc.).

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

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

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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

[Mike Koldychev (mkoldych)]

Hi WG,

I have read the latest version of the document. I support the WG LC, as a 
co-author. This work is necessary for SRv6 deployment of the PCE.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Monday, February 13, 2023 12:39 PM
To: pce@ietf.org
Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

Dear PCE WG,

This message starts a 2-week WG last call on
draft-ietf-pce-segment-routing-ipv6-15 [1]. Please, be express any comments you 
have about this document using the PCE mailing list.

This WGLC will end on Tuesday 28th February 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-ipv6/

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

Re: [Pce] IPR Poll on draft-ietf-pce-segment-routing-ipv6-15

[Mike Koldychev (mkoldych)]

Hi,

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

Thanks,
Mike.

From: Hariharan Ananthakrishnan 
Sent: Monday, February 13, 2023 10:21 PM
To: preje...@rtbrick.com; msiva...@gmail.com; c...@huawei.com; Mike Koldychev 
(mkoldych) ; Mahend Negi ; 
zhu...@chinatelecom.cn
Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-segment-routing-ipv6-15


Hi Authors,

In preparation for WG LC on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[Mike Koldychev (mkoldych)]

I appreciate the feedback, it's good that we settled on a decision. I will go 
ahead and split it into 2 documents.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Monday, January 16, 2023 11:58 AM
To: pce@ietf.org
Subject: Re: [Pce] Scoping Items from draft-koldychev-pce-operational

Dear PCE WG,

This issue has been opened for while. Thank you to those who took time to share 
their views.

We acknowledge that having a single document may be likely to reduce the 
initial paperwork (at least until the I-D starts to be reviewed by people 
outside the PCE WG). However, as stated by Adrian, the line between updates and 
clarifications "must not be blurry", all the more as the standard track piece 
of work may update some RFCs. This must be true both for us, as a WG, and for 
future reader of the documents, especially if they are not familiar with IETF 
way of working when it comes to multi-status document content.

As a result, let's follow John's guidelines, voiced during the London meeting, 
and split the I-D into 2 documents with focused status. 
Starting from there, we'll be able to move forward.

Thank you,

Dhruv & Julien


On 29/09/2022 10:37, julien.meu...@orange.com wrote:
> Dear PCE WG,
>
> Let's follow up on the discussion started during IETF 114 about 
> draft-koldychev-pce-operational [1]. The I-D currently tackles 
> different issues about PCEP, some of them being informational, some 
> other updating existing PCEP specifications. Among the options we 
> discussed to proceed with this work, 2 remain:
> 1. Keep a single draft, but clearly separate the two types of content; 
> 2. Break it up into 2 drafts.
>
> We'd like to hear the WG's opinion whether you prefer:
> a- a single standard track I-D, with both content types sharing fate 
> until publication?
> b- a clarification I-D on informational track + an I-D updating PCEP 
> on standard track (possibly progressing at different paces)?
>
> Please share your feedback using the PCE mailing list.
>
> Thanks,
>
> Dhruv & Julien
>
>
> [1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/
>
>
>
> ___
> 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] WG Adoption of draft-rajagopalan-pce-pcep-color-02

[Mike Koldychev (mkoldych)]

As a co-author, I support the adoption of this draft. The signaling of color 
has many uses in PCE based traffic engineering.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Thursday, December 1, 2022 12:07 AM
To: pce@ietf.org
Cc: draft-rajagopalan-pce-pcep-co...@ietf.org
Subject: [Pce] WG Adoption of draft-rajagopalan-pce-pcep-color-02

Hi WG,

This email begins the WG adoption poll for draft-rajagopalan-pce-pcep-color-02.

https://datatracker.ietf.org/doc/draft-rajagopalan-pce-pcep-color/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Friday 16th Dec 2022.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] IPR Poll on draft-rajagopalan-pce-pcep-color-02

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.

Thanks,
Mike.

From: Hariharan Ananthakrishnan 
Sent: Thursday, December 1, 2022 4:23 PM
To: peng.sha...@zte.com.cn; bala...@juniper.net; vbee...@juniper.net; Mike 
Koldychev (mkoldych) ; xiong.q...@zte.com.cn; 
gyan.s.mis...@verizon.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-rajagopalan-pce-pcep-color-02


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[Mike Koldychev (mkoldych)]

I prefer option A as well.

1) The original intent of the document was to make interop easier: sometimes by 
clarifying things and sometimes by tweaking the standard. Having two documents 
for one intent is just going to lead to more paperwork IMHO. 

2) The proposed updates to the PCEP standard are not "major" updates.

3) The line between updating the standard vs clarifying the standard can be 
blurry in some cases.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Thursday, September 29, 2022 5:08 PM
To: julien.meu...@orange.com; pce@ietf.org
Subject: Re: [Pce] Scoping Items from draft-koldychev-pce-operational

Hi PCE Chairs, PCE WG:

Prefer option A - single document with both contents covered, ideally with 
appropriate wording or sections for the two types of content. 

As mentioned in the last WG session, I see the document as a valuable 
implementation interop checkpoint for various PCE implementations. In this 
situation, having both types of content (some of which can be a bit of a gray 
definition of update vs inform) consolidated in one document makes it simpler 
to digest that converged view. 

Thanks
Andrew

On 2022-09-29, 4:37 AM, "Pce on behalf of julien.meu...@orange.com" 
 wrote:

Dear PCE WG,

Let's follow up on the discussion started during IETF 114 about 
draft-koldychev-pce-operational [1]. The I-D currently tackles different 
issues about PCEP, some of them being informational, some other updating 
existing PCEP specifications. Among the options we discussed to proceed 
with this work, 2 remain:
1. Keep a single draft, but clearly separate the two types of content;
2. Break it up into 2 drafts.

We'd like to hear the WG's opinion whether you prefer:
a- a single standard track I-D, with both content types sharing fate 
until publication?
b- a clarification I-D on informational track + an I-D updating PCEP on 
standard track (possibly progressing at different paces)?

Please share your feedback using the PCE mailing list.

Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/



___
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] IPR Poll on draft-li-pce-pcep-srv6-yang-07

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.

Thanks,
Mike.

From: Hariharan Ananthakrishnan 
Sent: Saturday, September 3, 2022 12:04 AM
To: luc-fabrice.ndi...@mtn.com; ssiva...@ciena.com; c...@huawei.com; Mike 
Koldychev (mkoldych) ; pengshup...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-li-pce-pcep-srv6-yang-07


Hi Authors,

In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] I-D Action: draft-koldychev-pce-operational-05.txt

[Mike Koldychev (mkoldych)]

Hi Adrian,

Thanks for the useful review comments. I will address most of them in the next 
version. See my replies inline with [MK].

Thanks,
Mike.

-Original Message-
From: Adrian Farrel  
Sent: Sunday, February 20, 2022 3:34 PM
To: draft-koldychev-pce-operatio...@ietf.org
Cc: pce@ietf.org
Subject: RE: I-D Action: draft-koldychev-pce-operational-05.txt

Hi authors,

I really appreciate the work done through interop to better understand protocol 
specs and revise the protocol. I hope that you are not all talking yourselves 
into an interop mode that changes the specs because that seems to interoperate, 
rather than fixing implementations to conform to the current specs (which were 
thought about quite a bit ;-)

In the end, of course, we should document what is implemented and interoperates 
(provided it works!).

I did a very light skim of the document and I found a number of issues that 
concern me.

Best,
Adrian

---

In section 3 you have:
   We introduce the concept of the LSP-DB, as a database of actual LSP
   state in the network

I don't think you do 😊

You might start with RFC 7399 and RFC 8051.

Possibly you are introducing the concept of the PCC LSP-DB.

[MK] Sure will change the wording.[/MK]

---

In section 3 you say

   The structure and format
   of the LSP-DB MUST be common among all dataplane types (i.e., RSVP-
   TE/SR-TE/SRv6), all instantiation methods (i.e., PCC-initiated/PCE-
   initiated), all destination types (i.e., point-to-point/point-to-
   multipoint).

This should be self-evidently wrong. The LSP-DB is internal to the PCE 
implementation, so while it is true that the PCE needs to be able to derive 
certain information from the LSP-DB, how it stores that information is 
completely its own business. Now, you may want an abstract representation in 
order to define your state machines, and that is fine, but please don't tell 
implementations how to implement.

[MK] Was simply saying that whatever mechanisms we define for manipulating the 
LSP database must be common among all dataplane types. I can just remove this 
paragraph as it's sort of obvious anyway.[/MK]

---

In 3.2 you have

   The PCC adds/removes entries to/from its LSP-DB based on what LSPs it
   creates/destroys in the network.  There can be many trigger types for
   updating the PCC LSP-DB, some examples include PCUpd messages, local
   computation on the PCC, local configuration on the PCC, etc.  The
   trigger type does not affect the content of the PCC LSP-DB, i.e., the
   content of the PCC LSP-DB is updated identically regardless of the
   trigger type.

But surely a PCUpd message does not immediately affect the state of the LSP in 
the network. Depending on the signaling process and the processing at the PCC, 
that may take some time. So, you need to be careful when you include PCUpd as a 
trigger and then say that all trigger types are to be treated equally.

[MK] Wasn't saying anything about "immediately" here? I was saying "identically 
regardless of the trigger type". But let me try to condense/rework a lot of the 
wording since it may be confusing.[/MK]

Later (in 3.2) you say:
   The LSP-DB on both the PCC and the PCE only stores the actual state
   in the network, it does not store the desired state.
Which seems to say that PCUpd is not a trigger.

In fact, the PCE and PCC need to store both the "currently believed current 
state" and the "state that is being attempted". How this state is stored is a 
very moot point because the LSP-DB is a logical concept. [In previous work] it 
expresses the information stored by the PCE about the active LSPs, but there is 
no such limit placed on what information about the active LSPs may be stored. 
Why not store the shoe size of the network operator's mother, if the 
implementation chooses to do so?

I suspect that all PCCs have always stored the current/desired states (plural) 
because that is how head end devices work. That is why there was never any 
mention of PCC LSP-DBs in the previous literature: they were implicit in "this 
is what you do when you build a router." The LSP-DB was only introduced for the 
stateful work because of the (new) desire to know what the PCC already knew and 
to synchronise PCC-PCE and PCE-PCE.

It seems to me that you are trying to describe how to implement a PCE and a 
PCC: something that may be a fun task, but which surely belongs outside the 
IETF.

[MK] There is nothing preventing an implementation from storing other 
information (desired state, shoe size, etc.) in a parallel-but-separate 
database indexed by the same key as the LSP-DB. That's all implementation 
details that we don't want to talk about in the draft, so we keep them out of 
our logical database. This allows us to make statements like "PCE LSP-DB is 
only modified by PCRpt messages" which sort of clarify where the data comes 
from. [/MK]

---

3.2

   Whenever a PCC modifies an entry in its PCC LSP-DB, it MUST send a
   PCRpt message to the PCE (or mult

Re: [Pce] I-D Action: draft-ietf-pce-multipath-04.txt

[Mike Koldychev (mkoldych)]

Hi WG,

Main change in 04 version was to move the R-flag (Reverse) from the OPPDIR TLV 
into the PATH-ATTRIB object..

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Friday, February 25, 2022 12:29 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-multipath-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP Extensions for Signaling Multipath Information
Authors : Mike Koldychev
  Siva Sivabalan
  Tarek Saad
  Vishnu Pavan Beeram
  Hooman Bidgoli
  Bhupendra Yadav
  Shuping Peng
  Gyan Mishra
Filename: draft-ietf-pce-multipath-04.txt
Pages   : 23
Date: 2022-02-25

Abstract:
   Path computation algorithms are not limited to return a single
   optimal path.  Multiple paths may exist that satisfy the given
   objectives and constraints.  This document defines a mechanism to
   encode multiple paths for a single set of objectives and constraints.
   This is a generic PCEP mechanism, not specific to any path setup type
   or dataplane.  The mechanism is applicable to both stateless and
   stateful PCEP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-multipath/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-multipath-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-multipath-04


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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

[Mike Koldychev (mkoldych)]

Support adoption. This document is necessary to implement flex-algo with PCE.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Friday, February 4, 2022 12:14 PM
To: pce@ietf.org
Cc: draft-tokar-pce-sid-a...@ietf.org
Subject: [Pce] WG Adoption of draft-tokar-pce-sid-algo-05

Hi WG,

This email begins the WG adoption poll for draft-tokar-pce-sid-algo-05.

https://datatracker.ietf.org/doc/draft-tokar-pce-sid-algo/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 21st Feb 2022.

Have a great weekend.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Additional questions for draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Boris,

1) Preference is actually optional in the SR Policy Architecture 
[https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/], 
it defaults to the value "100". So, we are just following the same data model. 
Even though in CLI, preference may be a key for a Candidate Path, in the data 
model it's actually a non-key value that can change.

2) Yes, in the current proposal there is the "State" field in the TLV, which 
encodes the PCC's state, i.e., if it's dropping traffic or not. We could use 
this field to signal other "forwarding states" as well.

3) Yes, the wording is not clear about how many LSPs (report/update/initiate) 
can be put into a PCEP message. It's perfectly valid to send multiple, but 
there's currently no reason to do it (except saving 4-bytes of PCEP message 
header). I will clarify the wording.

4) Hmmm yeah that's a great idea. Because currently if first label resolution 
fails at the PCC, then the LSP would just be down, but there would be no 
"invalidation reason" sent back to the PCE. We can indeed provide some 
indication, probably per-SL, about first-hop label resolution status. Perhaps 
the INVALIDATION TLV can be re-used in the PATH-ATTRIB object to encode per-SL 
invalidation reason (1-st SID unresolved)?

Thanks,
Mike.

From: Boris Khasanov 
Sent: Friday, November 12, 2021 10:36 AM
To: Mike Koldychev (mkoldych) 
Cc: pce@ietf.org
Subject: Additional questions for draft-ietf-pce-segment-routing-policy-cp


Hi Mike,

Few more questions which I did not mention on the mike (and repeat one which is 
absent in the Notes):

1)  I probably missed previous discussions (  I tried to search on 
mailarchive but no success) , pls remind -  what is the logic why 
SRPOLICY-CPATH-PREFERENCE TLV is optional? IMO it is quite important to define 
CPATH preference into same SR Policy.

2)  Could INVALIDATION TLV usage be extended also for PCC -> PCE (i.e. add 
this TLV to ASSOCIATION obj in PCRpt) case, to include some additional 
information to signal PCE what something goes wrong with LSP? What do you think?

3)  s.7.4 currently says: " PCE sends a separate PCInitiate message for 
every candidate path that it wants to create, or it sends multiple LSP objects 
within a single PCInitiate message. " IMO, it needs to be re-phrased (as I said 
verbally too) to some more  concrete like : "PCE SHOIULD send a separate 
PCInitiate message for every candidate path that it wants to create, or it MAY 
send multiple LSP objects within a single PCInitiate message." (or MAY for both 
cases if we want it to be relaxed)

4)  Can we extend section 8.3 PCEP Errors to include some more detailed 
Error types, for example, SL or CPATH instantiation failure (i.e. when 1st 
label in SL is invalid) etc.? Idea is to provide PCE more detailed info about 
forwarding plane issues.

Thank you.

SY,

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

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

[Mike Koldychev (mkoldych)]

Hi PCE experts,

In this update, we added some TLVs to signal standardized features of SR 
Policy, such as Drop-upon-invalid, Specified-BSID-only and others.

Although these features are standardized for SR Policy, we allow them to be 
applicable to all transport types, i.e., RSVP-TE as well.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: Friday, October 22, 2021 1:00 PM
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-policy-cp-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP extension to support Segment Routing Policy 
Candidate Paths
Authors : Mike Koldychev
  Siva Sivabalan
  Colby Barth
  Shuping Peng
  Hooman Bidgoli
Filename: draft-ietf-pce-segment-routing-policy-cp-06.txt
Pages   : 24
Date: 2021-10-22

Abstract:
   This document introduces a mechanism to specify a Segment Routing
   (SR) policy, as a collection of SR candidate paths.  An SR policy is
   identified by  tuple.  An SR policy can
   contain one or more candidate paths where each candidate path is
   identified in PCEP by its uniquely assigned PLSP-ID.  This document
   proposes extension to PCEP to support association among candidate
   paths of a given SR policy.  The mechanism proposed in this document
   is applicable to both MPLS and IPv6 data planes of SR.



The IETF datatracker status page for this 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-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-policy-cp-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
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] WG Adoption of draft-hsd-pce-sr-p2mp-policy-03

[Mike Koldychev (mkoldych)]

I support the WG adoption of this document. It provides a way to signal P2MP SR 
Policy.

Thanks,
Mike.

From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, October 18, 2021 8:33 AM
To: pce@ietf.org
Cc: draft-hsd-pce-sr-p2mp-pol...@ietf.org
Subject: [Pce] WG Adoption of draft-hsd-pce-sr-p2mp-policy-03

Hi WG,

This email begins the WG adoption poll for draft-hsd-pce-sr-p2mp-policy-03.
https://datatracker.ietf.org/doc/draft-hsd-pce-sr-p2mp-policy/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 8th Nov.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional

[Mike Koldychev (mkoldych)]

Hi PCE WG,

I support WG adoption of this document. It's a good improvement to the 
protocol. Would be good to clarify how it applies to objects that encode 
multiple constraints. For example, the LSPA object encodes affinity, plus other 
stuff like protection, priority and TLVs. Is it possible to ignore only some of 
those constraints? Perhaps by including multiple copies of the LSPA object?

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Tuesday, September 21, 2021 10:01 AM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-dhody-pce-stateful-pce-optional

Hi all,

This e-mail starts an adoption poll for
draft-dhody-pce-stateful-pce-optional-08 [1]. Do you consider this I-D is ready 
to become a PCE WG item?

Please respond to the PCE list, including rationale if you believe the WG 
should not adopt it.

Thanks,

Dhruv & Julien


[1]
https://datatracker.ietf.org/doc/html/draft-dhody-pce-stateful-pce-optional-08


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

Re: [Pce] Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Oscar,

See inline with [MK].

Thanks,
Mike.

From: Oscar González de Dios 
Sent: Friday, September 17, 2021 1:41 PM
To: Mike Koldychev (mkoldych) ; pce@ietf.org; 
draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: RE: Question about Originator Address in 
draft-ietf-pce-segment-routing-policy-cp

Thanks Mike,

Another question/comment.

The color & endpoint are encoded in the Extended Association ID 
TLV (defined in RFC 8697. The Extended Association ID TLV is an optional TLV 
for use in the ASSOCIATION object. The meaning and usage of the Extended 
Association ID TLV are as per Section 4 of [RFC6780] .

The content of the Extended Association TLV is defined here. 
Hence, the content of the TLV as expressed in the draft is only valid when the 
association type is 6 (segment routing). In other cases, the format would be 
completely different.

[MK] The format of the Extended Association ID TLV is specific to the 
Association Type and cannot be used outside of the Association Type that it's 
defined for.

Typically the content of all PCEP TLVs are well defined without 
requiring knowledge of the object in which they are carried. Some sort of type 
is used to determine the content.

Looking at Section 4 of [RFC6780], the "Extended Association 
ID: variable, 4-byte aligned
  This field contains data that is additional information to support
  unique identification.  The length and contents of this field is
  scoped by the Association Source.  ".

There, all association fields are together, so it makes sense. 
However, as in PCEP RFC 8697 "stripped off" the extended association ID to a 
TLV... well, we have the problem of having a TLV without any pre-defined format 
or any way of knowing its content without context...

[MK] It's kept generic on purpose - to allow encoding arbitrary keys. Each 
application can define its own key format.

Is there any particular reason for this behavior?  Does color & 
endpoint absolutely need to be part of the Extended Association TLV or could 
they have their own TLV?

[MK] In fact, the Color and Endpoint did have their own TLV, but it was decided 
to move them inside the Extended Association ID TLV. The reason is that every 
Association needs to have an Association ID value and it was difficult to pick 
that value for PCE Initiated SR Policies when two different PCEs send 
PCInitiate messages for two Candidate Paths of the same SR Policy (same 
Color+Endpoint) at the same time. Each PCE would need to choose what 
Association ID to send and if they just pick any random values, they would not 
agree. I.e., you would end up with two Associations on the PCC that have 
different Association IDs but same Color + Endpoint. On the other hand, if the 
two PCEs encode the Color + Endpoint as the ID, then this problem goes away, 
i.e., the two PCEs always agree on the ID. See also IETF 110 PCE WG recording.

Best Regards,

        Oscar

De: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Enviado el: viernes, 17 de septiembre de 2021 19:01
Para: Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>;
 pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Asunto: RE: Question about Originator Address in 
draft-ietf-pce-segment-routing-policy-cp

Hi Oscar,

Yes, I believe your understanding is correct.

Thanks,
Mike.

From: Oscar González de Dios 
mailto:oscar.gonzalezded...@telefonica.com>>
Sent: Friday, September 17, 2021 8:02 AM
To: pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: Question about Originator Address in 
draft-ietf-pce-segment-routing-policy-cp

Dear PCE WG & draft-ietf-pce-segment-routing-policy-cp authors,

I have one (easy) question about the SR Policy Candidate Path 
Identifiers TLV in section 5.2.2.
"Originator Address: Represented as 128 bit value where IPv4 address
   are encoded in lowest 32 bits, part of the originator identifier, as
   specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4."
In [I-D.ietf-spring-segment-routing-policy] Section 2.4. :
"Node Address : represented as a 128-bit value.  IPv4 addresses
  MUST be encoded in the lowest 32 bits, and the high-order bits
  MUST be set to zero."

 I guess an IPv4 Originator address would be encoded as follows: 
(apologies if the lines do not appear properly)

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-

Re: [Pce] Question about Originator Address in draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Oscar,

Yes, I believe your understanding is correct.

Thanks,
Mike.

From: Oscar González de Dios 
Sent: Friday, September 17, 2021 8:02 AM
To: pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Question about Originator Address in 
draft-ietf-pce-segment-routing-policy-cp

Dear PCE WG & draft-ietf-pce-segment-routing-policy-cp authors,

I have one (easy) question about the SR Policy Candidate Path 
Identifiers TLV in section 5.2.2.
"Originator Address: Represented as 128 bit value where IPv4 address
   are encoded in lowest 32 bits, part of the originator identifier, as
   specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4."
In [I-D.ietf-spring-segment-routing-policy] Section 2.4. :
"Node Address : represented as a 128-bit value.  IPv4 addresses
  MUST be encoded in the lowest 32 bits, and the high-order bits
  MUST be set to zero."

 I guess an IPv4 Originator address would be encoded as follows: 
(apologies if the lines do not appear properly)

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type  | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Proto. Origin |Reserved   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Originator ASN|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   all zeros   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   all zeros   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   all zeros   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Originator IPv4 Address|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Discriminator |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I ask it because in one interoperability test we are carrying out now, 
in one implementation the IPv4 address is encoded in the bits right after 
Originator ASN. Hence... I just want to be sure my understanding is correct to 
avoid a philosophical discussion :)

Best Regards,

Oscar


  

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede 
contener información privilegiada o confidencial y es para uso exclusivo de la 
persona o entidad de destino. Si no es usted. el destinatario indicado, queda 
notificado de que la lectura, utilización, divulgación y/o copia sin 
autorización puede estar prohibida en virtud de la legislación vigente. Si ha 
recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente 
por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential 
information intended only for the use of the individual or entity named above. 
If the reader of this message is not the intended recipient, you are hereby 
notified that any dissemination, distribution or copying of this communication 
is strictly prohibited. If you have received this transmission in error, do not 
read it. Please immediately reply to the sender that you have received this 
communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode 
conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa 
ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica 
notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização 
pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem 
por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e 
proceda a sua destruição
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Follow up about my question on the mic

[Mike Koldychev (mkoldych)]

Hi Aijun,

Thanks for clarifying Q1.

Regarding Q2, you can probably mention that in the draft. Multiple EPR objects 
MAY be sent for the same destination, which results in ECMP to that destination.

Thanks,
Mike.

From: Pce  On Behalf Of Aijun Wang
Sent: Monday, July 26, 2021 10:55 PM
To: 'Mike Koldychev (mkoldych)' ; 
draft-ietf-pce-pcep-extension-native...@ietf.org
Cc: pce@ietf.org
Subject: Re: [Pce] Follow up about my question on the mic

Hi, Mike:

Thanks for your questions. Please see the replies inline.
If you have more questions based on the followings answers, we can discuss them 
accordingly.

Best Regards

Aijun Wang
China Telecom

From: pce-boun...@ietf.org<mailto:pce-boun...@ietf.org> 
mailto:pce-boun...@ietf.org>> On Behalf Of Mike Koldychev 
(mkoldych)
Sent: Tuesday, July 27, 2021 6:36 AM
To: 
draft-ietf-pce-pcep-extension-native...@ietf.org<mailto:draft-ietf-pce-pcep-extension-native...@ietf.org>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Follow up about my question on the mic

Hi Authors,

Just following up about my 2 questions during the PCE WG session about 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-14.

Question 1: Is every prefix going to be advertised (via the RR) to every node 
in the native-ip domain, even if those nodes are never on-path for that prefix?
[WAJ] Yes, the behavior of RR is unchanged.
If my understanding is correct, the "BGP peer nodes" (R1 & R7 in Figure 4) 
would receive the PPA (Prefixes) and would inject these prefixes into the RR. 
The RR would then flood these prefixes (as regular BGP IP routes) to every 
single node in the domain (R2, R4, R5, R6) with the next-hop being set to R1 or 
R7. Please let me know if my understanding is correct or am I missing 
something. So even though R5 and R6 in this example are off-path, they would 
receive the prefix route from the RR?
[WAJ] Yes, R5 and R6 will also receive such prefix advertisements via the 
normal RR behavior. But on router R5&R6, the route to the BGP nexthop (R1&R7) 
is learned from the IGP protocol, not from the EPR(Explicit Peer Route) Object. 
Then after the recursive process, the forwarding path on R5&R6 will be along 
the normal non-optimal path.

Question 2: Have you thought about ECMP/UCMP (Equal/Unequal Cost Multipath)? 
How would you implement it in your protocol?
[WAJ] Currently, we consider only the ECMP application. If PCE wants to deploy 
multiple ECMP paths between two adjacent nodes, it can send two EPR Objects to 
the corresponding PCC, with the "Route Priority" field be set to the same value.

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

[Pce] Follow up about my question on the mic

[Mike Koldychev (mkoldych)]

Hi Authors,

Just following up about my 2 questions during the PCE WG session about 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-14.

Question 1: Is every prefix going to be advertised (via the RR) to every node 
in the native-ip domain, even if those nodes are never on-path for that prefix? 
If my understanding is correct, the "BGP peer nodes" (R1 & R7 in Figure 4) 
would receive the PPA (Prefixes) and would inject these prefixes into the RR. 
The RR would then flood these prefixes (as regular BGP IP routes) to every 
single node in the domain (R2, R4, R5, R6) with the next-hop being set to R1 or 
R7. Please let me know if my understanding is correct or am I missing 
something. So even though R5 and R6 in this example are off-path, they would 
receive the prefix route from the RR?

Question 2: Have you thought about ECMP/UCMP (Equal/Unequal Cost Multipath)? 
How would you implement it in your protocol?

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

Re: [Pce] Adoption of draft-litkowski-pce-state-sync

[Mike Koldychev (mkoldych)]

I believe this draft is very useful and support WG adoption.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: Monday, May 17, 2021 9:41 AM
To: pce@ietf.org
Subject: [Pce] Adoption of draft-litkowski-pce-state-sync

Dear all,

The document draft-litkowski-pce-state-sync has reached the head of our 
adoption queue 
(https://datatracker.ietf.org/doc/draft-litkowski-pce-state-sync/).

Do you consider this I-D is a good foundation for a WG item? Please share your 
feedback using the PCE mailing list by May 31.

Regards,

Dhruv & Julien


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

Re: [Pce] IPR Poll on draft-koldychev-pce-multipath-05

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.

Thanks,
Mike.

From: Hariharan Ananthakrishnan 
Sent: Monday, April 19, 2021 9:35 AM
To: Mike Koldychev (mkoldych) ; ssiva...@ciena.com; 
ts...@juniper.net; vbee...@juniper.net; hooman.bidg...@nokia.com; 
bya...@ciena.com; pengshup...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-koldychev-pce-multipath-05


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] WG Adoption of draft-koldychev-pce-multipath-05

[Mike Koldychev (mkoldych)]

Hi WG,

As a co-author, I support the adoption of this draft by PCE WG. The draft 
provides a generic way to represent multiple paths that taken together satisfy 
the given computation constraints/objectives.

Thanks,
Mike.

From: Dhruv Dhody 
Sent: Wednesday, April 14, 2021 10:52 AM
To: pce@ietf.org
Cc: draft-koldychev-pce-multip...@ietf.org
Subject: WG Adoption of draft-koldychev-pce-multipath-05

Hi WG,

This email begins the WG adoption poll for draft-koldychev-pce-multipath-05.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath-05

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Wednesday 28th April.

Thanks!
Dhruv & Julien
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Implementation option of draft-ietf-pce-stateful-interdomain-01.txt

[Mike Koldychev (mkoldych)]

Hi Olivier,

I would not recommend using the BSID TLV for #2 (Signal the presence of a 
Stitching Label in the path of a Tunnel/Policy). ERO/SR-ERO is the object that 
encodes the label-stack/path, and the SL is part of the label-stack/path of the 
previous Policy/Tunnel that uses it, so it belongs to the ERO/SR-ERO. BTW I 
don’t believe there is currently a way in PCEP to represent a BSID ERO 
sub-object, it would be useful to define it in some common way with the 
Stitching Label.

I agree about using flag(s) instead of allocating a new PST to represent the SL 
in the BSID TLV.

*IF* RSVP-TE RECORD_ROUTE is used, then RRO object is appropriate.

Thanks,
Mike.

From: olivier.dug...@orange.com 
Sent: Tuesday, March 23, 2021 2:11 PM
To: Mike Koldychev (mkoldych) ; Stone, Andrew (Nokia - 
CA/Ottawa) ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Implementation option of 
draft-ietf-pce-stateful-interdomain-01.txt


Hi Mike,
Le 22/03/2021 à 21:03, Mike Koldychev (mkoldych) a écrit :
Hi Olivier,

I believe what you are trying to achieve is:

  1.  Attach a Stitching Label to a Tunnel/Policy, similar to how a Binding 
Label points to a Tunnel/Policy.
[OD] Yes. Exactly


  1.
  2.  Signal the presence of a Stitching Label in the path of a Tunnel/Policy.
[OD] Yes by using PCE to PCE exchange through PCEP to convey this information


  1.

I believe that #1 can be achieved using the Binding Label TLV, by perhaps 
defining another Binding Type. And #2 can be achieved by adding another 
ERO/SR-ERO sub-object.
[OD] I think that both #1 & #2 could be achieved using the TE-PATH-BINDING TLV 
minus the addition of new flag to mention that the TE-PATH-BINDING TLV 
transport a Stitching Label. I would not define a new Binding Type as we could 
re-use which have been already define in the pce-binding-sid draft and we would 
not go back to the same problem as with the multiple PST code point. So, a 
dedicated flag to mention that it is a Binding Label for inter-domain would be 
better.


I do not think it’s a good idea to use the RRO unless there is an actual RSVP 
RECORD_ROUTE being used.

[OD] I tend to be agree after analysis all potential inconvenient, in 
particular in term of management. But, in another hand, the Stitching label is 
part of the Tunnel path reported by the Record Route Object.

Regards

Olivier

Thanks,
Mike.

From: Pce <mailto:pce-boun...@ietf.org> On Behalf Of 
Stone, Andrew (Nokia - CA/Ottawa)
Sent: Thursday, March 11, 2021 11:11 AM
To: olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>; Dhruv Dhody 
<mailto:dhruv.i...@gmail.com>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Implementation option of 
draft-ietf-pce-stateful-interdomain-01.txt

Hi Olivier,

Thanks for pointing this out. I think the presentation slide wording might have 
been a bit stronger than what is currently written in the posted draft, as the 
text does not prohibit the use of RRO but rather acknowledge and document that 
there are implementations which skip inclusion of SR-RRO (Nokia implementation 
does send SR-RRO), so it documents how to handle this scenario on the PCE. The 
text indicates that SR-RRO may or may not be included, and if omitted the PCE 
is to fallback to treating the ERO “like” it was an RRO.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-operational-03#section-6

   A PCC MUST send an (possibly empty) ERO/SR-ERO/SRv6-ERO in the PCRpt
   message for every LSP.  A PCC MAY send an SR-RRO/SRv6-RRO for an SR-
   TE/SRv6-TE LSP (respectively).  A PCE SHOULD interpret the RRO/SR-
   RRO/SRv6-RRO as the actual path the LSP is taking but MAY interpret
   only the ERO/SR-ERO/SRv6-ERO as the actual path.  In the absence of
   an RRO/SR-RRO/SRv6-RRO a PCE SHOULD interpret the ERO/SR-ERO/SRv6-ERO
   (respectively) as the actual path for the LSP.


I think the potential interdomain stitching label case you point out and the 
S-Flag defined in RFC8664 mentioned by Dhruv during the meeting seem to be 
valid use cases where an SR-RRO would need to be included.

Thanks!
Andrew

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
"olivier.dug...@orange.com<mailto:olivier.dug...@orange.com>" 
mailto:olivier.dug...@orange.com>>
Organization: Orange Labs
Date: Thursday, March 11, 2021 at 5:17 AM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>
Subject: Re: [Pce] Implementation option of 
draft-ietf-pce-stateful-interdomain-01.txt


Hello Dhruv, all,

Following the presentation done during the IETF meeting, please find the link 
to the presentation: 
https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-32-inter-domain-00

I also not a major point to take into account following the presentation of 
draft PCEP Operational Clarification (draft-koldychev-pce-operational) see 
https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/ a

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[Mike Koldychev (mkoldych)]

Hi,

I think that BSID is a concept that applies equally well to RSVP-TE and SR-TE. 
There are many use-cases for RSVP tunnels having a BSID and we definitely DO 
NOT want to limit it to just SR-TE.

Thanks,
Mike.

From: Pce  On Behalf Of Gyan Mishra
Sent: Sunday, March 28, 2021 7:53 PM
To: Siva Sivabalan 
Cc: pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; Stone, Andrew 
(Nokia - CA/Ottawa) 
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and 
Code Point Allocation)


Hi Siva

I believe  I was missing the signaling aspect for the PCE to build the 
contiguous end to end LSP and that requires BSID to be signaled over RSVP-TE 
which is although agnostic to data plane BSID component binding the candidate 
path to the forwarding plane, is a requirement for end to end control plane 
signaling for the single LSP end to end path instantiation.

The BSID signaling concept is somewhat analogous concept to LDP tunneling over 
RSVP-TE tunnel stitching for an end to end LSP instantiation.

Thank you Siva for the clarification.

Gyan

On Sun, Mar 28, 2021 at 7:33 PM Siva Sivabalan 
mailto:msiva...@gmail.com>> wrote:
Hi Gyan,

This ID is all about signaling BSID for RSVP-TE tunnels and SR policies via 
PCEP.

Please do not confuse signaling aspects with how BSID is used.

There is no change required in the ID.

Thanks,
Siva


On Sun, Mar 28, 2021 at 7:25 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:

All

After further review with Siva the use case is for connecting SR islands over 
RSVP-TE core.

So this is for stitching SR-TE on the edge islands binding SID to core RSVP-TE 
tunnel.

One major gap  of RSVP-TE is the VRF / VPN coloring capability that in order to 
achieve per VRF coloring mapping of VRF to a discrete TE tunnel requires a 
separate loopback and static routes to egress PE so it does not scale.  So for 
as many RSVP mapped tunnels that exist you need that many loopbacks and static 
routes for the next hop rewrite to the RSVP tunnel next hop.

So this Major gap is filled with SR VRF and app flow coloring capability that 
with SR-TE Policy BSID bound to candidate path can provide the scalability per 
VRF coloring.

So at the edges you may have many 100s of colored RSVP tunnels but as the core 
does not scale you can not provide a 1-1 mapping of SR-TE tunnel to RSVP 
tunnel.  So you would have many to 1 mappings of SR-TE tunnels to single or 
aggregate.

So in my mind to only way the BSID would come into play is if you could do a 
1-1 mapping of SR-TE tunnel to RSVP tunnel.  Technically that is not possible.

For PCE to compute end to end path in this scenario does RSVP-TE require the 
BSID for the stitching even if a many SR-TE colors to single RSVP-TE tunnel 
mapping. I would not think so.

If we think that for PCE to build the end to end path even for the end to end 
path in this scenario requires BSID binding to the RSVP-TE single path to make 
contiguous end to end then I agree technically we do need to make this 
inclusive of RSVP-TE.

I think we need to clear this up and if this use case is really not feasible 
then we should remove any mention of BSID use with RSVP-TE tunnel.

Kind Regards

Gyan

On Sat, Mar 27, 2021 at 3:05 PM Siva Sivabalan 
mailto:msiva...@gmail.com>> wrote:
Hi Gyan,

BSID can be allocated for RSVP-TE as well, and yes, there are use-cases for 
that. The proposed PCEP extension is equally applicable to both SR-TE and 
RSVP-TE.

Thanks,
Siva

On Sat, Mar 27, 2021 at 1:40 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


I support WG LC advancement of this draft for publication.

I see there are a lot of comments related to a mix of verbiage related to MPLS 
label binding and Binding label SID confusion.

Few comments.

The draft title states “carrying binding label/sid in PCE based networks”

In the abstract it states it is possible to associate a BSID with a RSVP 
signaled path.

I don’t recall any RSVP extension to support concept of BSID usage on an active 
Candidate Path option ERO.  Can you refer me to the RFC that states how BSID is 
used with RSVP TE.

For more clarity with this draft can we replace

s/TE/s/SR as TE nomenclature refers to RSVP-TE and does add confusion where SR 
is SR.  When mentioned traffic engineered path please spell out or say SR path 
for clarity.

Also the “TE-PATH-BINDING TLV” can we change to “SR-PATH-BINDING TLV”.

The word “binding” is very confusing as it’s used interchangeably with label 
binding and binding SID.

So I am thinking a more appropriate name for the TLV would be “SR-TE-BSID TLV”. 
 Makes it clear and concise the TLV is for SR-TE.

Kind Regards

Gyan

On Fri, Mar 26, 2021 at 9:45 PM Chengli (Cheng Li) 
mailto:c...@huawei.com>> wrote:
Thanks again for your help!

Cheng



-Original Message-
From: Stone, Andrew (Nokia - CA/Ottawa) 
[mailto:andrew.st...@nokia.com]
Sent: Saturday, March 27, 2021 2:42 AM
To: Chengli (Cheng Li) mailto:c...@huawei.com>>; 
j

Re: [Pce] Implementation option of draft-ietf-pce-stateful-interdomain-01.txt

[Mike Koldychev (mkoldych)]

Hi Olivier,

I believe what you are trying to achieve is:

  1.  Attach a Stitching Label to a Tunnel/Policy, similar to how a Binding 
Label points to a Tunnel/Policy.
  2.  Signal the presence of a Stitching Label in the path of a Tunnel/Policy.

I believe that #1 can be achieved using the Binding Label TLV, by perhaps 
defining another Binding Type. And #2 can be achieved by adding another 
ERO/SR-ERO sub-object.

I do not think it’s a good idea to use the RRO unless there is an actual RSVP 
RECORD_ROUTE being used.

Thanks,
Mike.

From: Pce  On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Thursday, March 11, 2021 11:11 AM
To: olivier.dug...@orange.com; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Implementation option of 
draft-ietf-pce-stateful-interdomain-01.txt

Hi Olivier,

Thanks for pointing this out. I think the presentation slide wording might have 
been a bit stronger than what is currently written in the posted draft, as the 
text does not prohibit the use of RRO but rather acknowledge and document that 
there are implementations which skip inclusion of SR-RRO (Nokia implementation 
does send SR-RRO), so it documents how to handle this scenario on the PCE. The 
text indicates that SR-RRO may or may not be included, and if omitted the PCE 
is to fallback to treating the ERO “like” it was an RRO.

https://datatracker.ietf.org/doc/html/draft-koldychev-pce-operational-03#section-6

   A PCC MUST send an (possibly empty) ERO/SR-ERO/SRv6-ERO in the PCRpt
   message for every LSP.  A PCC MAY send an SR-RRO/SRv6-RRO for an SR-
   TE/SRv6-TE LSP (respectively).  A PCE SHOULD interpret the RRO/SR-
   RRO/SRv6-RRO as the actual path the LSP is taking but MAY interpret
   only the ERO/SR-ERO/SRv6-ERO as the actual path.  In the absence of
   an RRO/SR-RRO/SRv6-RRO a PCE SHOULD interpret the ERO/SR-ERO/SRv6-ERO
   (respectively) as the actual path for the LSP.


I think the potential interdomain stitching label case you point out and the 
S-Flag defined in RFC8664 mentioned by Dhruv during the meeting seem to be 
valid use cases where an SR-RRO would need to be included.

Thanks!
Andrew

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
"olivier.dug...@orange.com" 
mailto:olivier.dug...@orange.com>>
Organization: Orange Labs
Date: Thursday, March 11, 2021 at 5:17 AM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: "pce@ietf.org" mailto:pce@ietf.org>>
Subject: Re: [Pce] Implementation option of 
draft-ietf-pce-stateful-interdomain-01.txt


Hello Dhruv, all,

Following the presentation done during the IETF meeting, please find the link 
to the presentation: 
https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-32-inter-domain-00

I also not a major point to take into account following the presentation of 
draft PCEP Operational Clarification (draft-koldychev-pce-operational) see 
https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/ and 
https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-34-operational-clarification-00:

 => In this draft, authors propose to use SR-ERO/SRv6-ERO and to NOT use 
SR-RRO/SR-v6-RRO for Segment Routing.

As a consequence for the stateful inter-domain draft, proposed option d1, d2 
and d3 become invalid as it uses the RRO to convey the Stiching Label. Thus, 
only option d4 with a specific new sub-Object to convey the Stitching Label 
remains valid.

As usual, comments are welcome.

Regards

Olivier
Le 26/02/2021 à 05:35, Dhruv Dhody a écrit :
Hi Olivier,

Thanks for starting this thread.

As a WG participant...

On Tue, Feb 23, 2021 at 12:05 AM 
mailto:olivier.dug...@orange.com>> wrote:
Dear all,

According to the remark about implementation we got during the WG call
for adoption, we would start a new thread to discuss this point.
The goal isto prepare the discussion for next IETF meeting and reach a
consensusin order to edit revision 2 of the draft.

The stitching label principle requires at least a certain number of
modifications in the current PCEP version:

 a) A new PCE Capability to announce the inter-domain behaviour
 b) A new PCE Association Group to associate the local paths identifier
to the inter-domain identifier
 c) new PCEP Errors to manage the Stitching Label exchange
 d) A mechanism to convey the Stitching Label

If there is no other choice than to reuse existing PCEP Objects by
allocating new code points for modifications a-c,there is several
options for point d, which we have tried to list below:

 d1) Use ERO and RRO in conjunction to new Path Setup code points as
 described in version 01 of the draft. It is the simplest
 implementation but as mention by Dhruv, each time a new path
 enforcement appear, a new PST code point must be allocated.
 For example, when Segment Routing v6 will be standardized, we must
 allocate a new Stitching label PST code point for SRv6.
 d2) Use ERO and ERO in conjunction to a new flag in LSP. Simple as 

Re: [Pce] IPR Poll on draft-ietf-pce-binding-label-sid-07

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Thanks,
Mike.

From: Pce  On Behalf Of Hariharan Ananthakrishnan
Sent: Thursday, March 18, 2021 1:10 PM
To: c...@huawei.com; Clarence Filsfils (cfilsfil) ; 
jefftant.i...@gmail.com; msiva...@gmail.com; stef...@previdi.net
Cc: pce@ietf.org
Subject: [Pce] IPR Poll on draft-ietf-pce-binding-label-sid-07


Hi Authors,



In preparation for WG Last Call on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.

Please respond (copying the mailing list) to say one of:

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] Early code point allocation for draft-ietf-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Tom,

Thanks a lot for your review, the -03 version should address your prior 
comments. Please log any new comments against the -03 version.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of tom petch
Sent: Saturday, February 20, 2021 7:33 AM
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp

From: Pce  on behalf of tom petch 
Sent: 19 February 2021 12:30
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Early code point allocation for 
draft-ietf-pce-segment-routing-policy-cp

From: julien.meu...@orange.com 
Sent: 18 February 2021 10:35

Hi Tom,

Thank you for your valuable feedback.



The more I look, the less I like it.

This I-D asks for an error code for missing mandatory TLV, a category which PCE 
has defined  as Error-Type 6 and is referenced  by such as pce-vn-association.

Why does this I-D put missing mandatory TLV in a different Error-Type?

I will raise some more issues next week.

Tom Petch


Some of the issues you point out are easy to address and we've already 
requested the authors to revise the I-D accordingly. To fully resolve your 
concern, could you please point any other specific parts where you feel you 
have to "interpret the words the way you think they should have been"? If you 
even have some text to suggest, that could smoothly ease the update.


At a first glance,

s.7.1
RFC8697 names three  columns for the registry; those names do not appear here.

The new association type is given a different identifier in different places.  
The preferred identifier needs to be nailed down since it is going into IANA 
forthwith and will be confusing to change thereafter.

s.7.2
This requests new error values  under Association Error  and specifies a Type 
of 29.  RFC8697 specifies a Type of 26 (29 is Path Computation Failure).

'Conflicting SRAG TLV' I find rather vague; conflicting with what?  Likewise 
'Multiple SRPAG from one LSP'

s.7.3
This document defines five new TLVs
That is TBD3, TBD4, TBD11, TBD5 and 

RFC8697 specifies the names of the fields in the registry,  Those names are not 
used here.

s.3.2
'as of the time of writing' will change its meaning as the I-D progresses; date 
needed

s.4.1
'is only meant to be used'
MUST NOT, SHOULD NOT, .?

'Policy Identifiers uniquely identify..
Policy Identifiers consist of Color.. Endpoint, optionally the policy hame.
So if one is Color red, Endpoint NY no policy name and then one is requested 
for Color red, Endpoint NY, policy name standby that is a different triplet and 
so valid.  Mmm. I can see that being mis-implemented

s.4.2

'is meant to strictly correspond'
MUST, SHOULD, ?

s.5
This document specifies four new TLVs...
These five TLVs .

These five TLVs encode the Policy Identifiers, SR Policy name, Candidate path 
identifiers, candidate path name and Candidate path preference..
That is five TLV. Wrong! That is four TLV and something completely different.


When any of the mandatory TLVs
Only one TLV is listed as mandatory SRPOLICY-CPATH-ID.

s.5
At most only one .. can be carried
and then goes on to describe the carriage of  more than one; 'Only one ... 
SHOULD be present in a ... (whatever identifier you fix on) message.  If more 
than one is present, only the first is processed and subsequent ones are 
silently discarded.

A Normative Reference to an unadopted I-D that expires next week is not a good 
look:-)

Like I said, the word that came to my mind was 'sloppy':-(

Tom Petch

Thanks,

Dhruv & Julien


On 17/02/2021 12:46, tom petch wrote:
> 
> 
> I am sure that IANA will cope because they always do, but it will be by 
> reading between the lines, applying intelligence to what the authors may have 
> meant, and so on.  Editorially this is a poor I-D (as yet), and that quality 
> verges on the technical aspects.
>
> Thus 7.3 says the I-D defines five new TLV and lists four; this also occurs 
> in the body of the I-D.  A reader might also notice the absence of TBD2 and 
> wonder.
>
> Or the new Association.  Thus needs an identifier.  Trouble is, the I-D uses 
> (at least) three different ones; this looseness of terminology can lead to 
> problems down the line.  (MPLS I see as a classic in how not to specify IANA 
> registries and I see this heading the same way).
>
> Likewise the identifiers used in s.7 do not match those in current use, a 
> good way of storing up future trouble.
>
> Is the specification adequate?  Only if you do not take it literally and 
> interpret the words the way you think they should have been.
>
> Tom Petch
>


___
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

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

Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

[Mike Koldychev (mkoldych)]

Hi Dhruv,

It is more clear now, thanks. The P=1 basically means to allocate from PCE 
controlled space, while P=0 means to allocate from PCC controlled space.

I would just suggest to make the last sentence more specific to reflect this:

Current:
"PCE would directly allocate the label
   from the PCE-controlled label space using P=1 as described above,
   whereas PCE would request for the allocation of a specific BSID with
   P=0 as described in Section 4."

Proposed:
"PCE would allocate the label
   from the PCE-controlled label space using P=1 as described above,
   whereas PCE would request for the allocation from the PCC-controlled label 
space
   using P=0 as described in Section 4."

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Tuesday, January 26, 2021 11:24 AM
To: Siva Sivabalan 
Cc: Mike Koldychev (mkoldych) ; pce@ietf.org; 
draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 
Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Siva,

I had a discussion with Mike, I explained that there are two different cases 
here:

(1) PCE requests a specific binding value to be allocated by PCC (section 4)
(2) PCE controls the label space and allocates the label directly (new section 
7, text moved from PCECC I-D)

For (1) there is no dependency on PCECC capability!
Only for (2), which is a PCECC operation, the PCECC capability is checked.
The P flag helps to easily distinguish between the two cases.

Again, this is not a new feature, this was already part of a post-WG-LC I-D, we 
are moving the text to BSID I-D here when the issue was discovered during the 
RTGDIR review.

I added some more clarifications based on your and Mike's suggestions.
Here is the latest working copy -
https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

If there is any text that is not clear or a change you would like to see, 
please let me know.

Thanks!
Dhruv (as a WG member)

On Tue, Jan 26, 2021 at 8:28 PM Siva Sivabalan  wrote:
>
> Hi Dhruv,
>
> I also agree with Mike. Let's not make BSID ID dependent on PCECC capability.
>
> Thanks,
> Siva
>
> On Mon, Jan 25, 2021 at 11:58 AM Mike Koldychev (mkoldych) 
>  wrote:
>>
>> Hi Dhruv,
>>
>> My concern is about a PCC that DOES support PCE assigned BSID, but that DOES 
>> NOT support PCECC. Your latest diff still says that PCECC capability is 
>> needed for this PCC to be able to make use of PCE assigned BSID.
>>
>> IMHO it should not be necessary to bring in support for PCECC, which is 
>> quite a large extension, just to allow a PCE to send down a BSID label to 
>> the PCC. PCE may have some other mechanism to figure out whether a BSID 
>> label is allocated or not.
>>
>> Thanks,
>> Mike.
>>
>> -Original Message-
>> From: Dhruv Dhody 
>> Sent: Monday, January 25, 2021 11:38 AM
>> To: Mike Koldychev (mkoldych) 
>> Cc: Siva Sivabalan ; pce@ietf.org; 
>> draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 
>> 
>> Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the 
>> BSID draft
>>
>> Hi Siva, Mike,
>>
>> I have made an update to add more clarity in section 7.
>>
>> Commit: 
>> https://github.com/dhruvdhody/ietf/commit/5c7e4625e8491fdece9007bec07
>> 6a654bbeeaf93
>> Diff:  
>> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce
>> -binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdho
>> dy/ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>>
>> Just to clarify, this is not a new requirement, all that is being done is 
>> moving the text from the PCECC I-D (which was already in post-WGLC) to the 
>> BSID I-D. It is also marked that this feature is optional and used only in 
>> the case the implementation also supports PCECC operations and no change is 
>> made to any existing operations that could lead to any backward 
>> compatibility issues.
>>
>> Thanks!
>> Dhruv (as a WG member)
>>
>>
>> On Mon, Jan 25, 2021 at 8:43 PM Mike Koldychev (mkoldych) 
>>  wrote:
>> >
>> > I’m also concerned about having PCECC as a requirement for anything in 
>> > that draft. It would break backward compatibility.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > Mike.
>> >
>> >
>> >
>> > From: Pce  On Behalf Of Siva Sivabalan
>> > Sent: Sunday, January 24, 2021 7:13 PM
>> > To: Dhruv Dhody 
>> > Cc: pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org;
>> > pce-chairs 
>> > Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SI

Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

[Mike Koldychev (mkoldych)]

Hi Dhruv,

My concern is about a PCC that DOES support PCE assigned BSID, but that DOES 
NOT support PCECC. Your latest diff still says that PCECC capability is needed 
for this PCC to be able to make use of PCE assigned BSID.

IMHO it should not be necessary to bring in support for PCECC, which is quite a 
large extension, just to allow a PCE to send down a BSID label to the PCC. PCE 
may have some other mechanism to figure out whether a BSID label is allocated 
or not.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Monday, January 25, 2021 11:38 AM
To: Mike Koldychev (mkoldych) 
Cc: Siva Sivabalan ; pce@ietf.org; 
draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 
Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Siva, Mike,

I have made an update to add more clarity in section 7.

Commit: 
https://github.com/dhruvdhody/ietf/commit/5c7e4625e8491fdece9007bec076a654bbeeaf93
Diff:  
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

Just to clarify, this is not a new requirement, all that is being done is 
moving the text from the PCECC I-D (which was already in post-WGLC) to the BSID 
I-D. It is also marked that this feature is optional and used only in the case 
the implementation also supports PCECC operations and no change is made to any 
existing operations that could lead to any backward compatibility issues.

Thanks!
Dhruv (as a WG member)


On Mon, Jan 25, 2021 at 8:43 PM Mike Koldychev (mkoldych)  
wrote:
>
> I’m also concerned about having PCECC as a requirement for anything in that 
> draft. It would break backward compatibility.
>
>
>
> Thanks,
>
> Mike.
>
>
>
> From: Pce  On Behalf Of Siva Sivabalan
> Sent: Sunday, January 24, 2021 7:13 PM
> To: Dhruv Dhody 
> Cc: pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; 
> pce-chairs 
> Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the 
> BSID draft
>
>
>
> Hi Dhruv and all:
>
>
>
> Section 7 states:
>
> Section 4 includes a case where a specified value for the binding  label/SID 
> is requested to be allocated by the PCC.
>
>
>
> Section 4 (of v5) states:
>
> If a PCE requires a PCC to allocate a specific binding value, it may 
> do so by sending a PCUpd or PCInitiate message containing a TE-PATH-
>
> BINDING TLV.
>
>
>
> Could we please add a bit more clarity to the motivation for the proposed 
> change ?
>
>
>
> Also, we may want to indicate that how a PCE figures out the available labels 
> on a PCC, etc, is outside the scope of this ID.
>
>
>
> Thanks,
>
> Siva
>
>
>
>
>
> On Wed, Jan 20, 2021 at 8:41 AM Dhruv Dhody  wrote:
>
> Hi WG, Authors,
>
> As part of the handling of RTGDIR comments [1] for the PCECC I-D [2], 
> it was discovered that it is a better idea to handle the Binding SID 
> allocation by the PCE in the BSID I-D [3]. Julien and I agree.
>
> Also, it makes sense to move the new P-flag in the LSP object here 
> (from path segment WG I-D [4]).
>
> Cheng and I have this proposed update -
>
> Diff: 
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-
> binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody
> /ietf/master/draft-ietf-pce-binding-label-sid-06.txt
>
> Please let us know if anyone has any concerns with this approach. This 
> draft is in our WG LC Queue [5].
>
> Thanks!
> Dhruv/Cheng
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu
> _hE/ [2] 
> https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce
> -controller/ [3] 
> https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
> [4] https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/
> [5] https://trac.ietf.org/trac/pce/wiki/WikiStart#WGLastCallQueue
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

[Mike Koldychev (mkoldych)]

I’m also concerned about having PCECC as a requirement for anything in that 
draft. It would break backward compatibility.

Thanks,
Mike.

From: Pce  On Behalf Of Siva Sivabalan
Sent: Sunday, January 24, 2021 7:13 PM
To: Dhruv Dhody 
Cc: pce@ietf.org; draft-ietf-pce-binding-label-...@ietf.org; pce-chairs 

Subject: Re: [Pce] Moving PCE Allocation of Binding Label/SID to the BSID draft

Hi Dhruv and all:

Section 7 states:
Section 4 includes a case where a specified value for the binding  label/SID is 
requested to be allocated by the PCC.

Section 4 (of v5) states:

If a PCE requires a PCC to allocate a specific binding value, it may do so by 
sending a PCUpd or PCInitiate message containing a TE-PATH-

BINDING TLV.



Could we please add a bit more clarity to the motivation for the proposed 
change ?



Also, we may want to indicate that how a PCE figures out the available labels 
on a PCC, etc, is outside the scope of this ID.



Thanks,

Siva



On Wed, Jan 20, 2021 at 8:41 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG, Authors,

As part of the handling of RTGDIR comments [1] for the PCECC I-D [2],
it was discovered that it is a better idea to handle the Binding SID
allocation by the PCE in the BSID I-D [3]. Julien and I agree.

Also, it makes sense to move the new P-flag in the LSP object here
(from path segment WG I-D [4]).

Cheng and I have this proposed update -

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-binding-label-sid-05&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-binding-label-sid-06.txt

Please let us know if anyone has any concerns with this approach. This
draft is in our WG LC Queue [5].

Thanks!
Dhruv/Cheng

[1] https://mailarchive.ietf.org/arch/msg/rtg-dir/4n6FpBoDHjnGppKH4bcVotUu_hE/
[2] 
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-controller/
[3] https://datatracker.ietf.org/doc/draft-ietf-pce-binding-label-sid/
[4] https://datatracker.ietf.org/doc/draft-ietf-pce-sr-path-segment/
[5] https://trac.ietf.org/trac/pce/wiki/WikiStart#WGLastCallQueue
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi WG,

Our latest version of the draft 
(https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-02#section-4.2)
 addresses the issue that was pointed out in this thread. We are able to avoid 
the race condition by setting Association Ext ID = , so that 
all the PCEs are able to agree on the same Association ID/ExtID without having 
to communicate between each other.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Monday, November 23, 2020 11:59 PM
To: Mike Koldychev (mkoldych) 
Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
; pce-chairs ; 
pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
; Stone, Andrew (Nokia - CA/Ottawa) 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Mon, Nov 23, 2020 at 9:04 PM Mike Koldychev (mkoldych)  
wrote:
>
> Hi PCE-CHAIRS,
>
> Would like to understand how does RFC 8697 work in the following scenario:
>
> t=1: PCE_A creates LSP_1 in Association_A (using Source=PCE_A)
> t=2: PCE_B creates LSP_2 and joins Association_A
> t=3: PCE_A deletes LSP_1
>
> Now, PCE_B owns an Association that has the source address of PCE_A. 
> Meanwhile, PCE_A may disconnect from the given PCC and may not be aware that 
> PCE_B is using PCE_A as the Source. So PCE_A can now reuse the same 
> Association ID somewhere else?
>

The stateful PCE model works with the assumption that the LSP state from the 
network is synchronized to all PCEs in the domain. BTW in the case of a 
temporary disconnect, synchronization between PCE is the proposed solution. 
Basically, PCE_A needs to be aware of the continued use of association at the 
PCC/PCE_B in your example.

Also, when RFC 8697 suggested using virtual IP as a source in case of PCE 
redundancy, it was with this understanding that the state is synchronized and 
one PCE would be aware of association created by another, using the virtual IP 
as association source (this principle can be applied to PCE_A as source as 
well). Also, in your case above it would be a good implementation principle for 
PCE_A to not reuse the same association ID immediately if it can help it :)

Anyways as a last resort, there is also a possibility for PCE_B to remove the 
old association and recreate a new association in an extreme case. Though I 
would not recommend you do that!

=

RFC 8697 provides a mechanism that is generic and includes the association with 
LSPs with different headends. PCC based allocation would not work in that case. 
Isn't it likely that implementations would support other association types as 
well, and likely implement the generic handling. To me reusing the generic 
techniques where we can makes sense (that was the very reason for the WG 
producing RFC 8697).

=

Thanks!
Dhruv (as a WG member)


> Thanks,
> Mike.
>
> -Original Message-
> From: Mike Koldychev (mkoldych)
> Sent: Friday, November 6, 2020 2:39 PM
> To: Dhruv Dhody 
> Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
> ; pce-chairs 
> ; pce@ietf.org; 
> draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
> ; Stone, Andrew (Nokia - CA/Ottawa) 
> 
> Subject: RE: [Pce] Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Dhruv,
>
> Thanks again for bringing up this topic. Let's think some more about the 
> possible solutions and also let other people provide feedback. Perhaps a 
> side-meeting can be held as well.
>
> Have a good weekend,
> Mike.
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Friday, November 6, 2020 10:50 AM
> To: Mike Koldychev (mkoldych) 
> Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
> ; pce-chairs 
> ; pce@ietf.org; 
> draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
> ; Stone, Andrew (Nokia - CA/Ottawa) 
> 
> Subject: Re: [Pce] Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Fri, Nov 6, 2020 at 7:39 PM Mike Koldychev (mkoldych)  
> wrote:
> >
> > Hi Dhruv,
> >
> > -Original Message-
> > From: Dhruv Dhody 
> > Sent: Friday, November 6, 2020 8:27 AM
> > To: Mike Koldychev (mkoldych) 
> > Cc: Dhruv Dhody ; pce-chairs 
> > ; pce@ietf.org; 
> > draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
> > ; Stone, Andrew (Nokia - CA/Ottawa) 
> > 
> > Subject: Re: [Pce] Association Source in
> > draft-ietf-pce-segment-routing-policy-cp-01
> >
> > Hi Mike,
> >
> > On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) 
> >  wrote:
> > >
> > > Hi Dhruv,
> > >
> > > I don't think it's valid to dismiss race conditions in the protocol 
> > > because they are "rare". If they can happen 

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi PCE-CHAIRS,

Would like to understand how does RFC 8697 work in the following scenario:

t=1: PCE_A creates LSP_1 in Association_A (using Source=PCE_A)
t=2: PCE_B creates LSP_2 and joins Association_A
t=3: PCE_A deletes LSP_1

Now, PCE_B owns an Association that has the source address of PCE_A. Meanwhile, 
PCE_A may disconnect from the given PCC and may not be aware that PCE_B is 
using PCE_A as the Source. So PCE_A can now reuse the same Association ID 
somewhere else?

Thanks,
Mike.

-Original Message-
From: Mike Koldychev (mkoldych) 
Sent: Friday, November 6, 2020 2:39 PM
To: Dhruv Dhody 
Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
; pce-chairs ; 
pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
; Stone, Andrew (Nokia - CA/Ottawa) 

Subject: RE: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Dhruv,

Thanks again for bringing up this topic. Let's think some more about the 
possible solutions and also let other people provide feedback. Perhaps a 
side-meeting can be held as well.

Have a good weekend,
Mike.

-Original Message-
From: Dhruv Dhody 
Sent: Friday, November 6, 2020 10:50 AM
To: Mike Koldychev (mkoldych) 
Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
; pce-chairs ; 
pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
; Stone, Andrew (Nokia - CA/Ottawa) 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Fri, Nov 6, 2020 at 7:39 PM Mike Koldychev (mkoldych)  
wrote:
>
> Hi Dhruv,
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Friday, November 6, 2020 8:27 AM
> To: Mike Koldychev (mkoldych) 
> Cc: Dhruv Dhody ; pce-chairs ; 
> pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril 
> Margaria ; Stone, Andrew (Nokia - CA/Ottawa) 
> 
> Subject: Re: [Pce] Association Source in
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) 
>  wrote:
> >
> > Hi Dhruv,
> >
> > I don't think it's valid to dismiss race conditions in the protocol because 
> > they are "rare". If they can happen at all means that implementations need 
> > to have extra logic to handle these race conditions.
> >
>
> Doesn't this "extra" logic exist anyway, as you must make sure there is only 
> one SR policy association with a given set of SR Policy parameters under 
> normal operations.
>
> [MK] If the PCC allocates the Association Source/ID, then it's always going 
> to choose a unique value, so there will never be any collision. So no, this 
> "extra" logic won't exist if we go with my proposal.
>

+1 to what Cyril said. The idea that even when PCE knows about the
existing association created at the PCC and it wants a new CP to join that 
association, it cannot do so and it must use association-id as zero is weird - 
there is a reason we maintain associations at the PCE.
So my reading was that the use of 0 was only when the SR Policy association was 
not known.
Also, you don't mention the PCUpd message in your draft, first an existing 
SR-TE path (RFC 8664) can join the SR Policy association using the PCUpd 
message. Also, you may want to update the existing CP and carry the already 
known association in the PCUpd message. I assume you would want to put "a 
non-zero PCC allocated ID''!

>
> > What is rare today in your deployment, may not be rare tomorrow in another 
> > deployment. I can think of a case where a PCC connects simultaneously to 
> > many PCEs which create many thousands of SR CPs on it. If they all send 
> > PCInit messages before the head-end replies to them with PCRpt, then you 
> > will have this "rare" race condition repeated thousands of times. Each PCE 
> > will choose different Source/ID in PCInit and PCC will have to send PCError 
> > back to them.
> >
>
> You make a good point here! What you describe is "possible"!
>
> [MK] I would say "very likely" that you would get a flood of PCError messages 
> in that scenario under scale.
>
>
> > Furthermore, you need logic on the PCC to choose the right Association out 
> > of many.
>
> The logic is the first association created for a given SR policy at the PCC 
> and that's it!
>
> > There are also undesirable security/privacy implications of putting PCE/NMS 
> > IP address into the Source. It means that if two PCEs are controlling 
> > different CPs of the same policy, then one of the PCEs can learn the IP 
> > address of the other by reading the Association Source of the PCRpt 
> > messages from the PCC. This is especially bad, because this Association 

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

Thanks again for bringing up this topic. Let's think some more about the 
possible solutions and also let other people provide feedback. Perhaps a 
side-meeting can be held as well.

Have a good weekend,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Friday, November 6, 2020 10:50 AM
To: Mike Koldychev (mkoldych) 
Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
; pce-chairs ; 
pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
; Stone, Andrew (Nokia - CA/Ottawa) 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Fri, Nov 6, 2020 at 7:39 PM Mike Koldychev (mkoldych)  
wrote:
>
> Hi Dhruv,
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Friday, November 6, 2020 8:27 AM
> To: Mike Koldychev (mkoldych) 
> Cc: Dhruv Dhody ; pce-chairs ; 
> pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril 
> Margaria ; Stone, Andrew (Nokia - CA/Ottawa) 
> 
> Subject: Re: [Pce] Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) 
>  wrote:
> >
> > Hi Dhruv,
> >
> > I don't think it's valid to dismiss race conditions in the protocol because 
> > they are "rare". If they can happen at all means that implementations need 
> > to have extra logic to handle these race conditions.
> >
>
> Doesn't this "extra" logic exist anyway, as you must make sure there is only 
> one SR policy association with a given set of SR Policy parameters under 
> normal operations.
>
> [MK] If the PCC allocates the Association Source/ID, then it's always going 
> to choose a unique value, so there will never be any collision. So no, this 
> "extra" logic won't exist if we go with my proposal.
>

+1 to what Cyril said. The idea that even when PCE knows about the
existing association created at the PCC and it wants a new CP to join that 
association, it cannot do so and it must use association-id as zero is weird - 
there is a reason we maintain associations at the PCE.
So my reading was that the use of 0 was only when the SR Policy association was 
not known.
Also, you don't mention the PCUpd message in your draft, first an existing 
SR-TE path (RFC 8664) can join the SR Policy association using the PCUpd 
message. Also, you may want to update the existing CP and carry the already 
known association in the PCUpd message. I assume you would want to put "a 
non-zero PCC allocated ID''!

>
> > What is rare today in your deployment, may not be rare tomorrow in another 
> > deployment. I can think of a case where a PCC connects simultaneously to 
> > many PCEs which create many thousands of SR CPs on it. If they all send 
> > PCInit messages before the head-end replies to them with PCRpt, then you 
> > will have this "rare" race condition repeated thousands of times. Each PCE 
> > will choose different Source/ID in PCInit and PCC will have to send PCError 
> > back to them.
> >
>
> You make a good point here! What you describe is "possible"!
>
> [MK] I would say "very likely" that you would get a flood of PCError messages 
> in that scenario under scale.
>
>
> > Furthermore, you need logic on the PCC to choose the right Association out 
> > of many.
>
> The logic is the first association created for a given SR policy at the PCC 
> and that's it!
>
> > There are also undesirable security/privacy implications of putting PCE/NMS 
> > IP address into the Source. It means that if two PCEs are controlling 
> > different CPs of the same policy, then one of the PCEs can learn the IP 
> > address of the other by reading the Association Source of the PCRpt 
> > messages from the PCC. This is especially bad, because this Association 
> > Source has no semantic meaning in SR Policy and may be hidden in normal 
> > show commands. Furthermore, this IP address of the PCE/NMS that created the 
> > policy will be associated to the Policy even after PCE disconnects from the 
> > PCC, as long as any CP remains in that Policy.
> >
>
> If any of this is really an issue, we got to update RFC 8697! I am not 
> advocating for that BTW :) Privacy of one PCE from another in an SR domain  
> (under same administrative control) is quite a stretch IMHO.
>
> [MK] The two PCEs may not be under one administrative control. Network A may 
> delegate some tunnels/policies to Network B PCE (for routing through Network 
> B, for example).

Delegation outside of your network domain would open you up to so much more 
security concern than just knowing another PCE add

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Cyril,

Yes I propose the PCE always send PCInint with 0/0.0.0.0/0::0 (for SR Policy). 
PCC would then allocate its own Source/ID and send that in PCRpt. That PCC 
allocated Source/ID would be used to track the Association, not the 
0/0.0.0.0/0::0.

Associations in general are useful because they allow to refer to a grouping of 
PLSPs.

Thanks,
Mike.

From: Cyril Margaria 
Sent: Friday, November 6, 2020 9:21 AM
To: Mike Koldychev (mkoldych) 
Cc: Dhruv Dhody ; Mike Koldychev (mkoldych) 
; Dhruv Dhody ; pce-chairs 
; pce@ietf.org; 
draft-ietf-pce-segment-routing-policy...@ietf.org; Stone, Andrew (Nokia - 
CA/Ottawa) 
Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike

On Fri, 6 Nov 2020 at 14:09, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Dhruv,

-Original Message-
From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: Friday, November 6, 2020 8:27 AM
To: Mike Koldychev (mkoldych) 
mailto:40cisco@dmarc.ietf.org>>
Cc: Dhruv Dhody mailto:d...@dhruvdhody.com>>; pce-chairs 
mailto:pce-cha...@ietf.org>>; 
pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>;
 Cyril Margaria mailto:cyril.marga...@gmail.com>>; 
Stone, Andrew (Nokia - CA/Ottawa) 
mailto:andrew.st...@nokia.com>>
Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) 
mailto:40cisco@dmarc.ietf.org>> wrote:
>
> Hi Dhruv,
>
> I don't think it's valid to dismiss race conditions in the protocol because 
> they are "rare". If they can happen at all means that implementations need to 
> have extra logic to handle these race conditions.
>

Doesn't this "extra" logic exist anyway, as you must make sure there is only 
one SR policy association with a given set of SR Policy parameters under normal 
operations.

[MK] If the PCC allocates the Association Source/ID, then it's always going to 
choose a unique value, so there will never be any collision. So no, this 
"extra" logic won't exist if we go with my proposal.

[MC] that's assuming that the PCE always sends 0, and not the previously 
returned value, at that point why bother using or tracking association ?




BTW, what are your thoughts on the operator-configured association in the 
previous email? Not viable?

[MK] You could set AssocExtID=Color, but I’m not sure what you would set Source 
to? Can we just set it to 0.0.0.0/0::0<http://0.0.0.0/0::0> and be done? Isn't 
that also a "special value"?

AssocExtID=Color, endpoint

Source should be a valid IP address, 0.0.0.0 looks OK, but I am rusty on that.
0 is reserved, 0x is all assocation, 1 works as a fixed number not in a 
reserved range.


> All of this can be avoided if we just allow Source/ID to be 0 in PCInit 
> messages. Is that really such a big change?
>

No, but the WG worked on RFC 8697 to make sure all the associations can be 
handled in a common way as much as possible. When deviating from that, IMHO a 
higher bar should be met. The WG should ponder if it is met here based on the 
scenario described above, that's all.

[MK] I fully understand, but the value of 0 is reserved in that RFC. Can each 
application use 0/0.0.0.0/0::0<http://0.0.0.0/0::0> for its own purpose? Is 
that allowed/forbidden in the RFC?

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

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

-Original Message-
From: Dhruv Dhody  
Sent: Friday, November 6, 2020 8:27 AM
To: Mike Koldychev (mkoldych) 
Cc: Dhruv Dhody ; pce-chairs ; 
pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; Cyril Margaria 
; Stone, Andrew (Nokia - CA/Ottawa) 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Fri, Nov 6, 2020 at 5:08 PM Mike Koldychev (mkoldych) 
 wrote:
>
> Hi Dhruv,
>
> I don't think it's valid to dismiss race conditions in the protocol because 
> they are "rare". If they can happen at all means that implementations need to 
> have extra logic to handle these race conditions.
>

Doesn't this "extra" logic exist anyway, as you must make sure there is only 
one SR policy association with a given set of SR Policy parameters under normal 
operations.

[MK] If the PCC allocates the Association Source/ID, then it's always going to 
choose a unique value, so there will never be any collision. So no, this 
"extra" logic won't exist if we go with my proposal.


> What is rare today in your deployment, may not be rare tomorrow in another 
> deployment. I can think of a case where a PCC connects simultaneously to many 
> PCEs which create many thousands of SR CPs on it. If they all send PCInit 
> messages before the head-end replies to them with PCRpt, then you will have 
> this "rare" race condition repeated thousands of times. Each PCE will choose 
> different Source/ID in PCInit and PCC will have to send PCError back to them.
>

You make a good point here! What you describe is "possible"!

[MK] I would say "very likely" that you would get a flood of PCError messages 
in that scenario under scale.


> Furthermore, you need logic on the PCC to choose the right Association out of 
> many.

The logic is the first association created for a given SR policy at the PCC and 
that's it!

> There are also undesirable security/privacy implications of putting PCE/NMS 
> IP address into the Source. It means that if two PCEs are controlling 
> different CPs of the same policy, then one of the PCEs can learn the IP 
> address of the other by reading the Association Source of the PCRpt messages 
> from the PCC. This is especially bad, because this Association Source has no 
> semantic meaning in SR Policy and may be hidden in normal show commands. 
> Furthermore, this IP address of the PCE/NMS that created the policy will be 
> associated to the Policy even after PCE disconnects from the PCC, as long as 
> any CP remains in that Policy.
>

If any of this is really an issue, we got to update RFC 8697! I am not 
advocating for that BTW :) Privacy of one PCE from another in an SR domain  
(under same administrative control) is quite a stretch IMHO.

[MK] The two PCEs may not be under one administrative control. Network A may 
delegate some tunnels/policies to Network B PCE (for routing through Network B, 
for example). In this case, the internal NMS/PCE addresses of Network A would 
be leaked. An operator who is not intimate with the PCEP messaging internals 
might never even realize this leak is happening. I believe we should update RFC 
8697, we need to at least state that a privacy violation is possible and that 
the operator needs to assume that internal NMS/PCE addresses are going to be 
leaked to other PCEs via the ASSOCIATION object.


BTW, what are your thoughts on the operator-configured association in the 
previous email? Not viable?

[MK] You could set AssocExtID=Color, but I’m not sure what you would set Source 
to? Can we just set it to 0.0.0.0/0::0 and be done? Isn't that also a "special 
value"?


> All of this can be avoided if we just allow Source/ID to be 0 in PCInit 
> messages. Is that really such a big change?
>

No, but the WG worked on RFC 8697 to make sure all the associations can be 
handled in a common way as much as possible. When deviating from that, IMHO a 
higher bar should be met. The WG should ponder if it is met here based on the 
scenario described above, that's all.

[MK] I fully understand, but the value of 0 is reserved in that RFC. Can each 
application use 0/0.0.0.0/0::0 for its own purpose? Is that allowed/forbidden 
in the RFC?


Thanks!
Dhruv

PS. Process comment - If the WG decides this is needed (and I am in rough), the 
procedure needs to be generic and outside the SR policy draft in a separate 
I-D, so that other associations can also use it.

> Thanks,
> Mike.
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Friday, November 6, 2020 5:15 AM
> To: Mike Koldychev (mkoldych) 
> Cc: Stone, Andrew (Nokia - CA/Ottawa) ; Cyril 
> Margaria ; pce@ietf.org; 
> draft-ietf-pce-segment-routing-policy...@ietf.org; pce-chairs 
> 
> Subject: Re: [Pce] Association Source in 

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

I don't think it's valid to dismiss race conditions in the protocol because 
they are "rare". If they can happen at all means that implementations need to 
have extra logic to handle these race conditions. 

What is rare today in your deployment, may not be rare tomorrow in another 
deployment. I can think of a case where a PCC connects simultaneously to many 
PCEs which create many thousands of SR CPs on it. If they all send PCInit 
messages before the head-end replies to them with PCRpt, then you will have 
this "rare" race condition repeated thousands of times. Each PCE will choose 
different Source/ID in PCInit and PCC will have to send PCError back to them. 
Furthermore, you need logic on the PCC to choose the right Association out of 
many.

There are also undesirable security/privacy implications of putting PCE/NMS IP 
address into the Source. It means that if two PCEs are controlling different 
CPs of the same policy, then one of the PCEs can learn the IP address of the 
other by reading the Association Source of the PCRpt messages from the PCC. 
This is especially bad, because this Association Source has no semantic meaning 
in SR Policy and may be hidden in normal show commands. Furthermore, this IP 
address of the PCE/NMS that created the policy will be associated to the Policy 
even after PCE disconnects from the PCC, as long as any CP remains in that 
Policy.

All of this can be avoided if we just allow Source/ID to be 0 in PCInit 
messages. Is that really such a big change?

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Friday, November 6, 2020 5:15 AM
To: Mike Koldychev (mkoldych) 
Cc: Stone, Andrew (Nokia - CA/Ottawa) ; Cyril Margaria 
; pce@ietf.org; 
draft-ietf-pce-segment-routing-policy...@ietf.org; pce-chairs 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike, Andrew, Cyril,

Thanks for a great discussion, more inline...

On Fri, Nov 6, 2020 at 7:23 AM Mike Koldychev (mkoldych)  
wrote:
>
> Hi Andrew,
>
> See inline with [MK]
>
> Hi Mike, Dhruv, Cyril:
>
> We do use errors on initiate messages during race conditions, for example, 
> symbolic name uniqueness on pce-initiated vanilla LSPs. So error based 
> protection to enforce uniqueness and protect race conditions is 
> manageable/done today.
>
> [MK] The chances of symbolic-names being the same is much less than the 
> chance of Association Sources being different. Also the symbolic-name 
> actually has an important meaning, the Association Source has no meaning. 
> Getting a flood of PCError messages about a field that has no meaning would 
> be bad. If we can eliminate these error messages completely, why not do that?
>
>

[DD] First, the flood of errors is a stretch by any means :) And I agree with 
Andrew about the 'initiate' case.

>
> However: would it make sense for the SRPAG definition, to be defined by the 
> ‘first’ entity which created the candidate path? when it’s a shared construct 
> with other entities which are now forced to re-use that value? Using a 
> Virtual IP on the PCE(s) would certainly help, but wouldn’t work correctly 
> with mixed use PCC/PCE init candidate paths (would anyone do that?), or 
> different vendor PCE/clusters/different virtual IPs would add more 
> complexity.  The common element I see is the uniqueness on PCC and the fact 
> that SRPAG==SRPolicy. Since Association Source is ‘scoping for the 
> association ID’, and there is no association scoping used/needed, then the 
> value is essentially unused – therefore just a dummy value assigned by PCC?
>
> [MK] Yes it’s unused! I like the idea of PCC choosing it.
>

[DD] For a dynamic association, the default is for the local PCEP speaker to be 
the association source unless local policy says otherwise.

Anyways, based on the requirement that you had in the earlier email -

Mike> 1. all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND 
Mike> 2. they agree without talking to each other.

One can make the SRPolicy association to be considered as an 
operator-configured association (i.e. association parameters configured by the 
operator beforehand on the PCEP peers).

Hear me out, we anyway have the SR Policy configuration happening at all peers, 
could we say that the PCEP association parameters
(type/id/source..) need also be set by the operator. If you are worried that it 
would be extra configuration, there could be rules set by the operator for 
filling the association parameters using SRPolicy such as Assoc-type=SR-Policy, 
Assoc-ID/Extended Association ID=Color, Assoc-source=headend/special value.

Note that allowing SRPolicy to be both dynamic and operator-configured is also 
a possiblity.

>
>
> I think there is a bit of ambiguity as mentioned (PCEP session? Router ID? ), 
> and still run the ri

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Andrew,

See inline with [MK]

From: Stone, Andrew (Nokia - CA/Ottawa) 
Sent: Thursday, November 5, 2020 3:48 PM
To: Mike Koldychev (mkoldych) ; Cyril Margaria 
; Dhruv Dhody 
Cc: pce@ietf.org; draft-ietf-pce-segment-routing-policy...@ietf.org; pce-chairs 

Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike, Dhruv, Cyril:

We do use errors on initiate messages during race conditions, for example, 
symbolic name uniqueness on pce-initiated vanilla LSPs. So error based 
protection to enforce uniqueness and protect race conditions is manageable/done 
today.
[MK] The chances of symbolic-names being the same is much less than the chance 
of Association Sources being different. Also the symbolic-name actually has an 
important meaning, the Association Source has no meaning. Getting a flood of 
PCError messages about a field that has no meaning would be bad. If we can 
eliminate these error messages completely, why not do that?

However: would it make sense for the SRPAG definition, to be defined by the 
‘first’ entity which created the candidate path? when it’s a shared construct 
with other entities which are now forced to re-use that value? Using a Virtual 
IP on the PCE(s) would certainly help, but wouldn’t work correctly with mixed 
use PCC/PCE init candidate paths (would anyone do that?), or different vendor 
PCE/clusters/different virtual IPs would add more complexity.  The common 
element I see is the uniqueness on PCC and the fact that SRPAG==SRPolicy. Since 
Association Source is ‘scoping for the association ID’, and there is no 
association scoping used/needed, then the value is essentially unused – 
therefore just a dummy value assigned by PCC?
[MK] Yes it’s unused! I like the idea of PCC choosing it.

I think there is a bit of ambiguity as mentioned (PCEP session? Router ID? ), 
and still run the risk that PCEP is terminating on different addresses towards 
different PCEs / different view of the ‘PCC address’.  Requesting the PCC to 
just assign the (unused?) value seems to like a way to avoid all of the above.  
With that said, I could be missing other implications/usage of the Association 
Source field.
[MK] Yes, requesting the PCC to assign a value would resolve this issue. But 
the question is what value would the PCE send in PCInit message when first 
creating a policy? I propose that PCE can send just 0.0.0.0 or 0::0 in PCInit 
messages to indicate to the PCC to pick a value. Alternatively, PCE can send 
any value of Association Source/ID, but the PCC will not honor it and just 
choose its own Association Source/ID.

Cheers
Andrew

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
"Mike Koldychev (mkoldych)" 
mailto:mkoldych=40cisco@dmarc.ietf.org>>
Date: Thursday, November 5, 2020 at 1:30 PM
To: Cyril Margaria mailto:cyril.marga...@gmail.com>>, 
Dhruv Dhody mailto:d...@dhruvdhody.com>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>"
 
mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>>,
 pce-chairs mailto:pce-cha...@ietf.org>>
Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01

Hi Cyril,

See inline with [MK]

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Thursday, November 5, 2020 11:35 AM
To: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Cc: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>; 
pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mailto:pce-cha...@ietf.org>>; 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01


I have a related question: how do you define the "PCC address", PCEP session 
address , one router id?
[MK] By PCC Address, I meant the IP address of the PCEP session. I believe a 
better approach is actually to set Association Source in PCInitiate message to 
0.0.0.0 or 0::0 and let the PCC allocate the correct Source, same as how 
Association ID allocation is proposed in the draft.


For the association source race condition, the race condition will result in a 
"Conflicting SRPAG TLV" from a PCInitiate/PCUpd, the PCE can use the correct 
SRPAG.
[MK] It’s not a good protocol design to allow PCError messages to appear 
randomly when all the parties are following the protocol. Would really like to 
avoid that.



On Thu, 5 Nov 2020 at 16:16, Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Mike,

On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)
mailto:mkold...@cisco.com>> wrote:
>
> Hi Dhruv,
>
>
>
> Perhaps we can avoid this by letting PCE send PCInitiate message with 
> Association Source set to some reserved

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Cyril,

See inline with [MK]

From: Cyril Margaria 
Sent: Thursday, November 5, 2020 11:35 AM
To: Dhruv Dhody 
Cc: Mike Koldychev (mkoldych) ; pce@ietf.org; pce-chairs 
; draft-ietf-pce-segment-routing-policy...@ietf.org
Subject: Re: [Pce] Association Source in 
draft-ietf-pce-segment-routing-policy-cp-01


I have a related question: how do you define the "PCC address", PCEP session 
address , one router id?
[MK] By PCC Address, I meant the IP address of the PCEP session. I believe a 
better approach is actually to set Association Source in PCInitiate message to 
0.0.0.0 or 0::0 and let the PCC allocate the correct Source, same as how 
Association ID allocation is proposed in the draft.


For the association source race condition, the race condition will result in a 
"Conflicting SRPAG TLV" from a PCInitiate/PCUpd, the PCE can use the correct 
SRPAG.
[MK] It’s not a good protocol design to allow PCError messages to appear 
randomly when all the parties are following the protocol. Would really like to 
avoid that.



On Thu, 5 Nov 2020 at 16:16, Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Mike,

On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)
mailto:mkold...@cisco.com>> wrote:
>
> Hi Dhruv,
>
>
>
> Perhaps we can avoid this by letting PCE send PCInitiate message with 
> Association Source set to some reserved value, like 0. This can mean that the 
> PCE is basically requesting the PCC to allocate an Association Source and to 
> “own” that Association. We already do this with the Association ID. PCE sets 
> the ID to 0 in PCInitiate and PCC chooses an Association ID and reports it 
> back.
>
>

The comment was applicable for association-id as well as
association-source! The use of 0 as association ID is being introduced
by your draft and not part of the base RFC 8697 and that triggered the
original email. Julien and I were uncomfortable with that and wanted
to understand what is new here for SR policy association that requires
a new procedure and cant be handled by RFC 8697.

Thanks,
Dhruv

>
> Thanks,
>
> Mike.
>
>
>
> From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
> Sent: Thursday, November 5, 2020 10:43 AM
> To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
> Cc: 
> draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>;
>  pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
> mailto:pce-cha...@ietf.org>>
> Subject: Re: Association Source in draft-ietf-pce-segment-routing-policy-cp-01
>
>
>
> Hi Mike,
>
>
>
> On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) 
> mailto:mkold...@cisco.com>> wrote:
>
> Hi Dhruv,
>
>
>
> Thanks for bringing this up.
>
>
>
> By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:
>
> all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND
> they agree without talking to each other.
>
>
>
> In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that 
> condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd 
> messages between the 3 entities, which violates condition 2. Please correct 
> me if I misunderstood something. In the picture that you drew, you say that 
> “Policy Endpoint=X” and “Association Source=X”, are you suggesting to use the 
> policy endpoint as the ASSO_SOURCE? That would satisfy both conditions, but 
> I’m not sure if you intended that?
>
>
>
>
>
> No, I did not!
>
>
>
>
>
> I believe condition 2 is important to satisfy, because otherwise there could 
> be race conditions where the 3 parties have different ASSOC_SOURCE for the 
> same policy. Consider what happens when all 3 parties try to create the same 
> policy at the same time.
>
>
>
>
>
> The SR-Policy association is "dynamic" in nature, and we need to go by the 
> association parameters we receive from the PCEP peer. Condition 2 of talking 
> to each other is the very nature of a dynamic association!
>
>
>
> If the race condition is the issue to solve, we can use the SR-Policy 
> parameters (color, endpoint, source). And make sure there is only one 
> SR-Policy-association-group with a given set of SR-Policy parameters (and 
> generate an error otherwise). The other PCE would learn about the association 
> and can use it subsequently!
>
>
>
> I’m open to any proposal, but IMO we should respect the above two 
> requirements.
>
>
>
>
>
> I feel the requirement 2 is not compatible with a dynamic association.
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
> Thanks,
>
> Mike.
>
>
>
> From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
> Sent: Thursday, November 

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

The scenario is when the same SR Policy is created on the PCC and the PCE at 
the same time (or from multiple PCEs at the same time). If we follow RFC 8697 
procedures, it can result in each entity generating its own Association ID and 
Source.

It's not a good protocol design to use Error messages to resolve timing/race 
conditions. IMO it's not acceptable that PCError messages can appear at random, 
even when every party is complying to the protocol.

So I propose to enhance the RFC 8697 procedures to allow a PCEP speaker to 
request Association ID/Source to be allocated from the remote peer, by sending 
a 0 value, which is reserved today.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Thursday, November 5, 2020 11:35 AM
To: Mike Koldychev (mkoldych) 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs 

Subject: Re: Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

And if you want to do that, please explain the scenario that requires the new 
procedure (and explain why not use RFC 8697 mechanisms itself). That was the 
original ask in the first email.

Thanks!
Dhruv
PS. IMHO the race condition scenario can be solved by RFC 8697 and the SR 
Policy parameter check.

On Thu, Nov 5, 2020 at 9:55 PM Mike Koldychev (mkoldych)  
wrote:
>
> Hi Dhruv,
>
> Yes, I think we should standardize this mechanism - allowing PCE to request 
> PCC to allocate Association ID and Source.
>
> Thanks,
> Mike.
>
> -Original Message-
> From: Dhruv Dhody 
> Sent: Thursday, November 5, 2020 11:16 AM
> To: Mike Koldychev (mkoldych) 
> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; 
> pce-chairs 
> Subject: Re: Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
> Hi Mike,
>
> On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)  
> wrote:
> >
> > Hi Dhruv,
> >
> >
> >
> > Perhaps we can avoid this by letting PCE send PCInitiate message with 
> > Association Source set to some reserved value, like 0. This can mean that 
> > the PCE is basically requesting the PCC to allocate an Association Source 
> > and to “own” that Association. We already do this with the Association ID. 
> > PCE sets the ID to 0 in PCInitiate and PCC chooses an Association ID and 
> > reports it back.
> >
> >
>
> The comment was applicable for association-id as well as association-source! 
> The use of 0 as association ID is being introduced by your draft and not part 
> of the base RFC 8697 and that triggered the original email. Julien and I were 
> uncomfortable with that and wanted to understand what is new here for SR 
> policy association that requires a new procedure and cant be handled by RFC 
> 8697.
>
> Thanks,
> Dhruv
>
> >
> > Thanks,
> >
> > Mike.
> >
> >
> >
> > From: Dhruv Dhody 
> > Sent: Thursday, November 5, 2020 10:43 AM
> > To: Mike Koldychev (mkoldych) 
> > Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; 
> > pce-chairs 
> > Subject: Re: Association Source in
> > draft-ietf-pce-segment-routing-policy-cp-01
> >
> >
> >
> > Hi Mike,
> >
> >
> >
> > On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) 
> >  wrote:
> >
> > Hi Dhruv,
> >
> >
> >
> > Thanks for bringing this up.
> >
> >
> >
> > By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:
> >
> > all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND they 
> > agree without talking to each other.
> >
> >
> >
> > In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that 
> > condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd 
> > messages between the 3 entities, which violates condition 2. Please correct 
> > me if I misunderstood something. In the picture that you drew, you say that 
> > “Policy Endpoint=X” and “Association Source=X”, are you suggesting to use 
> > the policy endpoint as the ASSO_SOURCE? That would satisfy both conditions, 
> > but I’m not sure if you intended that?
> >
> >
> >
> >
> >
> > No, I did not!
> >
> >
> >
> >
> >
> > I believe condition 2 is important to satisfy, because otherwise there 
> > could be race conditions where the 3 parties have different ASSOC_SOURCE 
> > for the same policy. Consider what happens when all 3 parties try to create 
> > the same policy at the same time.
> >
> >
> >
> >
> >
> > The SR-Policy association is "dynamic" in nature, and we

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

Yes, I think we should standardize this mechanism - allowing PCE to request PCC 
to allocate Association ID and Source.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Thursday, November 5, 2020 11:16 AM
To: Mike Koldychev (mkoldych) 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs 

Subject: Re: Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Thu, Nov 5, 2020 at 9:34 PM Mike Koldychev (mkoldych)  
wrote:
>
> Hi Dhruv,
>
>
>
> Perhaps we can avoid this by letting PCE send PCInitiate message with 
> Association Source set to some reserved value, like 0. This can mean that the 
> PCE is basically requesting the PCC to allocate an Association Source and to 
> “own” that Association. We already do this with the Association ID. PCE sets 
> the ID to 0 in PCInitiate and PCC chooses an Association ID and reports it 
> back.
>
>

The comment was applicable for association-id as well as association-source! 
The use of 0 as association ID is being introduced by your draft and not part 
of the base RFC 8697 and that triggered the original email. Julien and I were 
uncomfortable with that and wanted to understand what is new here for SR policy 
association that requires a new procedure and cant be handled by RFC 8697.

Thanks,
Dhruv

>
> Thanks,
>
> Mike.
>
>
>
> From: Dhruv Dhody 
> Sent: Thursday, November 5, 2020 10:43 AM
> To: Mike Koldychev (mkoldych) 
> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; 
> pce-chairs 
> Subject: Re: Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
>
>
> Hi Mike,
>
>
>
> On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych)  
> wrote:
>
> Hi Dhruv,
>
>
>
> Thanks for bringing this up.
>
>
>
> By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:
>
> all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND they 
> agree without talking to each other.
>
>
>
> In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that 
> condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd 
> messages between the 3 entities, which violates condition 2. Please correct 
> me if I misunderstood something. In the picture that you drew, you say that 
> “Policy Endpoint=X” and “Association Source=X”, are you suggesting to use the 
> policy endpoint as the ASSO_SOURCE? That would satisfy both conditions, but 
> I’m not sure if you intended that?
>
>
>
>
>
> No, I did not!
>
>
>
>
>
> I believe condition 2 is important to satisfy, because otherwise there could 
> be race conditions where the 3 parties have different ASSOC_SOURCE for the 
> same policy. Consider what happens when all 3 parties try to create the same 
> policy at the same time.
>
>
>
>
>
> The SR-Policy association is "dynamic" in nature, and we need to go by the 
> association parameters we receive from the PCEP peer. Condition 2 of talking 
> to each other is the very nature of a dynamic association!
>
>
>
> If the race condition is the issue to solve, we can use the SR-Policy 
> parameters (color, endpoint, source). And make sure there is only one 
> SR-Policy-association-group with a given set of SR-Policy parameters (and 
> generate an error otherwise). The other PCE would learn about the association 
> and can use it subsequently!
>
>
>
> I’m open to any proposal, but IMO we should respect the above two 
> requirements.
>
>
>
>
>
> I feel the requirement 2 is not compatible with a dynamic association.
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
> Thanks,
>
> Mike.
>
>
>
> From: Dhruv Dhody 
> Sent: Thursday, November 5, 2020 1:59 AM
> To: draft-ietf-pce-segment-routing-policy...@ietf.org
> Cc: pce@ietf.org; pce-chairs 
> Subject: Association Source in 
> draft-ietf-pce-segment-routing-policy-cp-01
>
>
>
> Hi Authors,
>
> In 
> https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-0
> 1#section-4.2,  you state -
>
>The Association Source MUST be set to the PCC's address.  This
>applies for both PCC-initiated and PCE-initiated candidate paths.
>The reasoning for this is that if different PCEs could set their own
>Association Source, then the candidate paths instantiated by
>different PCEs would by definition be in different PCEP Associations,
>which contradicts our requirement that the SR Policy is represented
>by an Association.
>
>
>
>
>The Association ID MUST be chosen by the PCC when the SR policy is
>allocated.  In PCRpt messages from the PCC, the Association ID MUST

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

Perhaps we can avoid this by letting PCE send PCInitiate message with 
Association Source set to some reserved value, like 0. This can mean that the 
PCE is basically requesting the PCC to allocate an Association Source and to 
“own” that Association. We already do this with the Association ID. PCE sets 
the ID to 0 in PCInitiate and PCC chooses an Association ID and reports it back.

Thanks,
Mike.

From: Dhruv Dhody 
Sent: Thursday, November 5, 2020 10:43 AM
To: Mike Koldychev (mkoldych) 
Cc: draft-ietf-pce-segment-routing-policy...@ietf.org; pce@ietf.org; pce-chairs 

Subject: Re: Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Mike,

On Thu, Nov 5, 2020 at 7:51 PM Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Dhruv,

Thanks for bringing this up.

By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:

  1.  all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND
  2.  they agree without talking to each other.

In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that 
condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd messages 
between the 3 entities, which violates condition 2. Please correct me if I 
misunderstood something. In the picture that you drew, you say that “Policy 
Endpoint=X” and “Association Source=X”, are you suggesting to use the policy 
endpoint as the ASSO_SOURCE? That would satisfy both conditions, but I’m not 
sure if you intended that?


No, I did not!


I believe condition 2 is important to satisfy, because otherwise there could be 
race conditions where the 3 parties have different ASSOC_SOURCE for the same 
policy. Consider what happens when all 3 parties try to create the same policy 
at the same time.


The SR-Policy association is "dynamic" in nature, and we need to go by the 
association parameters we receive from the PCEP peer. Condition 2 of talking to 
each other is the very nature of a dynamic association!

If the race condition is the issue to solve, we can use the SR-Policy 
parameters (color, endpoint, source). And make sure there is only one 
SR-Policy-association-group with a given set of SR-Policy parameters (and 
generate an error otherwise). The other PCE would learn about the association 
and can use it subsequently!

I’m open to any proposal, but IMO we should respect the above two requirements.


I feel the requirement 2 is not compatible with a dynamic association.

Thanks!
Dhruv


Thanks,
Mike.

From: Dhruv Dhody mailto:d...@dhruvdhody.com>>
Sent: Thursday, November 5, 2020 1:59 AM
To: 
draft-ietf-pce-segment-routing-policy...@ietf.org<mailto:draft-ietf-pce-segment-routing-policy...@ietf.org>
Cc: pce@ietf.org<mailto:pce@ietf.org>; pce-chairs 
mailto:pce-cha...@ietf.org>>
Subject: Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Authors,

In 
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01#section-4.2,
  you state -
   The Association Source MUST be set to the PCC's address.  This
   applies for both PCC-initiated and PCE-initiated candidate paths.
   The reasoning for this is that if different PCEs could set their own
   Association Source, then the candidate paths instantiated by
   different PCEs would by definition be in different PCEP Associations,
   which contradicts our requirement that the SR Policy is represented
   by an Association.


   The Association ID MUST be chosen by the PCC when the SR policy is
   allocated.  In PCRpt messages from the PCC, the Association ID MUST
   be set to the unique value that was allocated by the PCC at the time
   of policy creation.  In PCInit messages from the PCE, the Association
   ID MUST be set to the reserved value 0, which indicates that the PCE
   is asking the PCC to choose an ID value.  The PCE MUST NOT send the
   Extended Association ID TLV in the PCInit messages.

But the base RFC 8697 https://www.rfc-editor.org/rfc/rfc8697.html#section-6.1.3 
gave quite a bit of leeway while setting the association source.

Consider 2 PCEs - PCE1 & PCE2, I am assuming if candidate paths are created via 
two different PCEs both will be aware of SR Policy identifiers (color, 
end-point, etc). When PCE1 initiates CP1, it could use the association source 
as Virtual-IP or NMS (instead of PCE1). The PCE2 will learn about the 
association and the corresponding SR policy parameters via the PCRpt message 
which is sent to both PCEs. So when the PCE2 initiates CP2, it could use the 
same association!

This was the very reason to include the flexibility in setting the association 
source in RFC 8697.

Julien and I discussed this and we feel you are trying to solve the issue of 
sharing an association ID between several PCEs by using a new mean than the one 
in RFC 8697. If you have other reasons then please state them, otherwise, RFC 
8697 should take precedence.

Thanks!
Dhruv & Julien

PS. I quickly drew a figure if that h

Re: [Pce] Association Source in draft-ietf-pce-segment-routing-policy-cp-01

[Mike Koldychev (mkoldych)]

Hi Dhruv,

Thanks for bringing this up.

By setting ASSO_SOURCE = PCC_ADDRESS, we guarantee that:

  1.  all 3 parties: PCC, PCE1 and PCE2 agree on the same source, AND
  2.  they agree without talking to each other.

In your proposal below, if we set ASSO_SOURCE = NMS_ADDRESS, it seems that 
condition 1 may be fulfilled, but it requires exchange of PCRupt/PCUpd messages 
between the 3 entities, which violates condition 2. Please correct me if I 
misunderstood something. In the picture that you drew, you say that “Policy 
Endpoint=X” and “Association Source=X”, are you suggesting to use the policy 
endpoint as the ASSO_SOURCE? That would satisfy both conditions, but I’m not 
sure if you intended that?

I believe condition 2 is important to satisfy, because otherwise there could be 
race conditions where the 3 parties have different ASSOC_SOURCE for the same 
policy. Consider what happens when all 3 parties try to create the same policy 
at the same time.

I’m open to any proposal, but IMO we should respect the above two requirements.

Thanks,
Mike.

From: Dhruv Dhody 
Sent: Thursday, November 5, 2020 1:59 AM
To: draft-ietf-pce-segment-routing-policy...@ietf.org
Cc: pce@ietf.org; pce-chairs 
Subject: Association Source in draft-ietf-pce-segment-routing-policy-cp-01

Hi Authors,

In 
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01#section-4.2,
  you state -
   The Association Source MUST be set to the PCC's address.  This
   applies for both PCC-initiated and PCE-initiated candidate paths.
   The reasoning for this is that if different PCEs could set their own
   Association Source, then the candidate paths instantiated by
   different PCEs would by definition be in different PCEP Associations,
   which contradicts our requirement that the SR Policy is represented
   by an Association.


   The Association ID MUST be chosen by the PCC when the SR policy is
   allocated.  In PCRpt messages from the PCC, the Association ID MUST
   be set to the unique value that was allocated by the PCC at the time
   of policy creation.  In PCInit messages from the PCE, the Association
   ID MUST be set to the reserved value 0, which indicates that the PCE
   is asking the PCC to choose an ID value.  The PCE MUST NOT send the
   Extended Association ID TLV in the PCInit messages.

But the base RFC 8697 https://www.rfc-editor.org/rfc/rfc8697.html#section-6.1.3 
gave quite a bit of leeway while setting the association source.

Consider 2 PCEs - PCE1 & PCE2, I am assuming if candidate paths are created via 
two different PCEs both will be aware of SR Policy identifiers (color, 
end-point, etc). When PCE1 initiates CP1, it could use the association source 
as Virtual-IP or NMS (instead of PCE1). The PCE2 will learn about the 
association and the corresponding SR policy parameters via the PCRpt message 
which is sent to both PCEs. So when the PCE2 initiates CP2, it could use the 
same association!

This was the very reason to include the flexibility in setting the association 
source in RFC 8697.

Julien and I discussed this and we feel you are trying to solve the issue of 
sharing an association ID between several PCEs by using a new mean than the one 
in RFC 8697. If you have other reasons then please state them, otherwise, RFC 
8697 should take precedence.

Thanks!
Dhruv & Julien

PS. I quickly drew a figure if that helps (see attached)!

On Tue, Oct 27, 2020 at 8:42 PM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

Title   : PCEP extension to support Segment Routing Policy 
Candidate Paths
Authors : Mike Koldychev
  Siva Sivabalan
  Colby Barth
  Shuping Peng
  Hooman Bidgoli
Filename: draft-ietf-pce-segment-routing-policy-cp-01.txt
Pages   : 20
Date: 2020-10-27

Abstract:
   This document introduces a mechanism to specify a Segment Routing
   (SR) policy, as a collection of SR candidate paths.  An SR policy is
   identified by  tuple.  An SR policy can
   contain one or more candidate paths where each candidate path is
   identified in PCEP via an PLSP-ID.  This document proposes extension
   to PCEP to support association among candidate paths of a given SR
   policy.  The mechanism proposed in this document is applicable to
   both MPLS and IPv6 data planes of SR.



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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-policy-cp-01
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=dr

Re: [Pce] WG adoption poll for draft-stone-pce-local-protection-enforcement-02.

[Mike Koldychev (mkoldych)]

Hi,

I have read the latest version of this document and I support WG adoption. It's 
useful for finer control of TI-LFA protection for SR-TE Policy.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, October 21, 2020 9:41 AM
To: pce@ietf.org
Subject: [Pce] WG adoption poll for 
draft-stone-pce-local-protection-enforcement-02.

Hi WG,

This email begins the WG adoption poll for 
draft-stone-pce-local-protection-enforcement-02.

https://datatracker.ietf.org/doc/html/draft-stone-pce-local-protection-enforcement-02

Should this draft be adopted by the PCE WG? Please state your reasons
- Why / Why not? What needs to be fixed before or after adoption? Are you 
willing to work on this draft? Review comments should be posted to the list.

This adoption poll will end on 9th Nov 2020 (Monday).

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] WGLC for draft-ietf-pce-association-bidir

[Mike Koldychev (mkoldych)]

Hi,

I have read the latest version of this document. I support the publication of 
this document.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: Monday, October 5, 2020 1:17 PM
To: pce@ietf.org
Cc: draft-ietf-pce-association-bi...@ietf.org; pce-chairs 
Subject: [Pce] WGLC for draft-ietf-pce-association-bidir

Hi WG,

This email starts a working group last call for 
draft-ietf-pce-association-bidir [1].  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. A general reminder to the 
WG to be more vocal during the LC and adoption calls.

The WG LC will end on 20th October 2020.

Thanks,
Dhruv & Julien
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-bidir/

___
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-association-policy

[Mike Koldychev (mkoldych)]

I support this document.

It provides a useful mechanism to apply policies either on the PCC or on the 
PCE.

Comment: it should be clarified whether PCUpd message can be used instead of 
the PCInit message when updating the PAG that is "enforced by the PCC". I 
believe PCUpd can be used, but the draft should make that explicit, for example 
in Figure 1.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: Friday, September 4, 2020 1:13 AM
To: pce@ietf.org
Cc: draft-ietf-pce-association-pol...@ietf.org; pce-chairs 
Subject: [Pce] WGLC for draft-ietf-pce-association-policy

Hi WG,

This email starts a working group last call for 
draft-ietf-pce-association-policy [1].  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 21st September 2020.

Thanks,
Dhruv & Julien
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/

___
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] New Version Notification for draft-koldychev-pce-multipath-02.txt

[Mike Koldychev (mkoldych)]

Hi PCE,

We added another example, error handling and clarifications.

Thanks,
Mike.

-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, June 23, 2020 11:40 AM
To: Vishnu Pavan Beeram ; Tarek Saad ; 
Bhupendra Yadav ; Vishnu Beeram ; Mike 
Koldychev (mkoldych) ; Siva Sivabalan ; 
Hooman Bidgoli 
Subject: New Version Notification for draft-koldychev-pce-multipath-02.txt


A new version of I-D, draft-koldychev-pce-multipath-02.txt
has been successfully submitted by Mike Koldychev and posted to the IETF 
repository.

Name:   draft-koldychev-pce-multipath
Revision:   02
Title:  PCEP Extensions for Signaling Multipath Information
Document date:  2020-06-23
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/internet-drafts/draft-koldychev-pce-multipath-02.txt
Status: https://datatracker.ietf.org/doc/draft-koldychev-pce-multipath/
Htmlized:   https://tools.ietf.org/html/draft-koldychev-pce-multipath-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-koldychev-pce-multipath
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-koldychev-pce-multipath-02

Abstract:
   Current PCEP standards allow only one intended and/or actual path to
   be present in a PCEP report or update.  Applications that require
   multipath support such as SR Policy require an extension to allow
   signaling multiple intended and/or actual paths within a single PCEP
   message.  This document introduces such an extension.  Encoding of
   multiple intended and/or actual paths is done by encoding multiple
   Explicit Route Objects (EROs) and/or multiple Record Route Objects
   (RROs).  A special separator object is defined in this document, to
   facilitate this.  This mechanism is applicable to SR-TE and RSVP-TE
   and is dataplane agnostic.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Pce] WG adoption poll for draft-barth-pce-segment-routing-policy-cp-06

[Mike Koldychev (mkoldych)]

Hi PCE Chairs,

As one of the authors, I support WG adoption of the current draft.

Hi Andrew,

Thanks for your valuable input, let me reply.

1. It would be up to the head-end to decide what CP is active, so I would say 
that we probably do not need to explicitly state in this draft that only one CP 
must be active. But should explicitly state how an active CP is distinguished 
from non-active CP in terms of PCEP flags.

2. Agree, we should reference draft-sivabalan-pce-binding-label-sid, I would 
say that it's necessary to support binding-label-sid in order to support the 
current draft, because it's unpractical to have an SR Policy without a binding 
SID.

3. Agree, we should reference draft-koldychev-pce-multipath. However, it should 
not be necessary to support draft-koldychev-pce-multipath in order to support 
the current draft though. But you would only be able to have a single 
segment-list per CP without supporting draft-koldychev-pce-multipath.

4. I agree with your concerns, we can wait for wider input/consensus and decide 
what to do about this section.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Monday, June 8, 2020 12:05 PM
To: pce@ietf.org
Subject: Re: [Pce] WG adoption poll for 
draft-barth-pce-segment-routing-policy-cp-06

Hi PCE Chairs and WG

A few questions/comments regarding draft-barth-pce-segment-routing-policy-cp-06:

1.  draft-ietf-spring-segment-routing-policy states that only a single 
candidate path can be active within an SR Policy. While we wouldn't want to 
repeat all the text in the PCEP document that it's in the spring document and 
focus more on the encoding of signalling, should PCEP comment on this (only 1 
active CP in an SR Policy association group)?

2.  Binding SID is an important attribute of SR Policy, and for PCEP that is 
currently described independently in draft-sivabalan-pce-binding-label-sid (as 
it should be) - should draft-barth-pce-segment-routing-policy-cp-06 make a 
point to reference this? For an implementation of 
draft-barth-pce-segment-routing-policy-cp, must it support 
draft-sivabalan-pce-binding-label-sid ? 

3. Similar to previous point, draft-barth-pce-segment-routing-policy-cp-06 has 
editor comments regarding support of multiple SID lists to be described in 
another document. draft-koldychev-pce-multipath describes a mechanism for this. 
 Should draft-barth-pce-segment-routing-policy-cp make a reference to this? For 
an implementation of draft-barth-pce-segment-routing-policy-cp, must it support 
draft-koldychev-pce-multipath ? 

4. Section 4.3 leaves me confused. The term 'sub-candidate path' is not used 
anywhere else to my knowledge, and the concept of ECMP/UCMP makes it sound like 
the behaviour of multiple SID Lists to me, since a single candidate path will 
W-ECMP across multiple SID Lists. The use case requirement for encoding 
objective/constraints was discussed in the past, in Montreal if I recall, to 
allow the ability to tell PCE different constraints (ex: path1 take red plane, 
path2 take blue plane) and ECMP across it. I think this is certainly a valid 
use case, but it's not clear to me from this section how that's achieved within 
PCEP encoding and how that fits into the SR Policy model. How does a 
sub-candidate path differ from a SID list? Or are they the same? Then why all 
the language about PCEP tunnel and candidate path? Or is the intent to 
basically signal multiple candidate paths with the intent to ECMP across the 
SID Lists contained within them? I get a slight impression that there's a 
either (intentionally or unintentionally) potentially a logical new containment 
 introduced in the SR Policy model in order to encode optimization 
objective/constraints for PCE. The language of mapping sub-candidate paths each 
to a PCEP Tunnel also leaves me confused since a candidate path is a PCEP 
Tunnel as described in section 4.1.  Some additional clarification, diagrams or 
examples in this section is needed I think. 


Regarding the adoption call: 

Overall I think the draft should be adopted by the PCE WG. Having PCE 
instantiate and compute paths for a Candidate path, with full awareness of the 
context of an SR Policy is a natural fit. The existing implementations of SR 
Policy via BGP shows that SR Policy instantiation from a controller to the 
network is important, however in some deployments and platforms using PCEP 
would be a better fit than BGP. Using PCEP also helps ease the feedback 
complexity in reporting state back to the controller, felt by BGP.  With the 
exception of section 4.3 to me, I think the document reflects the overall 
architecture and model described in draft-ietf-spring-segment-routing-policy 
and follows a sensible encoding model in PCEP in its mappings of 
PLSP-ID/Candidate path and use of association. I think section 4.3 need to be 
evaluated and discussed in more detail - whether I think it should be before or 
after adoption I'll l

Re: [Pce] IPR Poll on draft-barth-pce-segment-routing-policy-cp-06

[Mike Koldychev (mkoldych)]

I am not aware of any IPR applicable to this draft.

Thanks,
Mike.

From: Hariharan Ananthakrishnan 
Sent: Monday, June 8, 2020 11:49 AM
To: Mike Koldychev (mkoldych) ; msiva...@gmail.com; Colby 
Barth ; pengshup...@huawei.com; hooman.bidg...@nokia.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-barth-pce-segment-routing-policy-cp-06


Hi Authors,



In preparation for WG adoption on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

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

[Mike Koldychev (mkoldych)]

Hi PCE,

We added a section for encoding the Candidate-Path name in an optional TLV (in 
addition to the already existing Policy-Name TLV) and made some minor editorial 
corrections. Comments welcome.

Thanks,
Mike.

-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, June 2, 2020 10:49 AM
To: Siva Sivabalan (msiva) ; Hooman Bidgoli 
; Shuping Peng ; Colby Barth 
; Mike Koldychev (mkoldych) 
Subject: New Version Notification for 
draft-barth-pce-segment-routing-policy-cp-06.txt


A new version of I-D, draft-barth-pce-segment-routing-policy-cp-06.txt
has been successfully submitted by Shuping Peng and posted to the IETF 
repository.

Name:   draft-barth-pce-segment-routing-policy-cp
Revision:   06
Title:  PCEP extension to support Segment Routing Policy Candidate Paths
Document date:  2020-06-02
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-barth-pce-segment-routing-policy-cp-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-barth-pce-segment-routing-policy-cp/
Htmlized:   
https://tools.ietf.org/html/draft-barth-pce-segment-routing-policy-cp-06
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-barth-pce-segment-routing-policy-cp
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-barth-pce-segment-routing-policy-cp-06

Abstract:
   This document introduces a mechanism to specify a Segment Routing
   (SR) policy, as a collection of SR candidate paths.  An SR policy is
   identified by  tuple.  An SR policy can
   contain one or more candidate paths where each candidate path is
   identified in PCEP via an PLSP-ID.  This document proposes extension
   to PCEP to support association among candidate paths of a given SR
   policy.  The mechanism proposed in this document is applicable to
   both MPLS and IPv6 data planes of SR.



  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

Re: [Pce] Please confirm whose name the SR Policy Name TLV carries in the draft

[Mike Koldychev (mkoldych)]

Hi Ruizhao,

The intent of SRPOLICY-POL-NAME TLV is to carry the *policy* name. We didn't 
define a TLV to carry the CPATH name in this draft, we assumed the PCEP 
symbolic-name can be used for that purpose. If required, we can definitely add 
another TLV to carry the CPATH name, if you want it to be separate from the 
PCEP symbolic name.

Regarding your points:

  1.  It is true that different CPATHs of the same policy can potentially 
contain different policy-name values. To ease debugging, it's much easier if 
all CPATHs of the same policy have the same policy-name. Regardless, 
policy-name is useful because the SR Policy Architecture does say that the 
policy-name (or names) MAY be used to identify an SR Policy. So we need to have 
a way to encode the policy-name(s) in PCEP.

2.1.
  Identification of an SR Policy



   An implementation MAY allow assignment of a symbolic name comprising

   of printable ASCII characters to an SR Policy to serve as a user-

   friendly attribute for debug and troubleshooting purposes.  Such

   symbolic names may identify an SR Policy when the naming scheme

   ensures uniqueness.



  1.  I will follow up with the authors of the IDR draft to clarify that there 
are two names: policy-name and cpath-name. I believe the wording needs to be 
corrected.

Thanks,
Mike.

From: huruizhao 
Sent: Monday, May 18, 2020 10:08 PM
To: pce@ietf.org; draft-barth-pce-segment-routing-policy...@ietf.org
Cc: Lihanlin ; Tanren 
Subject: Please confirm whose name the SR Policy Name TLV carries in the draft

Hi authors,
  In the section 5.2 of [draft-barth-pce-segment-routing-policy-cp-05], SR 
Policy Name TLV is defined to carry Policy name. Policy name and Candidate Path 
name have different definitions in 
[draft-ietf-spring-segment-routing-policy-06#section 2.1/2.6]. And there MAY be 
ambiguity here, I think this TLV carries name to Candidate Path instead of name 
to Policy.  The reasons are :

(1) There are multiple sources for the SR Policy of the head node. There will 
be multiple different Names to the same Policy if the PCE is allowed to deliver 
the Policy Name, which is difficult to manage.
(2) In [draft-ietf-idr-segment-routing-te-policy-08#section-2.4.6],  the draft 
clearly states "the Policy Name sub-TLV to attach a symbolic name to the SR 
Policy candidate path". The realization of BGP for SR Policy has reference 
value for PCEP.

  Please confirm whose name the SR Policy Name TLV carries in the draft.

Kind regards,
Ruizhao

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

Re: [Pce] Change Path Attrubute Object to a Sub-object

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks a lot for compiling all the information very nicely!

Hi Ruizhao,

The idea of putting PATH-ATTRIBUTES inside the ERO object was actually 
considered at IETF 105 in Montreal. We decided against it, for the reasons that 
Andrew listed.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) 
Sent: Tuesday, May 12, 2020 10:32 AM
To: huruizhao ; pce@ietf.org; 
draft-koldychev-pce-multip...@ietf.org
Cc: Lihanlin ; Tanren 
Subject: Re: [Pce] Change Path Attrubute Object to a Sub-object

Hi Ruizhao,

Thanks for the feedback and suggestion on the draft. I’m not an author, but do 
have a few comments regarding your proposal. Not sure I agree that embedding 
the Path Attribute object as a sub-object of the ERO would be better, due to 
Path Attribute Object being an object that describes a complete path definition 
and not an individual hop inside of the path definition. As well, it appears to 
me a precedence exists in somewhat related, but not PCEP, RFCs to use the ERO 
sub objects as per-hop information, and embed complete path attributes outside 
of the ERO.

Some snippets:

https://tools.ietf.org/html/rfc5440#section-7.9 states:

   The ERO is used to encode the path of a TE LSP through the network.
   The ERO is carried within a PCRep message to provide the computed TE
   LSP if the path computation was successful.

   The contents of this object are identical in encoding to the contents
   of the Resource Reservation Protocol Traffic Engineering Extensions
   (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209],
   [RFC3473], and [RFC3477].  That is, the object is constructed from a
   series of sub-objects.  Any RSVP-TE ERO sub-object already defined or
   that could be defined in the future for use in the RSVP-TE ERO is
   acceptable in this object.


https://tools.ietf.org/html/rfc8664 section 4.3 states:

   An ERO carrying
   an SR-TE path consists of one or more ERO subobjects, and it MUST
   carry only SR-ERO subobjects.

   When building the MPLS label stack from ERO, a PCC MUST assume that
   SR-ERO subobjects are organized as a last-in-first-out stack.  The
   first subobject relative to the beginning of ERO contains the
   information about the topmost label.  The last subobject contains
   information about the bottommost label.


https://tools.ietf.org/html/draft-koldychev-pce-multipath-01 states:

  We define the PATH-ATTRIB object that is used to carry per-path
  information



Taking the above snippets into consideration:

- When I read the above, to me it says ERO is the path. Path Attribute Object 
carries attributes about the path definition, not the path itself. The Path 
Attribute object isn't actually part of the path, so it shouldn't really be 
contained within the path definition but instead "wrap around it" / attach to 
it at a higher level.
- Carrying path attribute as a subObject would go against RFC 8664 statements. 
Those can be amended/extended of course, but something I think is relevant to 
point out.
- For a similar use case, RFC5420 also embeds “complete path” attributes 
outside of the ERO object construct in the context of RSVP signalled, and uses 
the RRO subobjects to capture per-hop feedback.
- From my p.o.v, 
https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-parameters-24
 (which defines the sub-objects used in PCEP as well) defines sub objects that 
are related to a specify node/hop in the path, not about the complete path. For 
example, RFC7570 defines a sub-object that is per-hop specific, not for the 
overall path.

Cheers
Andrew

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
huruizhao mailto:huruiz...@huawei.com>>
Date: Monday, May 11, 2020 at 6:35 AM
To: "pce@ietf.org" mailto:pce@ietf.org>>, 
"draft-koldychev-pce-multip...@ietf.org"
 
mailto:draft-koldychev-pce-multip...@ietf.org>>
Cc: Lihanlin mailto:lihan...@huawei.com>>, Tanren 
mailto:tan...@huawei.com>>
Subject: [Pce] Change Path Attrubute Object to a Sub-object

Hi authors,

   In the section 4.2 of [draft-koldychev-pce-multipath-01], Path Attribute 
Object is defined as a new object that is used to carry per-path information 
and to act as a separator between several ERO/RRO objects..
   The newly defined object describes the attributes of the ERO object (path 
ID, Multipath Weight TLV, Multipath Backup TLV). Therefore, we recommend 
changing it to a Sub-object carried in the ERO / RRO object. This way can make 
the information in the ERO object centralized and complete. And from an 
implementation perspective, this approach can avoid the operational complexity 
when dealing with the pairing of Path Attribute Object and ERO Object.
If you have other considerations, please contact me. Thanks.


Best Regards,
Ruizhao.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Multipath / replication segment comment

[Mike Koldychev (mkoldych)]

Regarding SID lists terminating on the same node This cannot be 
mandated/enforced from a protocol point of view. There are use cases, as Andrew 
pointed out, where the SID list(s) terminate prior to reaching the end-point 
and the packets go the rest of the way unencapsulated.

It may be that some implementations of SR-TE head-end may choose to validate 
the ERO(s) and verify that they actually do reach the end-point node, but this 
extra validation is purely optional.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Thursday, December 19, 2019 12:19 PM
To: Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Multipath / replication segment comment

Few comments below,

Cheers
Andrew

On 2019-12-19, 6:52 AM, "Dhruv Dhody"  wrote:

Hi Andrew,

Speaking as a WG contributor...

On Wed, Dec 18, 2019 at 11:58 PM Stone, Andrew (Nokia - CA/Ottawa)
 wrote:
>
> Hi all,
>
>
>
> In Singapore I made a remark about draft-koldychev-pce-multipath that 
it’s a helpful draft and is also applicable to the replication segment.
>
>
>
> I received a follow up question emailed directly, asking about whether 
“EROs need to share same source and destination” and how/if this could be 
related to RFC 8623.
>
>
>
> For openness, sending my thoughts/comments here to the WG:
>
>
>
> There is no requirement listed in draft-koldychev-pce-multipath that I 
can see which requires EROs to terminate on the same source/destination, I 
haven’t seen that expectation anywhere, and in my opinion there should not be.

[Dhruv] You are right, this is not explicit in the I-D. But based on
the scope of past discussion IMHO it was always about multiple paths
(ERO) for a single tunnel and thus finding a way to encode them within
a single report/update in a PCEP message.

[Andrew] True, the original intent of multiple paths within the same tunnel in 
a single report/update, but that could still be leveraged in the replication 
case, i.e I want a single report/update to modify the state of a replication 
segment. I think it becomes a gray area in interpretation of whether or not a 
replication segment creates a P2MP tunnel or if it's actually just creating 
multiple P2P tunnels from a single ingress label. If the interpretation is it's 
a P2MP tunnel, then using multiple EROs to define the forwarding of a P2MP. 
Tunnel requires those EROs to terminate on different nods. 

The new ERO-ATTRIB object in the I-D is just a separator between
several ERO objects in a existing PCEP message which reports/update a
particular LSP (identified by PLSP-ID in the LSP object).

> For example, one of the use cases of draft-koldychev-pce-multipath is for 
SR Policy to support multiple SID lists, combine that with use case such as 
SR-EPE, you could have multiple SID lists and have weighted ECMP traffic out 
different egress nodes intentionally to load balance across different peer 
nodes.

[Dhruv] As per the SR policy as it is currently defined - End point is
the property of the SR Policy. Each segment-list inside a candidate
path would be a specific source-routed path from the headend to the
endpoint of the corresponding SR policy. That said, in this use case
perhaps you would use an anycast address but still the same endpoint
from the SR policy point of view.


[Andrew] Coincidentally this was just mentioned in SPRING mailing list, whether 
in SR Policy endpoint is the tunnel termination vs a prefix/route to reach 
(which I kind of have to agree with), which seemed to have been raised because 
there's the concept of null/0.0.0.0 (and some wording on whether or not this is 
a valid "endpoint"). Anyways, in an EPE case I don't need to specify a path to 
reach the absolute endpoint, I just need to specify a path to steer to an 
egress peer, and with last label in the stack being an EPE Peer link or node, 
and that egress peer can take over the packet (likely not MPLS encaped anymore) 
and steer, forward or tunnel however it chooses. In this regard the SID list 
specified on the headend SR Policy "stops early" before the "real endpoint". 
From this perspective whether my ECMP SID lists stop on different routers or 
not is not really relevant for reaching the "real endpoint". Section 4.7 in 
draft-ietf-spring-segment-routing-central-epe-10 briefly comments on this, in 
the sense that to reach an internet route a SID list comprised of only SID(s) 
to reach the border node, and a SID to specify the peering router is 
sufficient. In this regard the path terminates on the peering router, despite 
the fact that my endpoint is much further in the network / perhaps across the 
internet. 


> Another example, with ingress replication, is the multipath ERO can also 
be re-used to describe the egress downstream paths which will be going to 
different re

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi Jeff, and WG,

To follow up on your comment about making these 2 separate documents: one for 
ECMP within a single LSP and another for ECMP among different LSPs.

That may be a good idea, since the mechanisms for achieving these two are quite 
different, so they are better kept separate. Just as long as it’s understood 
that they are not “conflicting” solutions.

Thanks,
Mike.

From: Mike Koldychev (mkoldych)
Sent: Tuesday, July 23, 2019 9:03 AM
To: Mike Koldychev (mkoldych) ; Cyril Margaria 

Cc: pce@ietf.org
Subject: RE: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

I have updated the slides based on our discussion.

https://github.com/mkoldych-cisco/ietf105/blob/master/pcep_multiple_ERO.pptx

We plan to discuss the issue further on Wednesday at 8:30 at the side meeting.

https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings

Thanks,
Mike.

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of Mike 
Koldychev (mkoldych)
Sent: Friday, July 19, 2019 1:03 PM
To: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Cyril,

Like I wrote in the slides… Solution 1 may work if you *only* do PCE-initiated, 
because the PCC never requests anything from the PCE, it simply installs 
whatever the PCE pushes down. Even for PCE-initiated, there are some issues, 
such as forcing the PCE to encode all the LSP objects into one message, to 
force them to get installed at the same time. Also you would need to handle 
fragmentation, if you cannot fit all the LSPs into a single message.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 12:23 PM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Mike,

One of my point is that one optimization is a peculiar case of n optimization. 
For the particuliar case of candidate path, it can be attached to a given 
association, each TE-LSP can have the same optimization criterias.

I understand the argument for Option 2 as "I want to carry and manage my 
constraint  (and candidate path) as one PCEP entity", the drawback is that it 
will become complicated in case of inter-domain and OAM which are per path.
The case for option 1 is one path, one LSP, but as you pointed out it becomes 
complicated when there is one candidate path that desire a behavior similar to  
LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed.

I think that option 1 is better in term of protocol reuse and will offer more 
flexibility, but that depends on how to deal with the PCE-managed number of 
paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (

Re: [Pce] PCReq changing state - draft-koldychev-pce-operational

[Mike Koldychev (mkoldych)]

Hi Andrew,

Thanks for the feedback, yes I think we can use absence of LSP object to mean 
“truly stateless” PCReq.

To WG,

Also wanted to address a couple of comments that were mentioned about 
Association being a container for Tunnels vs container for LSPs. The reason why 
we said it’s a container for LSPs is because it has implications on signaling. 
For example when Tunnel T1 has LSP 1 and creates another LSP 2 as part of MBB, 
then if we say that the tunnel is already in some Association then it would 
imply that the PCC does not have to include the Association object in the PCRpt 
message of LSP 2, when first reporting it. Since, LSP 2 would just “inherit” 
the Association membership of T1. On the other hand, if we say that Association 
is a container for LSPs, then LSP 2 PCRpt would need to contain the Association 
object. Clearly if two vendors interpret this differently, then they could look 
at the same PCEP messages, but end up in different ASSO-DB states! So a single 
rule is needed for how to update ASSO-DB.

If we consider disjoint path association, for example if there’s two Tunnels: 
T1 and T2 that are disjoint. Suppose T1 has two LSPs, because it’s going 
through MBB (without changing disjointness type). Then the disjoint Association 
would contain 3 LSPs:

A1 = [T1.LSP1, T1.LSP2, T2.LSP1].

It is understood that this *does not* mean that these 3 LSPs are 3-way disjoint 
from each other. It simply means that T1 and T2 are requesting disjoint paths.

Thanks,
Mike.

From: Stone, Andrew (Nokia - CA/Ottawa) 
Sent: Thursday, July 25, 2019 2:15 PM
To: pce@ietf.org; Mike Koldychev (mkoldych) 
Subject: Re: PCReq changing state - draft-koldychev-pce-operational

Hi Mike and WG,

First, wanted to say thanks for driving draft-koldychev-pce-operational as 
there’s definitely a need for it.

To expand on my comments a bit more from today, the concern I have is with the 
following statement:


“the PCE MUST NOT modify LSP-DB state based on PCReq messages. “

Existing implementation(s) already deployed may choose to do reservations in 
their LSP-DB/TEDB from a PCReq, this is primarily in the case of bandwidth 
allocation. Ex: PCE gives out bandwidth to LSP1 from PCReq1 and PCE wants to 
ensure it doesn’t give out the same BW to LSP2 PCReq2 that immediately follows. 
Since there should be no expectation of a PCRep to follow a PCReq , these 
implementations likely rely on a timeout mechanism to release the resources 
when no PCRep is received.

I believe the language should be changed to something such as “PCE MAY modify 
LSP-DB state, but MUST NOT require a PCRep message to follow a PCReq” to 
clarify this.

From the discussions, my understanding is there are 2 main reasons for why this 
statement was originally added:


  1.  Some vendors may have required PCReq to be sent before PCRep
  2.  The desire for a stateful PCE to do truly stateless PCReq for other 
purposes such as OAM

Item (1) is covered in other statements in the draft, which I’m good with.
Item (2) causes a problem(creating state, timeout for resource release) for 
those implementations which do make reservations (i.e above).

For (2), Is there another way in which we can indicate to PCE to truly treat 
the PCReq as being stateless?

For example, LSPObject is optional in the PCREQ. In the absence of LSPObject in 
the request, PCE cannot make a reservation.  Therefore, for stateless PCReq, do 
not include LSPObject in my PCReq.

Are there use cases in which the need for a stateless PCReq (for example OAM) 
to also include the LSPObject/LSP identifiers?  (I haven’t thought through this 
TBH)

If no: then the absence of that object tells PCE to not do reservation
If yes: then I think we may want to consider another flag to mark the PCReq as 
being truly stateless, when it’s being sent to a stateful PCE.

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

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi,

I have updated the slides based on our discussion.

https://github.com/mkoldych-cisco/ietf105/blob/master/pcep_multiple_ERO.pptx

We plan to discuss the issue further on Wednesday at 8:30 at the side meeting.

https://trac.ietf.org/trac/ietf/meeting/wiki/105sidemeetings

Thanks,
Mike.

From: Pce  On Behalf Of Mike Koldychev (mkoldych)
Sent: Friday, July 19, 2019 1:03 PM
To: Cyril Margaria 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Cyril,

Like I wrote in the slides… Solution 1 may work if you *only* do PCE-initiated, 
because the PCC never requests anything from the PCE, it simply installs 
whatever the PCE pushes down. Even for PCE-initiated, there are some issues, 
such as forcing the PCE to encode all the LSP objects into one message, to 
force them to get installed at the same time. Also you would need to handle 
fragmentation, if you cannot fit all the LSPs into a single message.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 12:23 PM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Mike,

One of my point is that one optimization is a peculiar case of n optimization. 
For the particuliar case of candidate path, it can be attached to a given 
association, each TE-LSP can have the same optimization criterias.

I understand the argument for Option 2 as "I want to carry and manage my 
constraint  (and candidate path) as one PCEP entity", the drawback is that it 
will become complicated in case of inter-domain and OAM which are per path.
The case for option 1 is one path, one LSP, but as you pointed out it becomes 
complicated when there is one candidate path that desire a behavior similar to  
LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed.

I think that option 1 is better in term of protocol reuse and will offer more 
flexibility, but that depends on how to deal with the PCE-managed number of 
paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated 
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be 
an advantage as its less restrictive. Having the same restriction on a set of 
paths is easy, relaxing a restriction on the ERO #5 is more complicated (in 
term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
 a)  set of LSPs can be reported in the same message, it can be enforced by 
the document defining that specific association type.
  

Re: [Pce] Updated slides

[Mike Koldychev (mkoldych)]

Hi Dhruv,

I made a couple of minor spelling corrections and uploaded my latest version 
here:
https://github.com/mkoldych-cisco/ietf105/blob/master/multiple_ERO_jl18a.pptx

I plan to finalize it after the side-meeting on Wednesday.

Thanks,
Mike.

-Original Message-
From: Dhruv Dhody  
Sent: Friday, July 19, 2019 6:10 PM
To: Mike Koldychev (mkoldych) 
Subject: Updated slides

Hi Mike,

Do you have updated slides for 3.1. Supporting Multiple ERO (SID-List) in PCEP?

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

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi Cyril,

Like I wrote in the slides… Solution 1 may work if you *only* do PCE-initiated, 
because the PCC never requests anything from the PCE, it simply installs 
whatever the PCE pushes down. Even for PCE-initiated, there are some issues, 
such as forcing the PCE to encode all the LSP objects into one message, to 
force them to get installed at the same time. Also you would need to handle 
fragmentation, if you cannot fit all the LSPs into a single message.

Thanks,
Mike.

From: Cyril Margaria 
Sent: Friday, July 19, 2019 12:23 PM
To: Mike Koldychev (mkoldych) 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi Mike,

One of my point is that one optimization is a peculiar case of n optimization. 
For the particuliar case of candidate path, it can be attached to a given 
association, each TE-LSP can have the same optimization criterias.

I understand the argument for Option 2 as "I want to carry and manage my 
constraint  (and candidate path) as one PCEP entity", the drawback is that it 
will become complicated in case of inter-domain and OAM which are per path.
The case for option 1 is one path, one LSP, but as you pointed out it becomes 
complicated when there is one candidate path that desire a behavior similar to  
LOAD-BALANCING where the PCC ask the PCE to decide how many path are needed.

I think that option 1 is better in term of protocol reuse and will offer more 
flexibility, but that depends on how to deal with the PCE-managed number of 
paths.

I will not attend the IETF meeting,

Best regards,
Cyril



On Fri, 19 Jul 2019 at 16:51, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria mailto:cyril.marga...@gmail.com>>
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) mailto:mkold...@cisco.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated 
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be 
an advantage as its less restrictive. Having the same restriction on a set of 
paths is easy, relaxing a restriction on the ERO #5 is more complicated (in 
term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
 a)  set of LSPs can be reported in the same message, it can be enforced by 
the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful for 
OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of the 
traffic does not need to be protected" cannot be expressed (it can be with 
solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is 
applicable for auto-bw and any 

Re: [Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi Cyril,

Thanks a lot for your feedback!

Maybe I need to make it clear that the problem we’re trying to solve is a 
single optimization objective resulting in multiple ECMP/UCMP paths. This is 
motivated by SR-TE Policy use case, where each Candidate Path represents a 
single optimization objective. The Candidate Path has a set of Segment Lists 
that satisfy the optimization objective.

You seem to want to solve a different problem: two or more different 
optimization objectives and each ECMP path is mapped to a different objective. 
In that case Solution 1 is absolutely necessary and it would not have any of 
the down-sides, because the PCC knows in advance how many optimization 
objectives it has and can create that many PCEP LSPs. However for our problem, 
Solution 1 would introduce a lot of implementation complexity and protocol 
overhead.

We have a side-meeting scheduled on Wednesday at 8:30 to discuss this topic, 
you are welcome to attend if you want to contribute your input.

Thanks,
Mike.

From: Cyril Margaria 
Sent: Friday, July 19, 2019 9:37 AM
To: Mike Koldychev (mkoldych) 
Cc: pce@ietf.org
Subject: Re: [Pce] Proposal for signaling ECMP or UCMP paths

Hi,

On slide "LSP objectives and constraints": Stateless  PCE can compute set of 
EROs/Label switch paths using RFC6007, including multi-domain and multi-PCEs 
scenarios. This can be used for computing a set of EROs for SR candidate paths, 
one case that can apply to the candidate path and explicitly mentioned by the 
RFC is "Two or more end-to-end diverse paths".  This does not cover the 
stateful PCE case directly, but there are similar situations to what RFC6007 in 
the form of path protection (primary/secondary/standby) for statefull PCE, 
which use the association mechanism. Those two existing mechanism exists to 
coordinate several paths and could be used to indicate how multiple paths are 
related and on how to signal them together (SVEC)

On slide "Analysis of Solution 1":
  - For PCC-Initated LSPs: what prevents the PCE to to create PCE-Initiated 
LSPs using the same association id? This would tackle the problem.
  - The possibility of each path to have different objective does seems to be 
an advantage as its less restrictive. Having the same restriction on a set of 
paths is easy, relaxing a restriction on the ERO #5 is more complicated (in 
term of encoding).
  - There is a set of options to achieve the "signal the set of paths together":
 a)  set of LSPs can be reported in the same message, it can be enforced by 
the document defining that specific association type.
 b) SVEC/SVEC List can be extended to statefull PCEP,

That solution would work in case of multi-domain PCEs, and also be helpful for 
OAM and auto-bw mechanism.
As a segment list is one path in the network, that maps nicely to one LSP.


Solution 2:
  - This limit the set of constraints to be applied, policies like "10% of the 
traffic does not need to be protected" cannot be expressed (it can be with 
solution 1, clear L bit of LSPA on one TE-LSP out of 10)
  - 2.a when the LSP is reported down : which ERO is down?, the same is 
applicable for auto-bw and any form of OAM data.
  - Solution 2.b allows for Optimized branch encoding, that should be disabled 
for that solution


Slide "Comparison of Solutions":
   - There are solutions to most of the points raised for solution 1
   - The database problem seems specific to one implementation, other 
implementation will have the problem for solution 2
   -  multi-PCE and multi-domain are not evaluated. Solutions and consideration 
are available for solution 1, not for solution 2. (experimental Inter-domain 
P2MP tree solutions exists).

Best Regards,
Cyril

On Fri, 12 Jul 2019 at 22:02, Mike Koldychev (mkoldych) 
mailto:mkold...@cisco.com>> wrote:
Hi WG,

As per SPRING WG, SR Policy may contain multiple Candidate Paths and each 
Candidate Path may contain multiple Segment Lists. Existing SR standards in 
PCEP allow only a single ERO (one Segment List) for the SR Path in a stateful 
PCEP message. There is a need to signal multiple Segment Lists in PCEP for this 
as well as other load balancing use cases.

See the link that describes this, as well as list possible ways to achieve 
this. Please provide your feedback on the list or during the WG session.

https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf

Thanks,
Mike.

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

[Pce] Proposal for signaling ECMP or UCMP paths

[Mike Koldychev (mkoldych)]

Hi WG,

As per SPRING WG, SR Policy may contain multiple Candidate Paths and each 
Candidate Path may contain multiple Segment Lists. Existing SR standards in 
PCEP allow only a single ERO (one Segment List) for the SR Path in a stateful 
PCEP message. There is a need to signal multiple Segment Lists in PCEP for this 
as well as other load balancing use cases. 

See the link that describes this, as well as list possible ways to achieve 
this. Please provide your feedback on the list or during the WG session.

https://github.com/dhruvdhody-huawei/105/blob/master/multiple_ERO_jl03a.pdf

Thanks,
Mike.

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

Re: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

[Mike Koldychev (mkoldych)]

Support.

Thanks,
Mike.

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: Tuesday, June 4, 2019 12:26 PM
To: pce@ietf.org
Cc: draft-ietf-pce-lsp-control-requ...@ietf.org
Subject: [Pce] WG LC for draft-ietf-pce-lsp-control-request-04

Hi WG,

This email starts a working group last call for 
draft-ietf-pce-lsp-control-request-04. The WG LC will run for 2 weeks, till 
19th June 2019.

https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-control-request/

Please indicate your support or concern for this draft.

If you are opposed to the progression of the draft, please articulate your 
concern.

If you support, please indicate that you have read the latest version and it is 
ready for publication. Further, explaining the importance of the work in your 
opinion is appreciated.

As always, review comments and nits are most welcome. Silence on the list, not 
so much :)

Thanks,
Dhruv, Julien, & Adrian

___
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] Comment on draft-barth-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Tarek,

Yes, because draft-barth-pce-segment-routing-policy-cp covers both "controller 
-> device" and "device -> controller" signaling, these extra attributes are 
needed for us. I agree that draft-ietf-idr-segment-routing-te-policy does not 
need them because they are implicit in BGP.

Thanks,
Mike.

From: Tarek Saad 
Sent: Wednesday, March 20, 2019 12:29 PM
To: Mike Koldychev (mkoldych) ; Dhruv Dhody 

Cc: draft-barth-pce-segment-routing-policy...@ietf.org; pce@ietf.org
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Mike,

>> Hi Tarek,
>> In addition to what Dhruv has said, I don't believe 
>> draft-ietf-idr-segment-routing-te-policy provides a way to encode "Protocol 
>> Origin", "Originator ASN" and "Originator Address". These are essential for 
>> reporting existing policies from the PCC to the PCE.
[TS]: Agreed. However, as far as I see, 
draft-ietf-idr-segment-routing-te-policy covers the "controller -> device" 
signaling only. The attributes you mention are for reporting state from "device 
-> controller".

Regards,
Tarek

Thanks,
Mike.

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: Wednesday, March 20, 2019 11:14 AM
To: Tarek Saad mailto:tsaad@gmail.com>>
Cc: 
draft-barth-pce-segment-routing-policy...@ietf.org<mailto:draft-barth-pce-segment-routing-policy...@ietf.org>;
 pce@ietf.org<mailto:pce@ietf.org>
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

As a individual WG member, I think reusing BGP sub-TLV in PCEP in this case(*) 
is problematic, mainly because -

(1) PCEP already has some other objects and TLVs which were defined much before 
the BGP SR Policy work, such as -
- SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV)
- TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV)

(2) PCEP has a very specific format for all its TLVs as per 
https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP does 
not follow that.

(3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or candidate 
path) we carry its associated Policy information in the ASSOCIATION object.

That said, it is important that fields and encoding are aligned between BGP and 
PCEP and I would request the authors to make sure that is the case.

Thanks!
Dhruv

(*) We were able to do this successfully in case of Flowspec

On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad 
mailto:tsaad@gmail.com>> wrote:
Hi authors,

The I-D "draft-ietf-idr-segment-routing-te-policy" defines sub-tlvs for SR 
Policy attributes that are carried in BGP (see below) for SR policy and its 
attributes. Ideally, with PCEP can achieve what is supported with BGP signaling 
and hence can leverage the most of those definitions? Is there a reason not to?



 
2.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2..4>.
  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   
9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

   
2.4.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.1>.
  Preference Sub-TLV  . . . . . . . . . . . . . . .. . .   
9<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-9>

   
2.4.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.2>.
  Binding SID Sub-TLV . . . . . . . . . . .. . . . . . .  
10<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-10>

   
2.4.3<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3>.
  Segment List Sub-TLV  . . . . . . . . . . . . . .. . .  
11<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-11>

   
2.4.3.1<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.1>.
  Weight Sub-TLV

   
2.4.3.2<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.3.2>.
  Segment Sub-TLV

   
2.4.4<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.4>.
  Explicit NULL Label Policy Sub-TLV  . . . . . . .. . .  
27<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-27>

   
2.4.5<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.5>.
  Policy Priority Sub-TLV . . . . . . . . .. . . . . . .  
28<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#page-28>

   
2.4.6<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-05#section-2.4.6>.
  Policy Name Sub-TLV . . . . . . . . . . .. . . . . . .  
29<https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-

Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

[Mike Koldychev (mkoldych)]

Hi Tarek,

In addition to what Dhruv has said, I don’t believe 
draft-ietf-idr-segment-routing-te-policy provides a way to encode “Protocol 
Origin”, “Originator ASN” and “Originator Address”. These are essential for 
reporting existing policies from the PCC to the PCE.

Thanks,
Mike.

From: Dhruv Dhody 
Sent: Wednesday, March 20, 2019 11:14 AM
To: Tarek Saad 
Cc: draft-barth-pce-segment-routing-policy...@ietf.org; pce@ietf.org
Subject: Re: [Pce] Comment on draft-barth-pce-segment-routing-policy-cp

Hi Tarek,

As a individual WG member, I think reusing BGP sub-TLV in PCEP in this case(*) 
is problematic, mainly because -

(1) PCEP already has some other objects and TLVs which were defined much before 
the BGP SR Policy work, such as -
- SR-ERO subobject to carry SID (compared to BGP's Segment sub-TLV)
- TE-PATH-BINDING TLV for BSID (compared to BGP's Binding SID sub-TLV)

(2) PCEP has a very specific format for all its TLVs as per 
https://tools.ietf.org/html/rfc5440#section-7.1, you would notice that BGP does 
not follow that.

(3) SR-POLICY is a top level container, in PCEP-SR for each LSP (or candidate 
path) we carry its associated Policy information in the ASSOCIATION object.

That said, it is important that fields and encoding are aligned between BGP and 
PCEP and I would request the authors to make sure that is the case.

Thanks!
Dhruv

(*) We were able to do this successfully in case of Flowspec

On Tue, Mar 19, 2019 at 1:12 AM Tarek Saad 
mailto:tsaad@gmail.com>> wrote:
Hi authors,

The I-D “draft-ietf-idr-segment-routing-te-policy” defines sub-tlvs for SR 
Policy attributes that are carried in BGP (see below) for SR policy and its 
attributes. Ideally, with PCEP can achieve what is supported with BGP signaling 
and hence can leverage the most of those definitions? Is there a reason not to?



 
2.4.
  SR Policy Sub-TLVs  . . . . . . . . . . . . . . . . . . .   
9

   
2.4.1.
  Preference Sub-TLV  . . . . . . . . . . . . . . . . .   
9

   
2.4.2.
  Binding SID Sub-TLV . . . . . . . . . . .. . . . . . .  
10

   
2.4.3.
  Segment List Sub-TLV  . . . . . . . . . . . . . . . .  
11

   
2.4.3.1.
  Weight Sub-TLV

   
2.4.3.2.
  Segment Sub-TLV

   
2.4.4.
  Explicit NULL Label Policy Sub-TLV  . . . . . . . . .  
27

   
2.4.5.
  Policy Priority Sub-TLV . . . . . . . . .. . . . . . .  
28

   
2.4.6.
  Policy Name Sub-TLV . . . . . . . . . . .. . . . . . .  
29


Regards,
Tarek
___
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] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Mike Koldychev (mkoldych)]

yes/support

From: Pce mailto:pce-boun...@ietf.org>> on behalf of 
Jonathan Hardwick 
mailto:Jonathan.Hardwick=40metaswitch@dmarc.ietf.org>>
Date: Saturday, October 13, 2018 at 10:57 AM
To: "pce@ietf.org" mailto:pce@ietf.org>>
Cc: 
"draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org"
 
mailto:draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org>>,
 "pce-cha...@ietf.org" 
mailto:pce-cha...@ietf.org>>
Subject: [Pce] WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

Please review the draft and send an email to the list indicating “yes/support” 
or “no/do not support”.  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

The poll ends on Friday, October 26.

Many thanks,

Jon and Julien

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