[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Andrew Stone (Nokia)]

….. or maybe in this document we can have text that simply says:

“RFC 7470 defines the Enterprise Numbers are allocated by IANA and managed 
through an IANA registry [RFC2578]. This document further clarifies that the 
IANA registry described is the Private Enterprise Numbers (PEN), in which 
registrations and the registration location are further described by RFC 9371”

From: Andrew Stone (Nokia) 
Date: Tuesday, July 9, 2024 at 4:31 PM
To: Samuel Sidor (ssidor) , Boris Hassanov 
, pce@ietf.org , Dhruv Dhody 

Cc: pce-chairs , 
draft-ietf-pce-stateful-pce-ven...@ietf.org 

Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03
Hi all,

I’ve read the latest version and support it’s progression. The text is a clear 
read.

Share similar comment of Boris’ about Enterprise number – inherited from RFC 
7470 -> points to RFC 2578 -> then pointers drop unless you read between the 
lines that it’s effectively the SNMP OID PEN. Maybe it’s worth having a bit 
more text for this just to say it’s from the IANA “Private Enterprise Numbers” 
registry? or a reference to RFC9371? Although an update for RFC7470 to clarify 
this (can that be a BIS?) is likely better than embedding it in this extension 
draft.

Thanks
Andrew


From: Samuel Sidor (ssidor) 
Date: Monday, July 8, 2024 at 5:30 AM
To: Boris Hassanov , pce@ietf.org , Dhruv 
Dhody 
Cc: pce-chairs , 
draft-ietf-pce-stateful-pce-ven...@ietf.org 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

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

At least my understanding is that:
1) As indicated later in that draft "Different instances of the object can have 
different Enterprise Numbers" - Enterprise ID can be different, but it can be 
same as well, so you can decide to include 2 vendor info objects with same 
Enterprise number if you want as well (e.g. if each of them represent some 
future standard object with not allocated codepoints and you want to simplify 
parsing).

" if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor 
Information Object per each object per each LSP?"

Correct. Let's use one example - you want to report per LSP statistics in PCEP 
- since there is no standard object, you can encode it into vendor specific 
object. If there is 3rd party PCE, then it will just ignore it (because 
Enterprise ID is not matching).

2) Since format of vendor object/TLV used by each vendor is not 
published/standardized (this is answering you other question as well), then at 
least I'm really assuming that in vast majority of cases, vendor objects for 
multiple different vendors will not be advertised. E.g. Cisco PCC will use 
vendor info object with cisco enterprise number only. " 
https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1; is already even 
suggesting making advertisement of vendor object configurable, so it can be 
blocked if 3rd party PCE is used. See also 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4
 - draft is already inheriting all manageability considerations from RFC7470.

3) Enterprise numbers are not PCEP specific. See:
https://www.iana.org/assignments/enterprise-numbers/

Regards,
Samuel

-Original Message-
From: Boris Hassanov 
Sent: Sunday, July 7, 2024 4:24 PM
To: pce@ietf.org; Dhruv Dhody 
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi Dhruv and WG,

I read the latest version of draft.  Indeed It adds more flexibility  to 
provide vendor-specific information for  PCEs using different messages.
I support the further work on this draft. But I would like to see the following 
clarifications:

1) The draft says : "Multiple instances of the object MAY be used on a single 
PCRpt message.". Does it mean the  addition of different Vendor Information 
objects (with different Enterprise numbers) per each PCEP object in PCRpt ? If 
I got it correct. if we have big/huge amount of LSPs in that PCRpt message, 
will we have Vendor Information Object per each object per each LSP?
2) RFC 7470 has section 6.6 Impact on Network Operation which says: " On the 
other hand, the presence of additional vendor-specific information in PCEP 
messages may congest the operation of the protocol especially if the PCE does 
not support the information supplied by the PCC.  ".
I would like to see some analysis in the draft about potential impact of 
increasing the amount of Vendor Information objects on network operations too. 
IMO similar section as in RFC 7470 is needed.


3) RFC 7470 also says: "Enterprise Numbers are assigned by IANA and managed 
through an IANA registry ".  But they are absent so far (at least here: 
https://www.iana.org/assignments/pcep/pcep.xhtml  ).


How can customers which dev

[Pce] Re: WGLC for draft-ietf-pce-stateful-pce-vendor-03

[Andrew Stone (Nokia)]

Hi all,

I’ve read the latest version and support it’s progression. The text is a clear 
read.

Share similar comment of Boris’ about Enterprise number – inherited from RFC 
7470 -> points to RFC 2578 -> then pointers drop unless you read between the 
lines that it’s effectively the SNMP OID PEN. Maybe it’s worth having a bit 
more text for this just to say it’s from the IANA “Private Enterprise Numbers” 
registry? or a reference to RFC9371? Although an update for RFC7470 to clarify 
this (can that be a BIS?) is likely better than embedding it in this extension 
draft.

Thanks
Andrew


From: Samuel Sidor (ssidor) 
Date: Monday, July 8, 2024 at 5:30 AM
To: Boris Hassanov , pce@ietf.org , Dhruv 
Dhody 
Cc: pce-chairs , 
draft-ietf-pce-stateful-pce-ven...@ietf.org 

Subject: RE: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

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

At least my understanding is that:
1) As indicated later in that draft "Different instances of the object can have 
different Enterprise Numbers" - Enterprise ID can be different, but it can be 
same as well, so you can decide to include 2 vendor info objects with same 
Enterprise number if you want as well (e.g. if each of them represent some 
future standard object with not allocated codepoints and you want to simplify 
parsing).

" if we have big/huge amount of LSPs in that PCRpt message, will we have Vendor 
Information Object per each object per each LSP?"

Correct. Let's use one example - you want to report per LSP statistics in PCEP 
- since there is no standard object, you can encode it into vendor specific 
object. If there is 3rd party PCE, then it will just ignore it (because 
Enterprise ID is not matching).

2) Since format of vendor object/TLV used by each vendor is not 
published/standardized (this is answering you other question as well), then at 
least I'm really assuming that in vast majority of cases, vendor objects for 
multiple different vendors will not be advertised. E.g. Cisco PCC will use 
vendor info object with cisco enterprise number only. " 
https://www.rfc-editor.org/rfc/rfc7470.html#section-6.1; is already even 
suggesting making advertisement of vendor object configurable, so it can be 
blocked if 3rd party PCE is used. See also 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.html#section-4
 - draft is already inheriting all manageability considerations from RFC7470.

3) Enterprise numbers are not PCEP specific. See:
https://www.iana.org/assignments/enterprise-numbers/

Regards,
Samuel

-Original Message-
From: Boris Hassanov 
Sent: Sunday, July 7, 2024 4:24 PM
To: pce@ietf.org; Dhruv Dhody 
Cc: pce-chairs ; 
draft-ietf-pce-stateful-pce-ven...@ietf.org
Subject: Re: [Pce] WGLC for draft-ietf-pce-stateful-pce-vendor-03

Hi Dhruv and WG,

I read the latest version of draft.  Indeed It adds more flexibility  to 
provide vendor-specific information for  PCEs using different messages.
I support the further work on this draft. But I would like to see the following 
clarifications:

1) The draft says : "Multiple instances of the object MAY be used on a single 
PCRpt message.". Does it mean the  addition of different Vendor Information 
objects (with different Enterprise numbers) per each PCEP object in PCRpt ? If 
I got it correct. if we have big/huge amount of LSPs in that PCRpt message, 
will we have Vendor Information Object per each object per each LSP?
2) RFC 7470 has section 6.6 Impact on Network Operation which says: " On the 
other hand, the presence of additional vendor-specific information in PCEP 
messages may congest the operation of the protocol especially if the PCE does 
not support the information supplied by the PCC.  ".
I would like to see some analysis in the draft about potential impact of 
increasing the amount of Vendor Information objects on network operations too. 
IMO similar section as in RFC 7470 is needed.


3) RFC 7470 also says: "Enterprise Numbers are assigned by IANA and managed 
through an IANA registry ".  But they are absent so far (at least here: 
https://www.iana.org/assignments/pcep/pcep.xhtml  ).


How can customers which develop their own PCEs or open source PCEs can know the 
details of that vendor specific information into Vendor Information objects to 
consider that in their path calculation algos?
Will vendors disclose it somehow as their good will or it will be just sort of 
black box approach?


Thank you in advance.


SY,
Boris










On Thursday, July 4, 2024 at 04:18:29 PM GMT+3, Dhruv Dhody 
 wrote:





Hi WG,This email starts a 2-weeks working group last call for 
draft-ietf-pce-stateful-pce-vendor-03.https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-03.htmlPlease
 indicate your support or concern for this draft. If you are opposed to the 
progression of the draft to RFC, please articulate 

[Pce] Re: Where the Controlled ID info shuold be carried/encoded?

[Andrew Stone (Nokia)]

Hi all,

I like the PcOpen + PcNotify idea, mainly because I hope we can generically 
define a pattern of PcOpen content refresh without the need for a session flap. 
 Using PcOpen+PcNotify also becomes a bit more consistent in approach with the 
similar state synchronization proposal for add/delete PcOpen between PCE’s. I 
do not think we should add (even partial) dependency on PCEP-LS to solve that 
generalized problem. I also do not think we should overload PcRpt since the use 
of PcRpt is well understood to be about LSP state, and mucking with it to fit 
other content feels like it's being overloaded.

Therefore I think it comes down to a new message (PcOpenRefresh?) or leveraging 
PcNotify. I currently don't see a block on using PcNotify for this.

To keep it simple I think the TLVs in the PcNotify should be a snapshot equal 
to the same content as if this was PcOpen upon connect (i.e don't send diff).  
In other words as an example with draft-ietf-pce-controlled-id-space, if 
someone adds a new range to the PCC, the PcNotify would carry a 
LABEL-CONTROLS-SPACE-TLV which contains both existing and new ranges and not 
build in add/remove/diff semantics inside of the TLV itself.

Thanks
Andrew

From: Cheng Li 
Date: Tuesday, July 9, 2024 at 6:28 AM
To: Dhruv Dhody 
Cc: pce@ietf.org , pce-chairs , Samuel Sidor 
(ssidor) 
Subject: RE: [Pce] Where the Controlled ID info shuold be carried/encoded?

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.


Yes, I also think this combination is better.
Option 1 Open msg can be used for initial report, and the rest update can be 
reported by the Notification msg.

Already recorded this in the slide.

Cheng


From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 11:34 AM
To: Cheng Li 
Cc: pce@ietf.org; pce-chairs ; Samuel Sidor (ssidor) 

Subject: Re: [Pce] Where the Controlled ID info shuold be carried/encoded?

Hi,

Samuel made a suggestion to combine the options of using Open and Notification 
together, I have now captured that in the notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view

Feel free to add to the discussion here or on the notes page.

Thanks!
Dhruv

On Sat, Jul 6, 2024 at 2:53 PM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi Cheng,

To facilitate this discussion I have created a notes page - 
https://notes.ietf.org/draft-ietf-pce-controlled-id-space?view that documents 
the various options.

WG,

Feel free to add things there but add your name for easy tracking.
You can also add your preference for a solution and with reasoning at the 
bottom or simply reply on this thread and I can keep the notes page updated.

Hope the WG finds this useful and it helps in converging on a way forward...

Thanks!
Dhruv

On Thu, Jun 20, 2024 at 10:46 AM Cheng Li 
mailto:40huawei@dmarc.ietf.org>> wrote:
Hi Guys，

Thank you so much for your helpful review and comments of our draft 
draft-ietf-pce-controlled-id-space.
In the WG adoption, I can summarize our discussion into the below bullets, hope 
they are correct,

  1.  The draft is useful, and the mechanism defined in the draft is needed, we 
should work on it. (Thanks!)
  2.  We need to discuss the where the info should be carried in the PCEP. Open 
Object seems not so good ☹
  3.  TLV encoding should be updated to be more generic or let's avoid the 
generic description and define specific sub-TLVs as needed.

I see the reasons why we decided to carry the info in PCEP Open Object, because 
it is a device-wide configuration info, which should not be modified in the 
running state. We may face a lot of trouble of removing some IDs and then 
modify the range in a running network. However, we may also need to handle the 
negotiation between PCC and PCE?  Therefore, I am also concerning about this.

I like to hear your voice on this, which object/msg is appropriate to carry the 
info? I am open with other options.

Possible options could be

•  Open message

•  Use PCEP-LS encoding and make this a node attribute

•  New type of notification

•  New message/object

Once we get the conclusion of this, we can go to the bullet 3, which is much 
easier that bullet 2. IMHO, I will prefer to define sub-TLVs one by one, this 
can decouple the relations between IDs, though we may need to delete the 
'generic' words.

Thoughts?
Cheng

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Pending item for draft-ietf-pce-state-sync

[Andrew Stone (Nokia)]

Hi Dhruv, PCE WG

Thanks for bringing this up again. PcNotif object with an add/remove semantics 
is exactly what I was thinking about as well in terms of how to carry this. I 
think we could (later) expand this to PCC->PCE communication to permit 
on-the-fly updates/changes to PcOpen criteria to avoid requiring session flap 
should knobs be flipped. With that said, I do like the proposed scoping of this 
via notification type so that way delete mechanics can only be applied for 
state sync.

Minor recommendation to clarify the PcNtf should be sent before StateSync / 
PcRpt messages:

On session establishment with a state-sync PCE, the PCE MUST also exchange
notifications for each of the PCCs it already has a session
established prior to State Synchronization described in section 3.2.

Overall text proposal looks good to me. I would assume this belongs in a 3.x 
section in the document.

Only caveat I can see is there would be no mechanism to potentially carry flag 
values from the PcOpen object, however, there's currently no flags defined 
after all these years and I suspect if they ever were defined they likely may 
not be relevant for state sync anyways. Should it ever be required, it would be 
straight forward to define a new TLV for pce-state sync to carry that anyways. 
I do not think we need to handle this now.

Thanks!
Andrew

From: Dhruv Dhody 
Date: Saturday, July 6, 2024 at 7:52 AM
To: draft-ietf-pce-state-s...@ietf.org , 
Andrew Stone (Nokia) 
Cc: pce@ietf.org , pce-chairs 
Subject: Pending item for draft-ietf-pce-state-sync

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,

There has been one pending item in draft-ietf-pce-state-sync. During IETF 119, 
we discussed adding support for the PCE to send the information it received in 
the PCC's open message to the other state-sync PCEs.

Here is my initial proposal of using a new notification type for this purpose. 
I have some initial text that authors and WG can consider. We can discuss this 
during IETF 120 as well if required.

---
3.5.1.  Information Received via Open Message from PCC

   To ensure uniform information across all PCEs, each PCE needs to
   relay the information it receives from the PCCs in the Open message
   to other PCEs via the state-sync session.  This includes various PCC
   capabilities and parameters such as Maximum Segment Identifier (SID)
   Depth (MSD).

   As per [RFC5440], the PCEP Notification message (PCNtf) can be sent
   by a PCEP speaker to notify its peer of a specific event.  A PCE
   should notify the other state-sync PCEs of the information it
   receives from the PCCs open message.  Section 7.14 of [RFC5440]
   specify the NOTIFICATION object.  This document adds a new
   Notification-type=TBD6 (Inter-PCE State-sync) and two Notification-
   values (Notification-value=1 (Add PCC's Open Information) and
   Notification-value=2 (Remove PCC's Open Information)).

   For Notification-type=TBD6, the NOTIFICATION object encodes the
   SPEAKER-ENTITY-ID TLV and any other TLV that can be carried inside
   the OPEN object as a way to signal the PCC's information it received
   via the open message to other state-sync PCEs.

   *  Notification-value=1: Add PCC's Open Information.  On session
  establishment with a PCC, a PCE with state-sync capability MUST
  send this notification to other state-sync PCEs with the SPEAKER-
  ENTITY-ID TLV with values that identify the PCC and any other TLVs
  encoded in the OPEN object received from the PCC.  On session
  establishment with a state-sync PCE, the PCE MUST also exchange
  notifications for each of the PCCs it already has a session
  established.  Note that the PCNtf can be used to carry multiple
  NOTIFICATION objects, one for each PCC.  On receiving this
  notification, PCE adds the information to its database.

   *  Notification-value=2: Remove PCC's Open Information.  On session
  down with a PCC, a PCE with state-sync capability MUST send this
  notification to other state-sync PCEs with the SPEAKER-ENTITY-ID
  TLV with values that identify the PCC to remove the information
  from the database.

   A PCE may receive this Notification from multiple PCEs that a given
   PCC has a session and can use a similar mechanism as described in
   Section 3.4 to keep the freshest state.  In case of the termination
   of state-sync session, this information is also cleaned up alongside
   LSP-DB.
---


Would this be a good way forward? Am I missing something? Is there any other 
proposal on the table?

Thanks!

Dhruv (no-hats!)
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] IPR poll for draft-ietf-pce-stateful-pce-vendor

[Andrew Stone (Nokia)]

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
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Call for slot in the PCE WG at IETF 120

[Andrew Stone (Nokia)]

Hi PCE WG,

Friendly reminder about the below!

Thanks
Andrew
(PCE WG Secretary)

From: Dhruv Dhody 
Date: Saturday, June 22, 2024 at 5:17 AM
To: pce@ietf.org 
Cc: pce-chairs 
Subject: Call for slot in the PCE WG at IETF 120
Hi,

The PCE WG would be meeting during the IETF 120 [1] week. If you need agenda 
time to progress some work, please send a slot request directly to the 
chairs/secretary mailto:pce-cha...@ietf.org>> by Monday, 
July 8th by including:

- the draft(s) you want to discuss,
- the expected presenter name,
- will you be attending in-person or remote
- the requested duration, including question time as part of the slot,
- the reason why you want to be on the agenda; What do you want to achieve? Why 
is a presentation necessary to achieve it?

Please note - Asking for a slot does not mean you will get one. We will be 
prioritizing moving WG work first as well as drafts that were discussed on the 
mailing list. Please make sure to introduce your new draft or summarize an 
update on the mailing list. The last date to submit drafts is also Monday, July 
8th [2]. Also, let us know if you have requested agenda time in a different WG 
session for the same topic.

Thanks!
PCE Chairs & Secretary

[1] https://datatracker.ietf.org/meeting/120/agenda
[2] https://datatracker.ietf.org/meeting/important-dates/
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

[Andrew Stone (Nokia)]

Hi PCEWG, Authors

Thanks for the document. I've read through the latest version, and it is a 
clear read in its use cases and purpose. I have two questions/comments below, 
but do not think these fundamentally change the document and support its 
publication.

Thanks
Andrew


- Introduction

Should the mutual dependency with draft-ietf-pce-multipath be simplified to 
allow independent draft progression? The text basically just says "can also use 
in composite path" without much description (which makes sense as it's 
described in multipath) so I'm questioning its value and whether to just 
replace the reference with below. (..after writing this I see Adrian suggested 
dropping it, which I am also okay with).

"This document does not restrict the TLV inclusion to only use cases or objects 
defined below. Other documents may describe and leverage the Color TLV 
specified in this document in other PCEP objects."

- Capability exchange

Should the capability exchange be more specific? As indicated in the document, 
the object carrying the TLV depends on purpose. Currently that's in LSP 
Object(rsvp steering case) or ERO (composite case). An implementation may 
support one or the other or neither, but from the capability exchange (in this 
document and multipath) this seems indistinguishable. Perhaps this a concern 
for draft-ietf-pce-multipath to sort out, but makes me wonder if 
draft-ietf-pcep-pcep-color capability should restrict the capability to usage 
in the LSP object when path-setup=type is RSVP?




From: Dhruv Dhody 
Date: Sunday, June 16, 2024 at 12:24 AM
To: pce@ietf.org 
Cc: pce-chairs , draft-ietf-pce-pcep-co...@ietf.org 

Subject: Re: WGLC for draft-ietf-pce-pcep-color-04

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,

Reminder to respond to this WGLC poll.
Please be more explicit in your support (or not) for publishing this I-D by 
responding on the mailing list. Silence makes it hard to judge consensus.

Thanks!
Dhruv


On Tue, Jun 4, 2024 at 9:20 AM Dhruv Dhody 
mailto:d...@dhruvdhody.com>> wrote:
Hi WG,

This email starts a 2-weeks working group last call for 
draft-ietf-pce-pcep-color-04.
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-color/

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 Tuesday 18 June 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
To unsubscribe send an email to pce-le...@ietf.org

[Pce] IPR poll for draft-ietf-pce-pcep-color

[Andrew Stone (Nokia)]

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
To unsubscribe send an email to pce-le...@ietf.org

[Pce] IPR poll for draft-li-pce-controlled-id-space

[Andrew Stone (Nokia)]

Hi Authors,

In preparation for WG adoption 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
To unsubscribe send an email to pce-le...@ietf.org

[Pce] IPR poll for draft-dhodylee-pce-pcep-ls

[Andrew Stone (Nokia)]

Hi Authors,
In preparation for WG adoption 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

[Pce] PCE WG minutes for IETF 119

[Andrew Stone (Nokia)]

Hi WG,
Please find the minutes for PCE WG session 
https://datatracker.ietf.org/meeting/119/materials/minutes-119-pce-202403190530-00
Thanks to those who contributed to the minutes.
Please reach out to pce-cha...@ietf.org in case any 
correction needs to be made.
Thanks,
Dhruv, Julien & Andrew

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

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

[Andrew Stone (Nokia)]

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

Thanks! 
Andrew


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


[You don't often get email from mkold...@proton.me <mailto:mkold...@proton.me>. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification 
<https://aka.ms/LearnAboutSenderIdentification> ]


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.






Hi Andrew,


(sorry my email client glitched)


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


Thanks,
Mike.


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


>
>
> Hi Andrew,
>
> We did keep in sync with the IDR draft authors. The intent is to make the 
> registry the same. There was an issue with interpretation of the Protocol 
> Origin values 10, 20, 30 from RFC 9256. In PCEP we interpreted them as being 
> actual code-points and some implementations have gone that way already. While 
> in BGP, different code-points were used. This is why the IDR draft has
>
>
>
>
> On Wednesday, January 17th, 2024 at 10:23 AM, Andrew Stone \(Nokia\) 
> andrew.stone=40nokia@dmarc.ietf.org <mailto:40nokia@dmarc.ietf.org> 
> wrote:
>
> > Hi Mike,
> >
> > Thanks for addressing the comments, looks good to me.
> >
> > Regarding section 6.5 - is it worth making the text identical to match 
> > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-03#section-8.4
> >  
> > <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-03#section-8.4>
> >  since I assume the intent is for both of these docs to use the same 
> > registry under Segment Routing? Naturally makes sense to not define values 
> > outside of the PCEP scope, however might be worth making sure the 
> > descriptions match even if they may appear redundant (i.e code point 1, 10, 
> > 20, 30). Comparing the two it's also not clear to me what code point value 
> > 1 is in IDR vs unassigned in PCEP.
> >
> > With that said, considering IDR was proposing similar and the origins can 
> > be common amongst many different protocols, think it makes sense to have 
> > the registry under Segment Routing.
> >
> > Thanks
> > Andrew
> >
> > On 2024-01-16, 11:48 PM, "Pce on behalf of Mike Koldychev" 
> > mailto:pce-boun...@ietf.org> 
> > mailto:pce-boun...@ietf.org <mailto:pce-boun...@ietf.org> on behalf of 
> > mkoldych=40proton...@dmarc.ietf.org <mailto:40proton...@dmarc.ietf.org> 
> > mailto:40proton...@dmarc.ietf.org <mailto:40proton...@dmarc.ietf.org>> 
> > wrote:
> >
> > Hi WG,
> >
> > I addressed all comments that I received so far (let me know if I missed 
> > anything).
> >
> > I copied some text from [I-D.ietf-idr-segment-routing-te-policy] into 
> > Section 5.3, to avoid making a normative reference to that draft. So we 
> > should probably review it again in more detail.
> >
> > Also, we need to double check Section 6.5 
> > (https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5
> >  
> > <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5>
> >  
> > https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5
> >  
> > <https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5>),
> >  to make sure it's a good idea to create the new registry under Segment 
> > Routing instead of under PCEP.
> >
> > Thanks,
> > Mike.
> >
> > Sent with Proton Mail secure email.
> >
> > On Tuesday, January 16th, 2024 at 7:48 PM, internet-dra...@ietf.org 
> > <mailto:internet-dra...@ietf.org> mailto:internet-dra...@ietf.org 
> > <mailto:internet-dra...@ietf.or

[Pce] IPR poll for draft-ietf-pce-stateful-pce-optional

[Andrew Stone (Nokia)]

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-peng-pce-entropy-label-position-10

[Andrew Stone (Nokia)]

Hi Quan,

Replies inline below.

Thanks
Andrew

From: "xiong.q...@zte.com.cn" 
Date: Sunday, February 4, 2024 at 3:26 AM
To: "Andrew Stone (Nokia)" 
Cc: "d...@dhruvdhody.com" , "pce@ietf.org" , 
"pce-cha...@ietf.org" , 
"draft-peng-pce-entropy-label-posit...@ietf.org" 

Subject: Re: WG Adoption of draft-peng-pce-entropy-label-position-10

You don't often get email from xiong.q...@zte.com.cn. Learn why this is 
important<https://aka.ms/LearnAboutSenderIdentification>


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.





Hi Andrew,

Thanks for your detailed review and suggestions! Much appreciated!

Please see in line with [Quan].



- Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? 
 From the read I don't see any other purpose than "this is also ongoing" and 
can likely be removed?

 [Quan]: Thanks for your remind. Other than the BGP ongoing work, the acronym 
of ELP (Entropy Label Position) was also defined in that draft. Would it be 
better to add this reference to the ELP? Thanks!

[Andrew]: Seems sensible to me to define ELP here and disconnect from the IDR 
draft. In the past often PCE/IDR documents often cross reference the protocol 
agnostic documents rather than cross reference each other (I think) and even if 
there’s minor re-statement of definitions should be okay.



- Section 3 wording is a bit clunky to me and 'node segment path' could be 
construed differently. Perhaps an alternative wording of below suggestion?

[Quan]: Your suggested texts will be taken and replace the OLD in next version. 
Thanks!

[Andrew]: ACK



- Section 4.2 and section 4.3 -> This document defined / This document defines.

[Quan]: Thanks for your remind and it will be updated in next version.

[Andrew]: ACK



- Section 4.3 -> the current text seems to interpret that the E position is a 
recommendation(is my interpretation), rather than a 'must insert'. Is that the 
case? In my view it should be a recommendation so perhaps it should include 
some language such as "When E flag is set, the PCC SHOULD insert  after 
this position. When the flag is not set, the PCC SHOULD NOT insert  
after this position" ?   Now, of course as I kept reading it turns out Section 
5 indicates it's a MUST, is MUST too strong? What should happen if it cannot? 
I'm not sure why pcc would not be able to but trying to consider what it should 
do if it cannot?.

 [Quan]: Thanks for your comment. From my understanding , E position is a 
recommendation. To clarify it , would it be better to update the section 4.3 to 
"If this flag is set, the PCC SHOULD insert  into the position after 
this SR-ERO subobject" and update the section 5 to "It indicates that two  pairs SHOULD be inserted into the label stack of the SR-TE forwarding 
entry,   respectively after the label for S3 and label for S6."?

[Andrew] Yep that sounds good to me. Thanks!





- Section 6 briefly indirectly comments on MSD implications and Section 3 
describes that it can/how to learn MSD but I find doesn't bind it with ELI/EL 
position calculation. I think this document should include explicit text 
somewhere that says something such as "When computing the ELI/EL positions the 
PCE MUST take into consideration MSD imposition" ?

 [Quan]: Thanks for your suggestion. Would it be better to remove the second 
sentence in section 6 and add the "When computing the ELI/EL positions the PCE 
MUST take into consideration MSD imposition" in section 3?

[Andrew] I'm not sure if section 6 would be good location for it or not. I see 
that sentence as more of a functional requirement rather than security 
consideration, as it's just a way to nudge the reader "don't forget about this 
__". I'm not against it going to section 6, but feel section 3 would be more 
appropriate.





Best Regards,

Quan
Original
From: AndrewStone(Nokia) 
To: 熊泉00091065;d...@dhruvdhody.com ;
Cc: pce@ietf.org ;pce-cha...@ietf.org 
;draft-peng-pce-entropy-label-posit...@ietf.org 
;
Date: 2024年02月03日 02:30
Subject: Re: WG Adoption of draft-peng-pce-entropy-label-position-10
Hi Authors and WG.

Overall the document reads pretty clear.  Some comments/feedback from doing a 
read through:

- Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? 
 From the read I don't see any other purpose than "this is also ongoing" and 
can likely be removed?

- Section 3 wording is a bit clunky to me and 'node segment path' could be 
construed differently. Perhaps an alternative wording of below suggestion?

OLD

"the ERLD value is important for inserting ELI/EL and the ingress node need to 
evaluate the minimum ERLD value along the node segment path. But it will add 
complexity in the ELI/EL insertion process. Moreover,

Re: [Pce] WG Adoption of draft-peng-pce-entropy-label-position-10

[Andrew Stone (Nokia)]

Hi Authors and WG.

Overall the document reads pretty clear.  Some comments/feedback from doing a 
read through:

- Is there any value in having a reference to draft-ietf-idr-bgp-srmpls-elp-00? 
 From the read I don't see any other purpose than "this is also ongoing" and 
can likely be removed?

- Section 3 wording is a bit clunky to me and 'node segment path' could be 
construed differently. Perhaps an alternative wording of below suggestion?

OLD

"the ERLD value is important for inserting ELI/EL and the ingress node need to 
evaluate the minimum ERLD value along the node segment path. But it will add 
complexity in the ELI/EL insertion process. Moreover, the ingress node cannot 
find the minimum ERLD along the path and does not support the computation of 
the minimum ERLD especially in inter-domain scenarios."

NEW SUGGESTION:

the ELRD value is an important consideration when inserting ELI/EL and the 
minimum ELRD must be evaluated for each node along a computed path. This 
necessary step adds additional complexity in the ELI/EL insertion process and 
it may not be feasible for an ingress router to compute the appropriate ERLD 
for each node in the path, since a SR-MPLS path may contain segments the 
ingress router can resolve such as inter-domain scenarios.


- Section 4.2 and section 4.3 -> This document defined / This document defines.

- Section 4.3 -> the current text seems to interpret that the E position is a 
recommendation(is my interpretation), rather than a 'must insert'. Is that the 
case? In my view it should be a recommendation so perhaps it should include 
some language such as "When E flag is set, the PCC SHOULD insert  after 
this position. When the flag is not set, the PCC SHOULD NOT insert  
after this position" ?   Now, of course as I kept reading it turns out Section 
5 indicates it's a MUST, is MUST too strong? What should happen if it cannot? 
I'm not sure why pcc would not be able to but trying to consider what it should 
do if it cannot?.

- Section 6 briefly indirectly comments on MSD implications and Section 3 
describes that it can/how to learn MSD but I find doesn't bind it with ELI/EL 
position calculation. I think this document should include explicit text 
somewhere that says something such as "When computing the ELI/EL positions the 
PCE MUST take into consideration MSD imposition" ?

Thanks
Andrew

From: "xiong.q...@zte.com.cn" 
Date: Monday, January 29, 2024 at 2:14 AM
To: "d...@dhruvdhody.com" 
Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"draft-peng-pce-entropy-label-posit...@ietf.org" 

Subject: Re: WG Adoption of draft-peng-pce-entropy-label-position-10
Resent-From: 
Resent-To: , , 

Resent-Date: Monday, January 29, 2024 at 2:14 AM

Hi Dhruv and WG,

I support the adoption as co-author.

This draft is useful and reasonable for PCEP extensions to configure the 
entropy label positions in SR-MPLS networks as described in RFC8662.

Thanks,
Quan


Original
From: DhruvDhody 
To: pce@ietf.org ;
Cc: pce-chairs 
;draft-peng-pce-entropy-label-posit...@ietf.org 
;
Date: 2024年01月27日 00:50
Subject: WG Adoption of draft-peng-pce-entropy-label-position-10
Hi WG,

This email begins the WG adoption poll for 
draft-peng-pce-entropy-label-position-10

https://datatracker.ietf.org/doc/draft-peng-pce-entropy-label-position/

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 12th Feb 2024.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien


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

[Pce] IPR poll for draft-peng-pce-entropy-label-position

[Andrew Stone (Nokia)]

Hi Authors,

In preparation for adoption 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] New Version Notification for draft-ietf-pce-segment-routing-policy-cp-13.txt

[Andrew Stone (Nokia)]

Hi Mike,

Thanks for addressing the comments, looks good to me. 

Regarding section 6.5 - is it worth making the text identical to match 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-03#section-8.4
 since I assume the intent is for both of these docs to use the same registry 
under Segment Routing? Naturally makes sense to not define values outside of 
the PCEP scope, however might be worth making sure the descriptions match even 
if they may appear redundant (i.e  code point 1, 10, 20, 30). Comparing the two 
it's also not clear to me what code point value 1 is in IDR vs unassigned in 
PCEP. 

With that said, considering IDR was proposing similar and the origins can be 
common amongst many different protocols, think it makes sense to have the 
registry under Segment Routing. 

Thanks
Andrew


On 2024-01-16, 11:48 PM, "Pce on behalf of Mike Koldychev" 
mailto:pce-boun...@ietf.org> on behalf of 
mkoldych=40proton...@dmarc.ietf.org > wrote:


Hi WG,


I addressed all comments that I received so far (let me know if I missed 
anything).


I copied some text from [I-D.ietf-idr-segment-routing-te-policy] into Section 
5.3, to avoid making a normative reference to that draft. So we should probably 
review it again in more detail.


Also, we need to double check Section 6.5 
(https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp-13#section-6.5
 
),
 to make sure it's a good idea to create the new registry under Segment Routing 
instead of under PCEP.


Thanks,
Mike.


Sent with Proton Mail secure email.


On Tuesday, January 16th, 2024 at 7:48 PM, internet-dra...@ietf.org 
 mailto:internet-dra...@ietf.org>> wrote:


> A new version of Internet-Draft
> draft-ietf-pce-segment-routing-policy-cp-13.txt has been successfully
> submitted by Mike Koldychev and posted to the
> IETF repository.
>
> Name: draft-ietf-pce-segment-routing-policy-cp
> Revision: 13
> Title: PCEP Extensions for SR Policy Candidate Paths
> Date: 2024-01-16
> Group: pce
> Pages: 23
> URL: 
> https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-policy-cp-13.txt
>  
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing-policy-cp/ 
> 
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-policy-cp
>  
> 
> Diff: 
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-segment-routing-policy-cp-13
>  
> 
>
> Abstract:
>
> A Segment Routing (SR) Policy is a non-empty set of SR Candidate
> Paths, which share the same  tuple. SR
>
> Policy is modeled in PCEP as an Association of one or more SR
> Candidate Paths. PCEP extensions are defined to signal additional
> attributes of an SR Policy. The mechanism is applicable to all SR
> forwarding planes (MPLS, SRv6, etc.).
>
>
>
> The IETF Secretariat


___
Pce mailing list
Pce@ietf.org 
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

[Andrew Stone (Nokia)]

Hi Mike,

Using MUST sounds good to me to keep the interop behavior consistent. Agreed, 
especially since there may be an inability to resolve the SID destination (ex: 
bsid, interdomain etc..) that it’s likely best to just force the resolution to 
rely on Endpoint from SRPA.

Thanks
Andrew

From: "Mike Koldychev (mkoldych)" 
Date: Thursday, January 11, 2024 at 12:53 PM
To: "Andrew Stone (Nokia)" , 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 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>" 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>"
 
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] WGLC for draft-ietf-pce-segment-routing-policy-cp-12

[Andrew Stone (Nokia)]

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"



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



From: Dhruv Dhody 
Date: Monday, January 8, 2024 at 5:29 AM
To: "pce@ietf.org" 
Cc: pce-chairs , 
"draft-ietf-pce-segment-routing-policy...@ietf.org" 

Subject: WGLC for draft-ietf-pce-segment-routing-policy-cp-12
Resent-From: 
Resent-To: , , 

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] I-D Action: draft-ietf-pce-state-sync-06.txt

[Andrew Stone (Nokia)]

Hi Cheng, Authors, 

Thanks for this document. It's fairly well written and I found many of the 
questions/thoughts I had were being answered as I kept reading.  Below are some 
comments/feedback/questions. Thanks in advance! 

- It’s likely worth defining the term computation loop as a reader may think 
it's simply PCEs spending time computing paths (or may think it’s routing 
loops), but really it’s message control+computation+path oscillation loops. 
Perhaps a simple sentence such as “The term computation loop used in this 
document describes a behavior of protocol message exchange looping between PCC 
and PCE, resulting in frequent path calculations and path updates to the 
network resulting in constant load on PCE and oscillation of data plane traffic 
after each subsequent update. “

- section 1.3 - RFC9059 is another good example use case that might be worth 
examine the behavior of since diversity covered the various conditions in great 
depth. However, I think the result might be be very similar though so it might 
be worth working through the same example flow (I have not yet..)

- section 1.3 - nice to see scenario 5 was covered as that was a concern I had 
as I started reading.   "both LSPs are configured almost at the same time"  -> 
another example condition for that could be link diverse paths with a common 
node failure detected by each PCE and each PCE naturally independently reroute 
and result on the same link.

- section 2 intro it might be worth remarking in a statement that various 
aspects of RFC8232 are required/used to implement this solution beyond RFC8231. 
For example, LSP-DB-VERSION support is critical, but is only RFC referenced at 
the very end of 3.3 after the its purpose is discussed. May make for an 
easier/more obvious read. 

- section 3.2 - 'SPEAKER-IDENTITY-TLV' term itself is not defined in RFC8232, 
but rather 'Speaker entity identifier TLV' or rather 'SPEAKER-ENTITY-ID' - 
should be changed? 

- section 3.4 "a PCE SHOULD update the LSP state only if the 
ORIGINAL-LSP-DB-VERSION present in the PCRpt is greater than the current 
ORIGINAL-LSP-DB-VERSION of the stored LSP state" - this text seems quite strict 
considering the value may wrap around. As well, RFC8232 doesn't seem to 
indicate LSP-DB-VERSION needs to be persisted for lifetime. What happens if PCC 
reboots and resets back to 1 on next connection? PCE may have kept the LSP 
state as stale during sync and thus no delete actually occurred on PCE1. If 
PCE1 then tries to update PCE2 with this, what should happen?  Not clear to me 
from the text how it would be handled. 

- is PCC open message exchange, carried and sent between PCE and PCE defined 
somewhere in this or other documents? appreciate if you could point me to It as 
I could not find and it’s not clear to me from reading. The reason I ask is 
there may be data in the open used during computation. As a top of head 
example, RFC8664 carries MSD in the open message (yes, and in a metric object). 
If an implementation doesn't carry MSD in the metric object, it could rely on 
the open message, or may need to rely on the open message, for extra 
information to do PCE-init. Can PCE1 forward PCC Open information info to PCE2? 
Similarly information such as capabilities for PCE-INIT would also need to be 
known to help during computation. So if a PCC is currently not connected to 
PCE2, should it be relying on its once-known-in-the-past PCC information or can 
it use the live information it can learn from PCE1? 

- section 3.5 - Want to confirm understanding…. Let's say PCE1, PCE2 and PCE3 
are deployed. PCC is connected to PCE1. PCE2 is highest priority. PCC delegates 
to PCE1, which then sub-delegates to PCE2. PCE3 learns undelegated.   When PCE2 
wants to send a PcUpdate, the text says "it MUST send a PCUpdate message to all 
state-sync sessions and to the PCC session on which it received the 
delegation". Therefore PCE2 MUST send the PcUpdate to PCE1 and PCE3. Emphasis 
here is PCE3. In normal operation PCE3 should ignore. What's the reason to send 
to PCE3? Is it to handle possible inconsistent/out of date synchronization of 
the delegation ownership? 

- section 3.5 paragraph 3 - might be worth adding: "LSPs part of the same 
association group SHOULD be assigned with the same PCE priority".  The last 
paragraph in this section touches on it in an inverse way but it's likely worth 
indicating this directly. 

- section 3.5 last paragraph, perhaps should be a section on it's own  (3.5.1 
?) since it's a specific sub behavior of computation priority of a certain type 
of LSPs rather than the general flow and concept of computation priority? 

- General question – any thought given to bandwidth optimization? Is a PCE with 
capabilities to perform bandwidth optimization out of scope? For example, under 
a split brain scenario, both PCE's may detect congestion a link. Both PCEs may 
attempt to move paths around to deal with this, further creating congestion 

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

[Andrew Stone (Nokia)]

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] Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: (with COMMENT)

[Andrew Stone (Nokia)]

Hi Murray,



Just +1 and acknowledging with the same from Dhruv. The shepherd writeup 
question was if there are any implementation reported somewhere (“or 
elsewhere”) thus figured thorough to reference the mailing list response.



Thanks!

Andrew


From: Dhruv Dhody 
Date: Thursday, January 4, 2024 at 1:12 AM
To: Murray Kucherawy 
Cc: The IESG , "draft-ietf-pce-pceps-tl...@ietf.org" 
, "pce-cha...@ietf.org" 
, "pce@ietf.org" , "Andrew Stone (Nokia)" 

Subject: Re: Murray Kucherawy's No Objection on draft-ietf-pce-pceps-tls13-03: 
(with COMMENT)

Hi Murray,

On Thu, Jan 4, 2024 at 11:30 AM Murray Kucherawy via Datatracker 
mailto:nore...@ietf.org>> wrote:
Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-pceps-tls13-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/



--
COMMENT:
--

Further to Eric's comment, I'm completely confused by question #4 of the
shepherd writeup.  While the document claims there are no implementations
known, the shepherd writeup says there's at least one (and it was easy), and
makes another "Yes" remark that I don't understand.


Dhruv: The shepherd writeup mentions this email response on the mailing list - 
https://mailarchive.ietf.org/arch/msg/pce/dLdcUan2psssBUgzCtXPluEr_ok/ that 
mentions some implementation experience. When we asked to include that 
information in the implementation section we did not get a confirmation back. 
Soo that's that :)

We could update the implementation section to say -

OLD:
   At the time of posting the -02 version of this document, there are no
   known implementations of this mechanism.
NEW:
   At the time of posting the -04 version of this document, there are no
   known implementations of this mechanism. It is believed that one
   vendor has implementation, but these plans are too vague to make
   any further assertions.
END

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

Re: [Pce] WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05

[Andrew Stone (Nokia)]

Hi PCE WG,

Support adoption as coauthor. The extensions provided in the document provide 
needed (interoperable) knobs to complete some use cases defined in the SPRING 
Circuit Style document. While the current goal is CS-SR, the encodings defined 
provide independent functionality that can be applicable to other use cases or 
used individually, including other path setup types thus is another useful tool 
in the toolbox.

Thanks
Andrew

From: Dhruv Dhody 
Date: Friday, December 1, 2023 at 5:33 AM
To: "pce@ietf.org" 
Cc: "draft-sidor-pce-circuit-style-pcep-extensi...@ietf.org" 

Subject: WG Adoption of draft-sidor-pce-circuit-style-pcep-extensions-05
Resent-From: 
Resent-To: , , 
, , 
Resent-Date: Friday, December 1, 2023 at 5:33 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 begins the WG adoption poll for 
draft-sidor-pce-circuit-style-pcep-extensions-05.

https://datatracker.ietf.org/doc/ 
http://draft-sidor-pce-circuit-style-pcep-extensions/

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 15th Dec 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] IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05

[Andrew Stone (Nokia)]

Hi PCE WG

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

Thanks
Andrew

From: Dhruv Dhody 
Date: Friday, December 1, 2023 at 5:41 AM
To: "Samuel Sidor (ssidor)" , "praveen.maheshw...@airtel.com" 
, "Andrew Stone (Nokia)" 
, "luay.ja...@verizon.com" , 
"Pengshuping (Peng Shuping)" 
Cc: "pce@ietf.org" 
Subject: IPR poll for draft-sidor-pce-circuit-style-pcep-extensions-05


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

In preparation for WG adoption on this draft, we'd like all authors 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,
Dhruv
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13

[Andrew Stone (Nokia)]

I've also read the new version and -02 content is more streamlined and looks 
good to me. 

+1 for proceeding on WGLC

Thanks
Andrew




On 2023-11-16, 9:14 AM, "Pce on behalf of Adrian Farrel" mailto:pce-boun...@ietf.org> on behalf of adr...@olddog.co.uk 
> wrote:

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,

I've read the new version of this draft.

I think it is ready for publication, but you have used smart quotes for
the apostrophes in the Abstract and Introduction.

Thanks for all the work.
Adrian


-Original Message-
From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
julien.meu...@orange.com 
Sent: 09 November 2023 17:13
To: pce@ietf.org 
Subject: [Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13


Dear PCE WG,


As suggested by Sean during the WG meeting today, this message starts a
2nd WG last call on draft-ietf-pce-pceps-tls13-02 [1]. Please, express
any comments you have about the latest revision of this document (diff
in [2]) using the PCE mailing list..


This WGLC will end on Friday 24th November 2023.


Thanks,


Julien


--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/ 

[2]
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pceps-tls13-01 

=draft-ietf-pce-pceps-tls13-02=--html




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 




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

[Pce] PCE WG minutes for IETF 118

[Andrew Stone (Nokia)]

Hi WG,

Please find the minutes for PCE WG session 
https://datatracker.ietf.org/meeting/118/materials/minutes-118-pce-202311091400-00

Thanks to those who contributed to the minutes.

Please reach out to pce-cha...@ietf.org in case any 
correction needs to be made.

Thanks,
Dhruv, Julien & Andrew

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

Re: [Pce] Shepherd Review of draft-ietf-pce-pceps-tls13-01

[Andrew Stone (Nokia)]

Hi Russ, WG,

Responses inline below.

Thanks
Andrew

From: Russ Housley 
Date: Wednesday, September 27, 2023 at 11:50 AM
To: "Andrew Stone (Nokia)" 
Cc: "draft-ietf-pce-pceps-tl...@ietf.org" 
, "pce@ietf.org" 
Subject: Re: Shepherd Review of draft-ietf-pce-pceps-tls13-01


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.





On Sep 27, 2023, at 11:02 AM, Andrew Stone (Nokia)  
wrote:

Hi authors of draft-ietf-pce-pceps-tls13,

I’ve been selected as the document shepherd for this draft.

Thank you for the work on this document. The direct references to 
draft-ietf-tls-rfc8446bis sections were useful and the document is well written.

From a quick peak at messages from [1], it seems like WGLC consensus was 
reached on draft-ietf-tls-rfc8446bis + some follow up discussions which appear 
to be resolved(?) thus draft-ietf-tls-rfc8446bis is also pending a Shepherd 
writeup. It seems both documents are in similar same state (?).  Given the size 
and complexity differences I assume draft-ietf-tls-rfc8446bis will progress 
slower than this document (as hinted by editor note in the introduction as 
well), is the plan to still continue with the bis as a normative reference?

Taking into consideration the outstanding review comments [2], [3], some 
additional comments/questions from reading -01:

# From ID NITS:


  *   >Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)

 *   (Considering the use inside the document and what is intended by 
referencing it I believe this is okay, but still wanted to point it out that 
it’s been picked up by the tool)

This reference is correct.

 ACK

# Comments:



  *   Abstract: uses "TLS" abbreviation, should be changed to: "..PCEP messages 
with Transport Layer Security (TLS) 1.2..."


  *   I was similarly unclear as Stephane regarding what does this document 
update for TLS 1.2 on RFC8253, but after going over it a few times, concluded 
this updates RFC8253 by bringing in RFC9325 recommendations and applying it to 
TLS 1.2 in the RFC8253 context. Is that the case? If so, it would be clearer in 
the introduction to make the point that RFC8253 TLS. 1.2 usage is being updated 
with recommendations from RFC5246.

We originally wrote a document that only talked about TLS 1.3, but the WG felt 
that it was better to update RFC 8253 to cover TLS 1.2 and TLS 1.3.

 ACK, Sounds good to me then.



  *   Editor Note in the Introduction should remark also updating appendix 
references in the document if draft-ietf-tls-rfc8446bis normative referenced is 
reduced to RFC8446


  *   Section 3 paragraph 2 – Replace E.5 with F.5 for the bis reference (…not 
use early data without a profile..). E.5 is correct for rfc8446, but is F.5 in 
draft-ietf-tls-rfc8446bis.


  *   Similar question to Stephanes regarding why no reference to RFC8253 in 
the security considerations? is one required and does this actually update 
RFC8253 security considerations? As well, the second paragraph seems like it 
can be removed as all it seems to dop is re-describe what PCE/PCEP is without 
discussing the security considerations or any explicit consideration updates.

Do we want to be blocked on the publication of draft-ietf-tls-rfc8446bis?

 At this moment I suspect not, but would defer this to the WG as a 
whole and the PCE WG chairs.  My own opinion is this doesn’t seem to have an 
explicit requirement on the BIS and happy to see it move forward with the base 
RFC8446 reference. Chairs, WG input?



# Suggestion:


OLD:
Note that TLS 1.3 can be used without early data as per Appendix F.5 of 
[I-D.ietf-tls-rfc8446bis]. In fact, early data is permitted by TLS 1.3 only 
when the client and server share a Pre-Shared Key (PSK), either obtained 
externally or via a previous handshake.

NEW:
TLS 1.3 can be used without early data as per Appendix F.5 of 
[I-D.ietf-tls-rfc8446bis], and allows early data only if both the client and 
server possess a shared Pre-Shared Key (PSK) obtained externally or from a 
previous handshake.

This depends on the answer to blocking on the publication of 
draft-ietf-tls-rfc8446bis.

Russ

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

[Pce] Shepherd Review of draft-ietf-pce-pceps-tls13-01

[Andrew Stone (Nokia)]

Hi authors of draft-ietf-pce-pceps-tls13,

I’ve been selected as the document shepherd for this draft.

Thank you for the work on this document. The direct references to 
draft-ietf-tls-rfc8446bis sections were useful and the document is well written.

From a quick peak at messages from [1], it seems like WGLC consensus was 
reached on draft-ietf-tls-rfc8446bis + some follow up discussions which appear 
to be resolved(?) thus draft-ietf-tls-rfc8446bis is also pending a Shepherd 
writeup. It seems both documents are in similar same state (?).  Given the size 
and complexity differences I assume draft-ietf-tls-rfc8446bis will progress 
slower than this document (as hinted by editor note in the introduction as 
well), is the plan to still continue with the bis as a normative reference?

Taking into consideration the outstanding review comments [2], [3], some 
additional comments/questions from reading -01:

# From ID NITS:


  *   >Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
 *   (Considering the use inside the document and what is intended by 
referencing it I believe this is okay, but still wanted to point it out that 
it’s been picked up by the tool)


# Comments:


  *   Abstract: uses "TLS" abbreviation, should be changed to: "..PCEP messages 
with Transport Layer Security (TLS) 1.2..."


  *   I was similarly unclear as Stephane regarding what does this document 
update for TLS 1.2 on RFC8253, but after going over it a few times, concluded 
this updates RFC8253 by bringing in RFC9325 recommendations and applying it to 
TLS 1.2 in the RFC8253 context. Is that the case? If so, it would be clearer in 
the introduction to make the point that RFC8253 TLS. 1.2 usage is being updated 
with recommendations from RFC5246.



  *   Editor Note in the Introduction should remark also updating appendix 
references in the document if draft-ietf-tls-rfc8446bis normative referenced is 
reduced to RFC8446



  *   Section 3 paragraph 2 – Replace E.5 with F.5 for the bis reference (…not 
use early data without a profile..). E.5 is correct for rfc8446, but is F.5 in 
draft-ietf-tls-rfc8446bis.


  *   Similar question to Stephanes regarding why no reference to RFC8253 in 
the security considerations? is one required and does this actually update 
RFC8253 security considerations? As well, the second paragraph seems like it 
can be removed as all it seems to dop is re-describe what PCE/PCEP is without 
discussing the security considerations or any explicit consideration updates.


# Suggestion:

OLD:
Note that TLS 1.3 can be used without early data as per Appendix F.5 of 
[I-D.ietf-tls-rfc8446bis]. In fact, early data is permitted by TLS 1.3 only 
when the client and server share a Pre-Shared Key (PSK), either obtained 
externally or via a previous handshake.

NEW:
TLS 1.3 can be used without early data as per Appendix F.5 of 
[I-D.ietf-tls-rfc8446bis], and allows early data only if both the client and 
server possess a shared Pre-Shared Key (PSK) obtained externally or from a 
previous handshake.


Thanks
Andrew


[1] https://mailarchive.ietf.org/arch/browse/tls/?q=draft-ietf-tls-rfc8446bis
[2] https://mailarchive.ietf.org/arch/msg/pce/JmSlc7PT-ms120LXfrldyenG7Bc/
[3] https://mailarchive.ietf.org/arch/msg/pce/SCyLmChul8v27cf-C7EdwNqxfoQ/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] IPR poll for draft-chen-pce-bier-11

[Andrew Stone (Nokia)]

Hi Authors,

In preparation for WG adoption 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] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

[Andrew Stone (Nokia)]

Hi all / PCE WG

Some thoughts …

In general I think it should be up to local PCE policy/implementation to 
determine if the 'best' path is one which prefers intra or inter domain paths. 
This goes for Flex Algo related or non-Flex Algo computations. It would be up 
to and dependent on PCE implementation for strictly respecting area/domain 
boundaries vs just a flat graph finding by shortest metric or a hybrid 
in-between (assuming not H-PCE..). Other questions start to pop up such as 
permitting path out of a domain and back into it etc.   Of course, when 
computing and using Flex Algo SIDs, PCE needs to do so with respect to the 
winning FAD in the IGP.

Objective from FAD + Metric Domain Count as a bound of 1 + 
draft-ietf-pce-stateful-pce-optional would seem a reasonable way to signal 
prefer intra-domain.

Do we need to introduce text explicitly in the ietf-pce-sid-algo document for 
this topic? Currently don’t believe so.  Agreed, mechanics of interdomain 
discussion is going to create more complexity in ietf-pce-sid-algo. Even though 
I suspect an interdomain section is inevitably needed in ietf-pce-sid-algo (I 
currently have no specifics points in mind), I think the topic of intra vs 
inter preference is applicable outside of just the flex algo scope therefore 
likely not an ideal document to discuss it in.

Thanks
Andrew


From: Pce  on behalf of Dhruv Dhody 
Date: Tuesday, September 19, 2023 at 6:58 AM
To: "Samuel Sidor (ssidor)" 
Cc: "pce@ietf.org" 
Subject: Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain


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

I stand corrected, how did i forget the long debate on metric-type and FAD :)
What I wanted to convey was if you need to signal this, do look for mechanisms 
that already exist!

Thanks!
Dhruv

On Tue, Sep 19, 2023 at 12:59 PM Samuel Sidor (ssidor) 
mailto:40cisco@dmarc.ietf.org>> wrote:
Hi Dhruv,

In case of path-computation done by PCE based on content of FAD (probably vast 
majority of cases), optimization metric will be specified in FAD, so it will 
not be possible to optimize based on other metric type on top of that.

For original question:

I agree with PSF – it would be probably too complex to try to define such 
behavior in the draft. On top of that, such requirement can potentially come 
for non-Flex-algo paths as well.

I can still imagine achieving something like that for example with 2 
candidate-paths:

  *   1st CP (preferred) which will be limited to intra-domain paths using some 
constraints
  *   2nd CP which will not have any restrictions and which can be used in case 
of no intra-domain path

That can be achieved with metric bound of metric pointed out by Dhruv, 
affinity,… set for 1st CP. Theoretically same thing can be achieved by setting 
MSD bound in 1st CP as with Flex-algo path-computation will probably result in 
just one SID anyway (Flex-algo SID of destination) – at least if other 
constraints are not applied on top of that.

Regards,
Samuel

From: Pce mailto:pce-boun...@ietf.org>> On Behalf Of 
Dhruv Dhody
Sent: Tuesday, September 19, 2023 5:48 AM
To: peng.sha...@zte.com.cn
Cc: pce@ietf.org
Subject: Re: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain

Hi Marcel, PSF,

Speaking as a WG participant...

Note that we do have a metric type "T=20: Domain Count metric (number of 
domains crossed)."; we can simply use this metric type, asking the PCE to 
optimize based on this which should lead to preferring intra-domain paths. See 
https://www.rfc-editor.org/rfc/rfc8685.html#section-3.5

Thanks!
Dhruv

On Tue, Sep 19, 2023 at 9:04 AM 
mailto:peng.sha...@zte.com.cn>> wrote:



Hi Marcel,



May it be a local policy of PCE ?

For a given  that belongs to the same domain, it may be

the default policy for PCE to calculate a candidate path intra domain.

Otherwise, it may bring unnecessary complexity. For example, for a real 
inter-domain

path requirement of  that belongs to the different 
domain,

the intention is to split the path calculation requirements into multiple 
domains, e.g,

 for domain 1,  for domain 2, etc. Now, in this 
case,

does  itself again get a inter-domain path ? In theory, yes. 
But in

reality, it doesn't make sense.



Regards,

PSF


Original
From: MarcelReuter(External) 
mailto:marcel.reuter.exter...@telefonica.com>>
To: pce@ietf.org mailto:pce@ietf.org>>;
Date: 2023年09月15日 16:25
Subject: [Pce] [PCE]: Draft-ietf-pce-sid-algo: Prefer Intra vs Inter-domain
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Aloha,
Dear colleagues,

I have a question regarding the PCE with SR Flex-algo and multiple IGP domains.

In my understanding in each IGP Domain the Flex-Algo is 

[Pce] IPR poll for draft-ietf-pce-pceps-tls13

[Andrew Stone (Nokia)]

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] New Version Notification for draft-ietf-pce-stateful-pce-vendor-01.txt

[Andrew Stone (Nokia)]

Looks good to me, resolves the question I raised. 

Thanks
Andrew



On 2023-08-08, 2:51 AM, "Cheng Li" mailto:c...@huawei.com> 
>> wrote:

Hi Andrew and Aijun,

The draft has been updated to address your comments received in the WG adoption 
call.
Please check if it works for you.

Thanks,
Li Cheng






-Original Message-
From: internet-dra...@ietf.org  
> 
mailto:internet-dra...@ietf.org> 
>> 
Sent: Tuesday, August 8, 2023 2:49 PM
To: Cheng Li mailto:c...@huawei.com> >>; Zhenghaomian mailto:zhenghaom...@huawei.com> >>; Samuel Sidor mailto:ssi...@cisco.com> >>; 
Siva Sivabalan mailto:msiva...@gmail.com> 
>>; Zafar Ali 
mailto:z...@cisco.com> >>
Subject: New Version Notification for draft-ietf-pce-stateful-pce-vendor-01.txt

A new version of I-D, draft-ietf-pce-stateful-pce-vendor-01.txt
has been successfully submitted by Cheng Li and posted to the IETF repository.

Name: draft-ietf-pce-stateful-pce-vendor
Revision: 01
Title: Conveying Vendor-Specific Information in the Path Computation Element 
(PCE) Communication Protocol (PCEP) extensions for Stateful PCE.
Document date: 2023-08-07
Group: pce
Pages: 12
URL: https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-01.txt 
 
 

Status: https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-vendor/ 
 
 

Html: 
https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-01.html 
 
 

Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-pce-vendor 
 
 

Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-stateful-pce-vendor-01 

 

 


Abstract:
A Stateful Path Computation Element (PCE) maintains information on
the current network state, including computed Label Switched Path
(LSPs), reserved resources within the network, and the pending path
computation requests. This information may then be considered when
computing new traffic engineered LSPs, and for the associated and the
dependent LSPs, received from a Path Computation Client (PCC).

RFC 7470 defines a facility to carry vendor-specific information in
stateless Path Computation Element Communication Protocol (PCEP).

This document extends this capability for the Stateful PCEP messages.

The IETF Secretariat



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

[Pce] PCE WG minutes for IETF 117

[Andrew Stone (Nokia)]

Hi WG,

Please find the minutes for PCE WG session 
https://datatracker.ietf.org/doc/minutes-117-pce-202307242230/

Thanks to those who contributed to the minutes.

Please reach out to pce-cha...@ietf.org in case any 
correction needs to be made.

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

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

[Andrew Stone (Nokia)]

Looks good to me!

Thanks
Andrew


From: Dhruv Dhody 
Sent: Tuesday, June 27, 2023 11:31 PM
To: Andrew Stone (Nokia) 
Cc: julien.meu...@orange.com ; pce@ietf.org 

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


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Hi Andrew, Authors,

On Wed, Jun 28, 2023 at 8:08 AM Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>> wrote:
Hi PCE WG,

Read the document and support adoption. The document is clear and relatively 
straight forward to follow and the use case does fill a hole within the 
stateful toolset.

One non-blocking question:

- In version 16, section 5.1, the final sentence is "This information can be 
used in Stateful PCEP messages as well" - it's not clear to me what this 
sentence is trying to be describe. The base reference in RFC7470 section 6.1 
essentially just indicates to provide config knobs. What is meant by "THIS" 
information can be "used" in stateful pcep messages "as well"?


Good point. I also dont see it adding any value too. How about this change -

OLD:

5.1.  Control of Function and Policy

   As stated in [RFC7470], this capability, the associated vendor-
   specific information, and policy SHOULD be made configurable.  This
   information can be used in Stateful PCEP messages as well.

NEW:

5.1.  Control of Function and Policy

   The requirements for control of function and policy for vendor-specific
   information as set out in [RFC7470] continues to apply to Stateful PCEP
   extensions specified in this document.

END

Thanks!
Dhruv (no-hats)

Thanks
Andrew



On 2023-06-20, 3:46 AM, "Pce on behalf of 
julien.meu...@orange.com<mailto:julien.meu...@orange.com> 
<mailto:julien.meu...@orange.com<mailto:julien.meu...@orange.com>>" 
mailto:pce-boun...@ietf.org> 
<mailto:pce-boun...@ietf.org<mailto:pce-boun...@ietf.org>> on behalf of 
julien.meu...@orange.com<mailto:julien.meu...@orange.com> 
<mailto:julien.meu...@orange.com<mailto:julien.meu...@orange.com>>> wrote:

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext<http://nok.it/ext> for 
additional information.

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



___
Pce mailing list
Pce@ietf.org<mailto: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] Adoption Poll for draft-dhody-pce-stateful-pce-vendor

[Andrew Stone (Nokia)]

Hi PCE WG,

Read the document and support adoption. The document is clear and relatively 
straight forward to follow and the use case does fill a hole within the 
stateful toolset. 

One non-blocking question:

- In version 16, section 5.1, the final sentence is "This information can be 
used in Stateful PCEP messages as well" - it's not clear to me what this 
sentence is trying to be describe. The base reference in RFC7470 section 6.1 
essentially just indicates to provide config knobs. What is meant by "THIS" 
information can be "used" in stateful pcep messages "as well"? 

Thanks
Andrew



On 2023-06-20, 3:46 AM, "Pce on behalf of julien.meu...@orange.com 
" mailto:pce-boun...@ietf.org> on behalf of julien.meu...@orange.com 
> wrote:

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 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] Proposed PCE WG Charter update

[Andrew Stone (Nokia)]

Hi PCE chairs,

Recharter changes look good to me.  The update looks needed considering the 
prevalence of all things SPRING related.

Thanks
Andrew

From: Pce  on behalf of Dhruv Dhody 
Date: Wednesday, June 21, 2023 at 1:38 AM
To: "pce@ietf.org" 
Subject: [Pce] Proposed PCE WG Charter update


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,

The PCE WG charter (-07) was last updated in 2014. Your chairs and AD discussed 
the need to bring the charter up to date. We have made a proposed small update 
(-08) and placed it in our WG's Github - https://github.com/ietf-wg-pce/charter

A diff of the changes can be seen at - 
https://author-tools.ietf.org/iddiff?url1=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-07.txt=--html=https://raw.githubusercontent.com/ietf-wg-pce/charter/main/charter-ietf-pce-08.txt

We request the WG to review the proposed charter update. We suggest using the 
mailing list for discussion and proposing substantial changes. Minor edits may 
also be suggested via PR directly on the GitHub.

Please provide all your comments before 5th July. We would then forward the 
request to our AD.

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

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-local-protection-enforcement-10: (with COMMENT)

[Andrew Stone (Nokia)]

Hi Eric,

Thank you for the review. New revision posted regarding the nits. Regarding 
your comments:

- Regarding BCP14 terms: that was changed in revision 10 [1] to address AD 
review and discussion in [2]. John had some good rationale on the english 
explanation against the intent of the wording (comment 2 in [2]) :) 

- Regarding Boolean bit - yes a little redundant :) the intent was to try and 
emphasise the need to go from a true/false definition to one of many / 
enumerated. 

[1] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-local-protection-enforcement-09=draft-ietf-pce-local-protection-enforcement-10=--html

[2] https://mailarchive.ietf.org/arch/msg/pce/LZFULU-rBrXXxC9HpcuHhYQatqA/


Thanks
Andrew


On 2023-06-20, 8:52 AM, "Éric Vyncke via Datatracker" mailto:nore...@ietf.org>> wrote:

Éric Vyncke has entered the following ballot position for
draft-ietf-pce-local-protection-enforcement-10: No Objection


When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 

for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/ 




--
COMMENT:
--


# Éric Vyncke, INT AD, comments for
draft-ietf-pce-local-protection-enforcement-10


Thank you for the work put into this document.


Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and one nit.


Special thanks to Julien Meuric for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.


I hope that this review helps to improve the document,


Regards,


-éric


# COMMENTS


As noted by Jim Guichard, id-nits exhibits some issues that should be fixed
before publication.


## Section 3


Is there a reason why PROTECTION MANDATORY uses BCP14 uppercase terms while
PROTECTION PREFERRED uses a lower case "should" ? Especially because in section
5, "SHOULD" and "MAY" are used.


# NITS


## Section 4.2


Isn't "boolean bit" a little redundant ?









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

Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-local-protection-enforcement-10: (with DISCUSS and COMMENT)

[Andrew Stone (Nokia)]

Hi Roman and all,

Thanks again for the review. Version 11 posted to address below and Jim's 
review. 

https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-local-protection-enforcement-10=draft-ietf-pce-local-protection-enforcement-11=--html

Andrew



On 2023-06-23, 9:18 AM, "Roman Danyliw" mailto:r...@cert.org>> 
wrote:

Hi Andrew!

This text suggested below addresses the feedback in my DISCUSS position.

Thanks,
Roman


> -Original Message-----
> From: Andrew Stone (Nokia)  <mailto:andrew.st...@nokia.com>>
> Sent: Thursday, June 22, 2023 1:51 PM
> To: Roman Danyliw mailto:r...@cert.org>>; The IESG 
> mailto:i...@ietf.org>>
> Cc: draft-ietf-pce-local-protection-enforcem...@ietf.org 
> <mailto:draft-ietf-pce-local-protection-enforcem...@ietf.org>; 
> pce-cha...@ietf.org <mailto:pce-cha...@ietf.org>;
> pce@ietf.org <mailto:pce@ietf.org>; julien.meu...@orange.com 
> <mailto:julien.meu...@orange.com>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-pce-local-protection-
> enforcement-10: (with DISCUSS and COMMENT)
>
> Hi Roman,
>
> Thank you for the review.
>
> Regarding the 3 text statements, thank you for catching that and can see how
> it looks inconsistent. Dhruv has kindly suggested the following text changes 
> to
> help the text be more consistent (Thanks again Dhruv!). If you agree this 
> helps
> clear the conflict, I'll submit the change in the next revision.
>
>
> OLD:
> * E Flag (Protection Enforcement): This flag controls the strictness
> in which the PCE must apply the L flag. When set to 1, the value
> of the L flag MUST be respected during resource selection by the
> PCE. When E flag is set to 0, the value of the L flag SHOULD be
> respected as selection criteria; however, the PCE is permitted to
> relax or ignore the L flag when computing a path. The statements
> below indicate preference when E flag is set to 0 in combination
> with the L flag value.
> NEW:
> * E Flag (Protection Enforcement): This flag controls the strictness
> in which the PCE must apply the L flag. When set to 1, the value
> of the L flag needs to be respected during resource selection by the
> PCE. When E flag is set to 0, an attempt to respect the value of the
> L flag is made; however, the PCE could relax or ignore the L flag when
> computing a path. The statements below indicate preference when the E
> flag is set to 0 in combination with the L flag value.
> END
>
>
> Regarding "respecting" vs "considering," the use of "respecting" was intended
> to indicate that PCE should adhere to the user's request ('respect the law') 
> but
> permitted to breaking it when E=0. On the other hand, the term "considering"
> is used in the context of how PCE should interpret the meaning of the bit 
> flags
> in relation to the definition terms.
>
> The nits will also be corrected within next revision. [
> https://mailarchive.ietf.org/arch/msg/pce/KZIGUYK1D2lPPgD8HLITczgCKaw/ 
> <https://mailarchive.ietf.org/arch/msg/pce/KZIGUYK1D2lPPgD8HLITczgCKaw/> ]
>
> Thanks
> Andrew
>
>
>
>
> On 2023-06-21, 10:39 AM, "Roman Danyliw via Datatracker"
> mailto:nore...@ietf.org> <mailto:nore...@ietf.org 
> <mailto:nore...@ietf.org>>> wrote:
>
>
> Roman Danyliw has entered the following ballot position for
> draft-ietf-pce-local-protection-enforcement-10: Discuss
>
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling- 
> <https://www.ietf.org/about/groups/iesg/statements/handling->
> ballot-positions/
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot- 
> <https://www.ietf.org/about/groups/iesg/statements/handling-ballot->
> positions/>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/ 
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/>
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/>
>  
> <https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/;>
>
>
>
>
>
>
> --
> DISCUSS:
> --
>
>
> ** Section 5. There is seeming

Re: [Pce] Roman Danyliw's Discuss on draft-ietf-pce-local-protection-enforcement-10: (with DISCUSS and COMMENT)

[Andrew Stone (Nokia)]

Hi Roman, 

Thank you for the review. 

Regarding the 3 text statements, thank you for catching that and can see how it 
looks inconsistent. Dhruv has kindly suggested the following text changes to 
help the text be more consistent (Thanks again Dhruv!). If you agree this helps 
clear the conflict, I'll submit the change in the next revision. 


OLD:
   *  E Flag (Protection Enforcement): This flag controls the strictness
  in which the PCE must apply the L flag.  When set to 1, the value
  of the L flag MUST be respected during resource selection by the
  PCE.  When E flag is set to 0, the value of the L flag SHOULD be
  respected as selection criteria; however, the PCE is permitted to
  relax or ignore the L flag when computing a path.  The statements
  below indicate preference when E flag is set to 0 in combination
  with the L flag value.
NEW:
   *  E Flag (Protection Enforcement): This flag controls the strictness
  in which the PCE must apply the L flag.  When set to 1, the value
  of the L flag needs to be respected during resource selection by the
  PCE.  When E flag is set to 0, an attempt to respect the value of the 
  L flag is made; however, the PCE could relax or ignore the L flag when 
  computing a path.  The statements below indicate preference when the E 
  flag is set to 0 in combination with the L flag value.
END


Regarding "respecting" vs "considering," the use of "respecting" was intended 
to indicate that PCE should adhere to the user's request ('respect the law') 
but permitted to breaking it when E=0. On the other hand, the term 
"considering" is used in the context of how PCE should interpret the meaning of 
the bit flags in relation to the definition terms.

The nits will also be corrected within next revision. [ 
https://mailarchive.ietf.org/arch/msg/pce/KZIGUYK1D2lPPgD8HLITczgCKaw/ ]

Thanks
Andrew




On 2023-06-21, 10:39 AM, "Roman Danyliw via Datatracker" mailto:nore...@ietf.org>> wrote:


Roman Danyliw has entered the following ballot position for
draft-ietf-pce-local-protection-enforcement-10: Discuss


When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)




Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 

for more information about how to handle DISCUSS and COMMENT positions.




The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-local-protection-enforcement/ 







--
DISCUSS:
--


** Section 5. There is seemingly conflicting guidance on the interpreting the
E and L flag.


Statement #1
When E flag is set to 0, the value of the L flag SHOULD be
respected as selection criteria;


Statement #2
When the L flag is set to 1 and the E flag is set to 0, then the PCE
MUST consider the protection eligibility as a PROTECTION PREFERRED
constraint.


Statement #3
When L flag is set to 0 and E flag is set to 1, then the PCE MUST
consider the protection eligibility as an UNPROTECTED MANDATORY
constraint.


-- The Statement #1 appears to be weaker (SHOULD) than Statement #2 and 3.


-- What is the difference between “respecting [something] in the selection
criteria” and “consider[ing] the protection eligibility”?




--
COMMENT:
--


Thank you to Rifaat Shekh-Yusef for the SECDIR review.


** Abstract. This document updates RFC5440 but does not explicitly say that in 
this section.


** Section 7.
Securing the PCEP session using Transport Layer Security (TLS)
[RFC8253], as per the recommendations and best current practices in
[RFC7525] is RECOMMENDED.


RFC7525 has been replaced by RFC9325.









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

Re: [Pce] Jim Guichard's No Objection on draft-ietf-pce-local-protection-enforcement-10: (with COMMENT)

[Andrew Stone (Nokia)]

Hi Jim,

Thank you for the review. I've made the following changes locally and will be 
pushing with the next revision:

- Updated abstract to remark document updates RFC5440.
- Changed RFC7525 reference to RFC9325.
- Fixed the non-ascii text. 

New nits result: Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 
comment (--).

Regarding reference to work pre-RFC5378, too be honest I'm having difficulty 
navigating through (https://trustee.ietf.org/license-info) and the related TLP 
to determine what would constitute requiring a disclaimer. In general I agree 
with John in that there isn't substantial material directly from RFC5440, 
beyond the one sentence reference quote in section 4.1.

Thanks
Andrew



On 2023-06-19, 3:03 PM, "John Scudder" mailto:j...@juniper.net>> wrote:

Thanks for the review, Jim. Regarding the warning about pre-RFC5378 work, I 
think it might not apply in this case, since AFAICT there isn’t substantial 
material from RFC 5440 incorporated into the present document. But of course, 
the authors should consider this and make their own determination.


The other two nits should be fixed, I’m sorry I didn’t catch these in my own 
review.


—John


> On Jun 19, 2023, at 10:42 AM, Jim Guichard via Datatracker  > wrote:
...
> --
> COMMENT:
> --
>
> === Comments ===
>
> - from idnits -> The draft header indicates that this document updates 
> RFC5440,
> but the abstract doesn't seem to mention this, which it should.
>
> - from idnits - the authors should check the miscellaneous warnings, 
> especially
> paying attention to the comments re: RFC 5378. I do not see anything in the
> shepherd write-up about this.
>
> - Section 9 - Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325)







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

Re: [Pce] Secdir last call review of draft-ietf-pce-local-protection-enforcement-10

[Andrew Stone (Nokia)]

Hi Rifaat,

Thank you for the review!

Andrew

On 2023-06-18, 12:31 PM, "Rifaat Shekh-Yusef via Datatracker" 
mailto:nore...@ietf.org>> wrote:




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.






Reviewer: Rifaat Shekh-Yusef
Review result: Ready


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.


The summary of the review is Ready




The document clarifies the usage of an existing flag, and adds new flag
that fine-tunes the interpretation of the original flag. the document does
not introduce any new security concerns.











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

Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-09

[Andrew Stone (Nokia)]

Thanks again!-10 is posted. 
https://datatracker.ietf.org/doc/html/draft-ietf-pce-local-protection-enforcement-10



On 2023-05-18, 7:29 PM, "John Scudder" mailto:j...@juniper.net>> wrote:

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.

> On May 18, 2023, at 6:51 PM, Andrew Stone (Nokia)  <mailto:andrew.st...@nokia.com>> wrote:
>
> To the PCE WG:
>
> Any preference regarding changing the capitalization text? i.e from 
> PROTECTION MANADATORY to Protection Mandatory? The intent with capitalization 
> was to try and pop out the values in the description text to make it clear to 
> refer back to the terminology section. If this conflicts with RFC 2119 and/or 
> if the WG doesn't have any preferences, we could certainly change to 
> 'Capitalized First Letter'.


To be clear, in my view, it doesn’t actually conflict with RFC 2119. I don’t 
think anyone would raise a blocking position based on the use of all caps, but 
I’m fairly sure there would be some questions raised, the overall gist of which 
would be to suggest ALL CAPS violates POLA [1]. So even if the decision is “we 
want to keep it this way” it’s worthwhile to validate that now since it lets us 
say “the WG considered this question and decided _”.


(But if this is the biggest thing we have to debate that is a good thing. “The 
bike shed should be green!” :-)


> Hi John,
>
> Thank you once again for the review comments. Diff attached, please let me 
> know if this looks okay and I'll upload the new version. ACK/Agreed with your 
> comments. Regarding should/may language, I see what you mean on the literal 
> expansion. Your interpretation is correct that it was intended to say "unless 
> not possible and gaps may be filled". I've changed should/might but do not 
> currently think additional text is needed to dive further, and I've included 
> your suggestion text from the related email thread.


Works for me. I suspect the protected/unprotected preferred definitions may 
come in for some fairly careful scrutiny, so I’m not saying it’s going to be 
the last word on the subject, but I think the text is solid and supportable.


I say ship it, either with the debated ALL CAPS or not; this can always be 
revised later as needed based on the outcome of any further discussion. Once 
you’ve uploaded it, I’ll request IETF Last Call.


—John


[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment 
<https://en.wikipedia.org/wiki/Principle_of_least_astonishment>



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

Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-09

[Andrew Stone (Nokia)]

To the PCE WG: 

Any preference regarding changing the capitalization text? i.e from PROTECTION 
MANADATORY to Protection Mandatory? The intent with capitalization was to try 
and pop out the values in the description text to make it clear to refer back 
to the terminology section. If this conflicts with RFC 2119 and/or if the WG 
doesn't have any preferences, we could certainly change to 'Capitalized First 
Letter'.



Hi John,

Thank you once again for the review comments. Diff attached, please let me know 
if this looks okay and I'll upload the new version. ACK/Agreed with your 
comments. Regarding should/may language, I see what you mean on the literal 
expansion. Your interpretation is correct that it was intended to say "unless 
not possible and gaps may be filled". I've changed should/might but do not 
currently think additional text is needed to dive further, and I've included 
your suggestion text from the related email thread. 

Regarding the PCE 'SHOULD ignore', yes, it coincides with leaving the door open 
for a PCE implementation dealing with legacy nodes. The current intention is 
that PCE doesn't overwrite its own local state for the E flag on the LSP based 
on what the node is echoing back for legacy compatibility, but an 
implementation might want or need to do that using its own knobs. 

Thanks again,
Andrew






On 2023-05-16, 2:28 PM, "John Scudder" mailto:j...@juniper.net>> wrote:

Hi Andrew and all,


Thanks for your replies to my previous review, and for the new version, it 
clears up most of my concerns. In reviewing the changes, I did come upon some 
other things, some of which were introduced in 09 and others which were things 
I’d overlooked on my first pass. I’m sorry not to have gotten these the first 
time through, but better late than never.


Once we’ve closed on these points [*] I think we’ll be ready for IETF Last Call.


Thanks,


—John


[*] Keeping in mind that “we’ve considered your input but decided to keep the 
text as written” is usually a way to resolve any given point. :-)


--- draft-ietf-pce-local-protection-enforcement-09.txt 2023-05-15 
20:21:43.0 -0400
+++ draft-ietf-pce-local-protection-enforcement-09-jgs-comments.txt 2023-05-16 
14:19:03.0 -0400
@@ -130,6 +130,9 @@
PCEP Extensions for Segment Routing ([RFC8664]) extends support in
PCEP for Segment Routed paths. The path list is encoded with Segment
Identifiers, each of which offer local protection. The PCE may
+---
+jgs: Should that be "each of which might offer"?
+---
discover the protection eligibility for a Segment Identifier (SID)
via BGP-LS [RFC9085] and take the protection into consideration as a
path constraint.
@@ -156,6 +159,17 @@
3. Terminology


This document uses the following terminology:
+---
+jgs: While I don't insist, I think the document will have a smoother
+approval path if the terms below were not rendered in ALL CAPS. If the
+WG feels that ALL CAPS is necessary or preferable, so be it, I'll take
+it forward that way -- I don't have a strong preference about this
+myself, but I know for certain that some reviewers will see it as
+unnecessarily confusing vs. RFC 2119 keywords.
+
+Another option would be to use initial caps as many specs do with terms
+they define, e.g. "Protection Mandatory", "Unprotected Mandatory", etc.
+---


PROTECTION MANDATORY: The Path MUST have protection eligibility on
all links.
@@ -173,10 +187,59 @@
PROTECTION PREFERRED: The Path SHOULD have protection eligibility on
all links but MAY contain links which do not have protection
eligibility.
+---
+jgs: I'm sorry to not have raised this in my first round of review, but
+I just noticed it. It's clear to me what your intent is (or, what I
+think it is!), which is probably why I didn't pick up on this earlier,
+but I think if subjected to a close reading of the RFC 2119 definitions
+of SHOULD and MAY this doesn't work right.
+
+Let's recall how SHOULD and MAY are defined in RFC 2119:
+
+```
+3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
+ may exist valid reasons in particular circumstances to ignore a
+ particular item, but the full implications must be understood and
+ carefully weighed before choosing a different course.
+
+5. MAY This word, or the adjective "OPTIONAL", mean that an item is
+ truly optional. One vendor may choose to include the item because a
+ particular marketplace requires it or because the vendor feels that
+ it enhances the product while another vendor may omit the same item.
+ An implementation which does not include a particular option MUST be
+ prepared to interoperate with another implementation which does
+ include the option, though perhaps with reduced functionality. In the
+ same vein an implementation which does include a particular option
+ MUST be prepared to interoperate with another implementation which
+ does not include the option (except, of course, for the feature the
+ option provides.)
+```
+
+So if we did a "macro expansion" of your 

Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-08

[Andrew Stone (Nokia)]

Hi John, PCE WG

New version -09 has been posted [1]. Hopefully this helps clear up the 
discussion comments below.

Summary:

- Reduced the verbosity in the introduction regarding segment routing background
- Added comment regarding control/data plane applicability and prefixed SR 
specific comments
- Moved preferred content from section 5 to section 4 and consolidated the 
wording with 'do not care'
- Various nits that were caught in review

Thanks again for the review! 
Andrew

[1] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-local-protection-enforcement-08=draft-ietf-pce-local-protection-enforcement-09=--html



On 2023-04-24, 7:13 PM, "Andrew Stone (Nokia)" mailto:andrew.st...@nokia.com>> wrote:


Hi John,


Thank you very much for the review and including the inline diff, made it 
easier to follow. 


Good observation and point about it being technology-agnostic. It was motivated 
by SR, but as you point out the E+F flags descriptions and behavior 
clarifications may be applicable outside of SR in ways I'm unaware of or don't 
exist yet. The introduction was intended to build context in the purpose of the 
draft, not necessarily a tutorial on SR, but I can see how it may be a bit 
heavy for that purpose. Considering these two observations perhaps the SR 
specific discussions from the introduction would be better to move to section 
4.2, and the introduction include statements about technology applicability? 
And where applicable, the use of 'SID' outside of that section can be amended 
where applicable? There are some recommendation text embedded in the document 
that should be kept (ex: 5.2: .It is RECOMMENDED . assume a Node SID is 
protected ...RECOMMENDED ... assume an Adjacency SID is protected if the backup 
flag advertised ). Perhaps those can be pre-ambled with "If the technology 
is SR then ..." ? Do you think this would help clarify what portions are 
agnostic vs SR specific?


Further replies in-line below with >>>>>>[Andrew]. >>>> blocks. 


Will adopt your editorial changes and address discussions for a new revision 
soon. 


Thanks again,
Andrew










On 2023-04-20, 3:35 PM, "John Scudder" mailto:j...@juniper.net> <mailto:j...@juniper.net <mailto:j...@juniper.net>>> 
wrote:
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 Authors, WG,


Thanks for this spec. I can see the need to clear up this ambiguity.




I’ve supplied most of my questions and comments in the form of an edited copy 
of the draft. Minor editorial suggestions I’ve made in place without further 
comment, most of my more substantive questions and comments are done in-line 
and prefixed with “jgs:”. You can use your favorite diff tool to review them; 
I’ve attached the iddiff output for your convenience if you’d like to use it. 
I’ve also pasted a traditional diff below in case you want to use it for 
in-line reply.




In addition to my various inline comments, I have a general question/comment. 
The spec, as far as I can tell, is technology-agnostic: it introduces the E 
flag and codifies the interpretation of the E+L flags. It doesn’t restrict this 
to any particular data plane. That seems like the right choice. But, the draft 
also opens with several paragraphs of discussion of Segment Routing in the 
Introduction, and its normative language is SR-specific (search for “SID” in 
the document to see what I mean, SIDs are an SR construct).




Is the applicability of the document intended to be specific to Segment 
Routing? If so I think this needs to be made clearer. Or, if the document is 
NOT intended to be restricted to SR, then revisions are needed everywhere after 
the Introduction where the string ‘SID’ occurs, to make it technology-agnostic. 
(Less importantly, one might also ask why the Introduction needs to contain a 
tutorial on SR.)




Thanks,


—John




--- draft-ietf-pce-local-protection-enforcement-08.txt 2023-04-20 
14:28:28.0 -0400
+++ draft-ietf-pce-local-protection-enforcement-08-jgs-comments.txt 2023-04-20 
15:25:51.0 -0400
@@ -148,15 +148,21 @@
calculated to include other segment identifiers which are not
applicable to having their protection state advertised, as they may
only be locally significant for each router processing the SID, such
- as Node SIDs, it may not be possible for PCE to include the
+ as Node SIDs, it may not be possible for the PCE to include the
protection constraint as part of the path calculation.




- It is desirable for an operator to define the enforcement, or
+ It is desirable for an operator to be able to define the enforcement, or
strictness of the protection requirement when it can be applied.
+---
+jgs: I don't follow what you mean by "... or strictness of the protection
+requirement when it can be applied." I'm getting

Re: [Pce] AD review of draft-ietf-pce-local-protection-enforcement-08

[Andrew Stone (Nokia)]

Hi John,

Thank you very much for the review and including the inline diff, made it 
easier to follow. 

Good observation and point about it being technology-agnostic. It was motivated 
by SR, but as you point out the E+F flags descriptions and behavior 
clarifications may be applicable outside of SR in ways I'm unaware of or don't 
exist yet. The introduction was intended to build context in the purpose of the 
draft, not necessarily a tutorial on SR, but I can see how it may be a bit 
heavy for that purpose. Considering these two observations perhaps the SR 
specific discussions from the introduction would be better to move to section 
4.2, and the introduction include statements about technology applicability? 
And where applicable, the use of 'SID' outside of that section can be amended 
where applicable? There are some recommendation text embedded in the document 
that should be kept (ex: 5.2: .It is RECOMMENDED . assume a Node SID is 
protected ...RECOMMENDED ... assume an Adjacency SID is protected if the backup 
flag advertised ). Perhaps those can be pre-ambled with "If the technology 
is SR then ..." ? Do you think this would help clarify what portions are 
agnostic vs SR specific?

Further replies in-line below with >>[Andrew].  blocks. 

Will adopt your editorial changes and address discussions for a new revision 
soon. 

Thanks again,
Andrew





On 2023-04-20, 3:35 PM, "John Scudder" mailto:j...@juniper.net>> wrote:
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 Authors, WG,

Thanks for this spec. I can see the need to clear up this ambiguity.


I’ve supplied most of my questions and comments in the form of an edited copy 
of the draft. Minor editorial suggestions I’ve made in place without further 
comment, most of my more substantive questions and comments are done in-line 
and prefixed with “jgs:”. You can use your favorite diff tool to review them; 
I’ve attached the iddiff output for your convenience if you’d like to use it. 
I’ve also pasted a traditional diff below in case you want to use it for 
in-line reply.


In addition to my various inline comments, I have a general question/comment. 
The spec, as far as I can tell, is technology-agnostic: it introduces the E 
flag and codifies the interpretation of the E+L flags. It doesn’t restrict this 
to any particular data plane. That seems like the right choice. But, the draft 
also opens with several paragraphs of discussion of Segment Routing in the 
Introduction, and its normative language is SR-specific (search for “SID” in 
the document to see what I mean, SIDs are an SR construct).


Is the applicability of the document intended to be specific to Segment 
Routing? If so I think this needs to be made clearer. Or, if the document is 
NOT intended to be restricted to SR, then revisions are needed everywhere after 
the Introduction where the string ‘SID’ occurs, to make it technology-agnostic. 
(Less importantly, one might also ask why the Introduction needs to contain a 
tutorial on SR.)


Thanks,

—John


--- draft-ietf-pce-local-protection-enforcement-08.txt 2023-04-20 
14:28:28.0 -0400
+++ draft-ietf-pce-local-protection-enforcement-08-jgs-comments.txt 2023-04-20 
15:25:51.0 -0400
@@ -148,15 +148,21 @@
calculated to include other segment identifiers which are not
applicable to having their protection state advertised, as they may
only be locally significant for each router processing the SID, such
- as Node SIDs, it may not be possible for PCE to include the
+ as Node SIDs, it may not be possible for the PCE to include the
protection constraint as part of the path calculation.


- It is desirable for an operator to define the enforcement, or
+ It is desirable for an operator to be able to define the enforcement, or
strictness of the protection requirement when it can be applied.
+---
+jgs: I don't follow what you mean by "... or strictness of the protection
+requirement when it can be applied." I'm getting hung up on the "when it
+can be applied" part. Would it be correct to just delete those words? Or
+if it wouldn't, can you help me understand what work they're doing? Thanks.
+---

 
[Andrew] "When it can be applied" was intended to suggest to a reader that 
there may be scenarios where the PCE is simply unaware whether a given resource 
is protected or not, or may even need to make assumptions on it's protected 
state because the information may not be available (knowledge if Node SID is 
protected by all nodes along the path). It's likely redundant and can be 
removed (PCE can't enforce what it doesn't know). Will adjust.





@@ -286,6 +292,25 @@
the PCE a preference on which SID to select, as the behaviour of the
LSP would differ during a local failure depending on which SID is
selected.
+---
+jgs: I thought this paragraph was going to answer a question I 

Re: [Pce] PCE SID-algo draft extension

[Andrew Stone (Nokia)]

Hi Samuel, ACK – rationale and comparisons sounds reasonable and good to me.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" 
Date: Wednesday, April 5, 2023 at 4:48 AM
To: "Andrew Stone (Nokia)" , "peng.sha...@zte.com.cn" 

Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"slitkows.i...@gmail.com" , "d...@dhruvdhody.com" 

Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Hi Andrew,

My proposal was really to use something like P/I flag from PCEP object. In this 
case, SID-algo constraint is TLV, so there is no way to enforce it using P 
flag), so yes – I meant “permitted to compute and program a path as if LSPA 
never contained the SID Algo TLV”.

If SID-algo constraint is not included, then PCE can use algo SIDs freely (even 
if there is no draft or no SID-algo constraint specified) – e.g. to decrease 
size of label stack. So same thing would apply to L=1. If PCE cannot fully 
satisfy constraint, then it can fallback into “no SID-algo constraint” behavior 
and it can still compute path with algo SIDs if needed, but there is no 
explicit preference to specific algo SIDs or anything like that.

For cases, where for example multi-domain path is needed, where some domains 
have FA support, but some domain does not support that FA, recommended approach 
can be still policy stitching.

I personally consider such approach as consistent with other constraints, which 
we have – e.g. for affinities we also does not have L flag to partially ignore 
it in part of the network, but still consider in other parts. And we have 
“Strict Disjointness” flag in diversity, which almost similar – allowing to 
fallback other disjoint types or non-disjoint path (but still constraint is 
applied to complete path and not only to some hops or some domain). Rules for 
path-computation are already more complex with other constraints (considering 
topology pruning, ASLA constraints, other constraints from PCRpt,…), so 
increasing complexity even more and allowing combination of algos in same 
segment-list, but still preferring some of them can be really too much.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, April 4, 2023 8:58 PM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specifie

Re: [Pce] PCE SID-algo draft extension

[Andrew Stone (Nokia)]

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" 
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" , "peng.sha...@zte.com.cn" 

Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"slitkows.i...@gmail.com" , "d...@dhruvdhody.com" 

Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specified algo, but constraint is not 
enforcing it, so PCE can still compute complete end-to-end path with just algo 
0 SIDs (of included SIDs of specified algo if it is considering it as safe). So 
there are no special requirements from topology pruning or SID filtering for L 
flag.

To me it seems that there would be really too many options/combinations if we 
will keep original definition of that flag and probably not all vendors will 
implement all of them and we will end-up with various interop issues, so would 
need extra capabilities as well to advertise what is supported and what is not.

Thanks,
Samuel

From: Andrew Stone (Nokia) 
Sent: Friday, March 31, 2023 5:18 AM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

Replies inline below with [Andrew]

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Thursday, March 30, 2023 at 8:22 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn<mailto:peng.sha...@zte.com.cn>" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org<mailto:pce@ietf.org>" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Hi Andrew,

Thanks for good comment.

There are really 3 things – optionA, optionB and L flag.

Option A + option B:
Option A cannot be combined with Option B as main difference here is source of 
optimization metric/constraints and topology attributes, which are supposed to 
be used in the path-computation (ASLA vs legacy).

[Andrew] Agreed

Option A + L flag:
I would say that option A can be combined with L flag as you are really doing 
path-computation based on “legacy” constraints specified in PCRpt. That will 
result in some path, which is translated into SID list and algo of those SIDs 
is not that important (if IGP path of those SIDs is congruent with computed 
path).

[Andrew] Agreed. My interpretation for a use case on the original adoption was 
that if PCE is setting up a path, it would be more ideal to set it up following 
a given Algo, so that way any native IGP convergence or protection mechanisms 
will still respect a metric/constraints differing from algo-0, and if you fail 
to resolve a SID list using the algo be permitted to use any SIDs available.

Option B + L flag:
Option B is implicitly restricting

Re: [Pce] PCE SID-algo draft extension

[Andrew Stone (Nokia)]

Hi Samuel,

Replies inline below with [Andrew]

Thanks
Andrew

From: "Samuel Sidor (ssidor)" 
Date: Thursday, March 30, 2023 at 8:22 AM
To: "Andrew Stone (Nokia)" , "peng.sha...@zte.com.cn" 

Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"slitkows.i...@gmail.com" , "d...@dhruvdhody.com" 

Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Hi Andrew,

Thanks for good comment.

There are really 3 things – optionA, optionB and L flag.

Option A + option B:
Option A cannot be combined with Option B as main difference here is source of 
optimization metric/constraints and topology attributes, which are supposed to 
be used in the path-computation (ASLA vs legacy).

[Andrew] Agreed

Option A + L flag:
I would say that option A can be combined with L flag as you are really doing 
path-computation based on “legacy” constraints specified in PCRpt. That will 
result in some path, which is translated into SID list and algo of those SIDs 
is not that important (if IGP path of those SIDs is congruent with computed 
path).

[Andrew] Agreed. My interpretation for a use case on the original adoption was 
that if PCE is setting up a path, it would be more ideal to set it up following 
a given Algo, so that way any native IGP convergence or protection mechanisms 
will still respect a metric/constraints differing from algo-0, and if you fail 
to resolve a SID list using the algo be permitted to use any SIDs available.

Option B + L flag:
Option B is implicitly restricting topology to only nodes/links with 
participation in that FA (PCE need to follow from path-computation what IGP is 
doing for that option). Constraints and metric-type in FAD are defining FA ASLA 
constraints, so even in the path-computation PCE is supposed to use FA ASLA 
link attributes. So if PCE would suddenly need to use links/nodes (if we would 
allow usage of non-FA topology for L=1), which does not advertise those 
attributes, then PCE would have to fallback into legacy (non-ASLA) link 
attributes and resulting path would have for example accumulated metric, which 
is combining ASLA latency of some links with non-ASLA latency of other links 
(it seems to me like mixing apples and oranges as it is not guaranteed that FA 
ASLA metric value for specific link is same as legacy metric value of same 
link). So I tend to say that topology should be restricted even with L=1 with 
option B.

[Andrew] Yes, agree that topology(edges in the graph) should be restricted with 
L=1. Topology must be restricted to links matching the flex algo, and thus any 
path programmed must only be for links within that flex algo, and If a given 
resource violates the FAD it must be pruned. But I do think there’s two sides 
to it, topology filtering vs SID selection to encode the selected the path in a 
given topology. If we take a simplistic case of a FAD with metric Delay without 
any constraints, assuming the entire network supports the Algo, Algo=0 and 
Algo=Delay are one-to-one with a difference of weights, so the concern for 
topological filtering is not as significant – what matters is encoding of the 
intended “best path” (FAD+LspConstraints+Rules imposed on PCE) using SIDs from 
Algo 0 or Algo=Delay.  (Secondary comment about MSD below)

I just described topology which must be used and not SIDs. I can still imagine 
that if L=1 is set, then PCE will use FA topology, but it can still fallback 
into Algo-0 Prefix SIDs (even if I think that there is higher change that adj 
SIDs + FA SIDs will be used) assuming that final computed path will still be 
shortest path of specified ASLA metric and it will satisfy ASLA constraints 
from FAD.

[Andrew] Yep agreed.

Btw for your other example with MSD – I assume that in most of the cases you 
will end up with smaller number of SIDs if you will use FA SIDs (as IGP 
forwarding will be more aligned with intended constraints in PCE 
path-computation) when compared with algo-0 SIDs.

[Andrew] While I generally agree with you, it could still be possible (likely 
outlier scenarios)  where the path constraints and behavior imposed by PCE may 
need to deviate from the Algo shortest path (ex: Delay) significantly enough 
that MSD becomes constraining. This would be more likely to occur with 
combination of factors imposed at PCE, such as de-congestion optimization and 
rules such as Bidirectionality and/or Diversity which by its nature generally 
requires avoiding the shortest path, potentially for each set of LSPs having 
diversity imposed on them.

I’ll think about it a little bit more, L flag is definitely introducing extra 
complexity into both cases, so maybe even dropping that flag may work (PCE can 
still compute path mix of FA and algo0 SIDs even without any constraint, so 
maybe added value of SID-algo 

Re: [Pce] PCE SID-algo draft extension

[Andrew Stone (Nokia)]

Hi Samuel, PCE WG

I think your comparison points cover the differences well. 
Comparing/contrasting the two scenarios and behaviors should probably be in the 
updated document, too.

It does seem a need to signal the different behavior intention in some form or 
another (whether flag or inclusion/exclusion of constructs). Something not 
remarked in (B), is PCE implicitly restricted to using only SIDs found from the 
Flex Algo Tree? Or is it still permitted to use any SID it wants (existing 
draft L=1) if the path is using resources respecting the FAD. As an example, 
Let's say PCE computes a path based on FAD constraints but needs to work around 
constraints defined outside of the algo, such as known planned maintenance or 
other impairments/rules. Due to MSD, maybe it can't encode this path within the 
confines of the Algo specified. However, if it used Algo-0 or another SIDs it 
can encode the path. I would assume this should be permitted, but Is there a 
need to prohibit this and restrict (B) to also use only the SIDs from the same 
algo? I think I’m looking to clarify, if (A) is filtering strictness and (B) 
metric/constraint, is the behavior needed actually A||B, or is it A=true/false, 
B=true/false?

Thanks
Andrew

From: "peng.sha...@zte.com.cn" 
Date: Wednesday, March 29, 2023 at 5:46 AM
To: "ssi...@cisco.com" 
Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"slitkows.i...@gmail.com" , "d...@dhruvdhody.com" 
, "Andrew Stone (Nokia)" 
Subject: Re: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.





Hi Samuel, WG,



Thanks for the effort work to get the consensus about path computation 
according to the content of FAD.

An explicit flag based on the existing SID-algo constraint for the purpose of 
behavior b, seems good to me.



Regards,

PSF




Original
From: SamuelSidor(ssidor) 
To: pce@ietf.org ;'pce-chairs' ;
Cc: slitkows.i...@gmail.com ;'Dhruv Dhody' 
;彭少富10053815;Stone, Andrew (Nokia - CA/Ottawa) 
;
Date: 2023年03月29日 17:10
Subject: RE: [Pce] PCE SID-algo draft extension
Hi all,

Thanks all for discussion, which happened during PCE session and thanks for 
supporting this extension.

I think that we agreed that it is necessary to consider FAD in the 
path-computation on PCE side if SID-algo constraint was specified, but we were 
not able to finish discussion whether there is a need to introduce new flag, 
which will control whether original behavior (SID-algo filtering) or new 
behavior should be used, so re-opening this mail thread to finish that 
discussion.

I would say that there are really at least two usecases/behaviors for SID-algo 
constraint and we need new flag in SID-algorithm constraint to allow PCC to 
pick required behavior.


  1.  SID-filtering - already exists in the draft (valid for all algorithms)

  *   Path-computation should occur on the topology associated with specified 
SID-algo
  *   Computed path can have only SIDs of specified algo value (+ adjacency 
SIDs)
  *   PCE path-computation is done based on metric-type and constraints from 
PCRpt
  *   Flex-algo specific part:

 *   PCE still has to make sure that IGP path of FA SID is congruent with 
computed path

  1.  Path-computation based on FAD (only valid for Flex-algo)

  *   Metric-type and constraints are primarily retrieved from FAD
  *   Path-computation follow IGP Flex-algo path-computation logic

 *   Flex-algo participation, ASLA attributes,...

  *   Metric-type from FAD is overriding metric-type from PCRpt
  *   PCUpdate will use metric-type from FAD
  *   PCC can send metric-type in PCRpt and it does not have to be same as 
metric-type from FAD, but it is recommended to do not advertise any 
optimization metric
  *   Other constraints from PCRpt:

 *   PCE implementation can decide based on flags in PCEP object
 *   It is not recommended to specify constraints in PCRpt, which are 
already specified in FAD
 *   PCE is not supposed to include constraints from FAD in PCUpdate

Description here is slightly different then the proposal presented in original 
slides, but main idea is still same and more details is provided now. Please 
provide any comments.

Thanks,
Samuel

From: Pce  On Behalf Of Samuel Sidor (ssidor)
Sent: Thursday, January 12, 2023 10:12 AM
To: slitkows.i...@gmail.com; 'Dhruv Dhody' 
Cc: pce@ietf.org; 'pce-chairs' 
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Dhruv,

Thanks for feedback. I completely agree – I would like to hear from WG if they 
can see added value in both (or they can specify even other) use-cases – using 
SID-algo constraint just for SID filtering and using it also for specification 
of constraints from FAD (I agree with Stephane here – computation based on in 
FAD seems to be even more important use-case to me and it is not covere

Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

[Andrew Stone (Nokia)]

Hi Pavan, Dhruv, Samuel,

Correct – that text is trying to steer implementors to use unprotected 
preferred but is keeping the option of unprotected mandatory for backwards 
compatibility. 
https://mailarchive.ietf.org/arch/msg/pce/4EX28antvCp_2CY--7RJmCvR-jo/  
discusses it a bit from a different angle (I assume the thread pointer comment 
below is for this thread.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" 
Date: Wednesday, January 11, 2023 at 4:36 AM
To: Dhruv Dhody , Vishnu Pavan Beeram 
, "Andrew Stone (Nokia)" 
Cc: "pce@ietf.org" , 
"draft-ietf-pce-local-protection-enforcem...@ietf.org" 

Subject: RE: [Pce] Question on draft-ietf-pce-local-protection-enforcement

Hi Dhruv, Vishnu,

“I think we can differentiate between an implementation that supports this 
extension - that MUST use UNPROTECTED PREFERRED whereas a legacy implementation 
would handle it as per their understanding of RFC 5440 which could be 
UNPROTECTED PREFERRED or UNPROTECTED MANDATORY.”

Wouldn’t such change break backward compatibility?

Consider that there is vendor, with original behavior L=0 -> unprotected 
mandatory (on both PCC and PCE side) – as Dhruv mentioned, such implementation 
would be completely valid with original L flag definition. Same old PCC will 
connect to new PCE (with draft supported) and suddenly (unexpected) different 
path-computation result is provided, because behavior has changed.

PCE can still have a way to detect that it is talking to legacy PCCs and it can 
fallback to original behavior to do not break backward compatibility.

I’ll keep Andrew to comment as he is main author.

Regards,
Samuel

From: Pce  On Behalf Of Dhruv Dhody
Sent: Wednesday, January 11, 2023 9:29 AM
To: Vishnu Pavan Beeram 
Cc: pce@ietf.org
Subject: Re: [Pce] Question on draft-ietf-pce-local-protection-enforcement

Hi Pavan,


On Wed, Jan 11, 2023 at 12:46 PM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
Dhruv, Hi!

Thanks for the response! Please see inline..

Regards,
-Pavan

On Wed, Jan 11, 2023 at 12:03 PM Dhruv Dhody 
mailto:dhruv.i...@gmail.com>> wrote:
Hi Pavan,

On Wed, Jan 11, 2023 at 11:02 AM Vishnu Pavan Beeram 
mailto:vishnupa...@gmail.com>> wrote:
I would like to get some clarification on the text below (understand that a 
publication request has been made for the draft).

**
From Section 5:

   When L-flag is not set and E-flag is not set then PCE SHOULD consider

   the protection eligibility as UNPROTECTED PREFERRED but MAY consider

   protection eligibility as UNPROTECTED MANDATORY constraint.

   When L-flag is not set and E-flag is set then PCE MUST consider the

   protection eligibility as UNPROTECTED MANDATORY constraint.


**
For the scenario where both the L-flag and the E-flag are not set (first 
statement above), it seems okay to just say
that the "PCE MUST consider the protection eligibility as UNPROTECTED 
PREFERRED". Is there a good reason
for both the "SHOULD (UNPROTECTED PREFERRED)" and "MAY (UNPROTECTED MANDATORY)" 
clauses to
be included here (and keep things ambiguous)?


Dhruv: If I recall correctly (and the authors can confirm that), this was done 
for the sake of backward compatibility. I remember it being discussed on the 
mailing list as well.

[VPB] Thanks for the pointer to the mailing list thread (should have searched 
there first; apologies for re-opening the topic) -- it was useful! However, the 
backwards compatibility section (5.1) seems to be silent about this particular 
scenario.

If a PCEP speaker does not understand this document (and thus ignores the E 
flag) and L flag is set to 0, would behave as per RFC 5440 where the concept of 
enforcement is undefined and some implementation could understand it to be 
handled as UNPROTECTED MANDATORY instead of UNPROTECTED PREFERRED. And the text 
allows for it.

[VPB] I understand that there was ambiguity with how the (presence/absence of 
the) L-flag was interpreted prior to this draft. I was hoping that there would 
be no ambiguity left when this draft is implemented -- but that doesn't seem to 
be the case. Let's say a PCC implementation assumes [L 0, E 0] to mean 
"UNPROTECTED PREFERRED" (SHOULD clause), while the PCE implementation assumes 
it to mean "UNPROTECTED MANDATORY" (MAY clause) -- this may result in no path 
being returned (if only protected SIDs are available on some links along the 
viable paths). Do we need to retain this ambiguity?

Dhruv: You have a point. I think we can differentiate between an implementation 
that supports this extension - that MUST use UNPROTECTED PREFERRED whereas a 
legacy implementation would handle it as per their understanding of RFC 5440 
which could be UNPROTECTED PREFERRED or UNPROTECTED MANDATORY.

Let's see what the authors think about it.

Thanks!
Dhruv



Happy to get additional eyes and confirm if it still makes sense!

Thanks!
Dhruv


Regards,
-Pavan

Re: [Pce] draft-chen-idr-mbinding - BSID terminating node

[Andrew Stone (Nokia)]

Hi Huaimo

Thanks for pointing me to the draft. Not sure how I missed it and the adoption 
call discussion. Indeed, does go into more detail that I was looking for in the 
mbinding document. Recommend having mbinding reference this document since it 
does cover the various solution discussions.

Replied below with [Andrew2].

Thanks
Andrew

From: Huaimo Chen 
Date: Monday, November 21, 2022 at 5:25 PM
To: "Andrew Stone (Nokia)" , "i...@ietf.org" 

Cc: "pce@ietf.org" 
Subject: Re: draft-chen-idr-mbinding - BSID terminating node

Hi Andrew,

Thanks much for your further comments and suggestions.
My responses are inline below with [HC2].

Best Regards,
Huaimo

From: Stone, Andrew (Nokia - CA/Ottawa) 
Sent: Sunday, November 13, 2022 4:01 PM
To: Huaimo Chen ; i...@ietf.org 
Cc: pce@ietf.org 
Subject: Re: draft-chen-idr-mbinding - BSID terminating node


Hi Huaimo,



Thanks for the responses. I've added additional replies below with [Andrew], 
basically just captures what we discussed on the mic at the PCE WG Friday 
session (which took place after the email exchange) - reapplying below for this 
thread.



As discussed in PCE WG session, seems to me there should be a solution document 
discussing the Node Protection for BSIDs and defining what kind of information 
needs to be sent down to the neighboring node independent of protocol encoding. 
Either SPRING or RTGWG seems appropriate. If one doc is already in the works 
discussing this appreciate if you can steer me to it.

[HC2]:  Draft "SR-TE Path Midpoint Restoration" below talks about the 
information about the Node Protection for BSIDs

https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/
[Image removed by 
sender.]<https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/>
draft-hu-spring-segment-routing-proxy-forwarding-20 - SR-TE Path Midpoint 
Restoration - Internet Engineering Task 
Force<https://datatracker.ietf.org/doc/draft-hu-spring-segment-routing-proxy-forwarding/>
Segment Routing Traffic Engineering (SR-TE) supports explicit paths using 
segment lists containing adjacency-SIDs, node-SIDs and binding- SIDs. The 
current SR FRR such as TI-LFA provides fast re-route protection for the failure 
of a node along a SR-TE path by the direct neighbor or say point of local 
repair (PLR) to the failure. However, once the IGP converges, the SR FRR is no 
longer ...
datatracker.ietf.org







Thanks

Andrew



From: Huaimo Chen 
Date: Thursday, November 10, 2022 at 10:41 PM
To: "Stone, Andrew (Nokia - CA/Ottawa)" , 
"i...@ietf.org" 
Cc: "pce@ietf.org" 
Subject: RE: draft-chen-idr-mbinding - BSID terminating node



Hi Andrew,



Thank you very much for your comments.

My responses are inline below with [HC].



Best Regards,

Huaimo

From: Idr  On Behalf Of Stone, Andrew (Nokia - CA/Ottawa)
Sent: Monday, November 7, 2022 6:33 PM
To: i...@ietf.org
Subject: [Idr] draft-chen-idr-mbinding - BSID terminating node



Hi IDR, Authors



Following up with my comment at the mic in the IDR meeting earlier today. The 
below would also apply to the sibling draft in PCE-WG. During the meeting it 
was confirmed the BSID SL is not provided to the neighbor node, however:



[HC]: A BSID is associated with a list of SIDs for a path segment. When BGP 
sends the

BSID with the list of SIDs to a node named N, BGP also sends the BSID with the 
list of SIDs

plus the ID of node N to the neighbors of N.



[Andrew] ACK. Thanks for clarifying the intention. Recommend the document 
clarifying that a SID list is indeed pushed down to the neighbor nodes and not 
just the node id + bsid value.



[HC2]: Will add some text into the document accordingly.





1.   How does a node providing protection, know where the BSID tunnel 
terminates on?



[HC]: If the first SID in the list is a node SID, when node N failed, the 
neighbor node of N will

replace the BSID with the list of SIDs in the packet after the SID for node N 
is removed/popped

and sends the packet  to the first SID in the path segment bond to BSID.



[Andrew] ACK. Will discuss more below….





For example, given the following network path: 
[A]--100--[B]--200--[C]--300--[D]--400--[E]--500--[F]



Where A,B,C,D,E,F are nodes and 100, 200, 300, 400, 500 are local 
adjacency-sids.



BSID 1000 is deployed to node C with SL: 300, 400.



Therefore a headend tunnel is programmed on A with SL: 100, 200, 1000, 500.



As per the draft, we want node protection for node C thus protect BSID 1000. 
When programming its neighbor [B] the document says to only inform node B:  {C, 
1000}



[HC]: If the first SID in the list is an adjacency SID (e.g., adjacency 300 for 
the adjacency from C to D),

when node N (e.g., node C here)  failed, the neighbor node(e.g., node B)  of N 
(e.g., node C) will

get the node SID of next hop node  (i.e., node D) usin