[Pce] PCE WG Agenda for IETF 120

[Dhruv Dhody]

Hi WG,

The **draft** agenda for the PCE WG sessions during IETF 120 is posted -
https://datatracker.ietf.org/doc/agenda-120-pce/

Please unicast us if there is any change needed.

Please note that the allocated time includes time for Q&A.
Please use the mailing list to bring out the key point that you would like
to discuss during the WG session.
Please send your slides (in pdf format) to emails in the CC in advance by
Sunday July 21st.

Useful information for both in-person and online participation can be found
at - https://www.ietf.org/how/meetings/preparation/.
Refresh your knowledge of Meetecho  -
https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/

Thanks!
Dhruv, Julien & Andrew

ICS file to add to your calendar:
https://datatracker.ietf.org/meeting/120/session/33041.ics
___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[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 develop their own PCEs or open source PCEs can know the 
details of 

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

[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

[Samuel Sidor (ssidor)]

Hi Dhruv,

Agreed, let’s skip it. Controlled-ID draft already mentioned state-sync I-D in 
Section 6, so it can also clarify way to exchange controlled ID ranges if 
needed (those will be synchronized automatically as part of “any other TLVs 
encoded in the OPEN object received from the PCC” if decision will be done to 
include them into Open object).

Regards,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 1:43 PM
To: Samuel Sidor (ssidor) 
Cc: Dhruv Dhody ; Andrew Stone (Nokia) 
; draft-ietf-pce-state-s...@ietf.org; 
pce@ietf.org; pce-chairs 
Subject: Re: [Pce] Re: Pending item for draft-ietf-pce-state-sync

Hi Samuel,

On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) 
mailto:ssi...@cisco.com>> wrote:
Hi Andrew, Dhruv,

Proposed text looks fine to me.

Do we also need to consider future result of discussion for controlled ID? E.g. 
if decision will be done to use Notification message for ID space 
advertisement, will we need to synchronize content of those on top of TLVs from 
Open object?


Personally, I consider controlled ID (and PCECC) to be out of scope of the 
state-sync I-D. We can make that explicit in the I-D.
In future another specification can tackle it if there is a need and can use 
the technique that you suggest.

Thanks!
Dhruv

Thanks,
Samuel

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Sent: Tuesday, July 9, 2024 11:18 AM
To: Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>>
Cc: 
draft-ietf-pce-state-s...@ietf.org; 
pce@ietf.org; pce-chairs 
mailto:pce-cha...@ietf.org>>
Subject: [Pce] Re: Pending item for draft-ietf-pce-state-sync

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>> 
wrote:
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.


Dhruv: I suggest adding this here ->

   *  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.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  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.


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


I suggest that this could be a subsection "3.5.1.  Information Received via 
Open Message from PCC"

Thanks!
Dhruv


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 mailto:d...@dhruvdhody.com>>
Date: Saturday, July 6, 2024 at 7:52 AM
To: 
draft-ietf-pce-state-s...@ietf.org 
mailto:draft-ietf-pce-state-s...@ietf.org>>,
 Andrew Stone (Nokia) mailto:andrew.st...@nokia.com>>
Cc: pce@ietf.org mailto:pce@ietf.org>>, 
pce-chairs mailto:pce-cha...@ietf.org>>
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 s

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

[Dhruv Dhody]

Hi Samuel,

On Tue, Jul 9, 2024 at 12:30 PM Samuel Sidor (ssidor) 
wrote:

> Hi Andrew, Dhruv,
>
>
>
> Proposed text looks fine to me.
>
>
>
> Do we also need to consider future result of discussion for controlled ID?
> E.g. if decision will be done to use Notification message for ID space
> advertisement, will we need to synchronize content of those on top of TLVs
> from Open object?
>
>
>

Personally, I consider controlled ID (and PCECC) to be out of scope of the
state-sync I-D. We can make that explicit in the I-D.
In future another specification can tackle it if there is a need and can
use the technique that you suggest.

Thanks!
Dhruv


> Thanks,
>
> Samuel
>
>
>
> *From:* Dhruv Dhody 
> *Sent:* Tuesday, July 9, 2024 11:18 AM
> *To:* Andrew Stone (Nokia) 
> *Cc:* draft-ietf-pce-state-s...@ietf.org; pce@ietf.org; pce-chairs <
> pce-cha...@ietf.org>
> *Subject:* [Pce] Re: Pending item for draft-ietf-pce-state-sync
>
>
>
> Hi Andrew,
>
>
>
> On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia)  40nokia@dmarc.ietf.org> wrote:
>
> 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.*
>
>
>
>
>
> Dhruv: I suggest adding this here ->
>
>
>
>*  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.  The PCE MUST exchange this notification prior to the
>   State Synchronization (described in Section 3.2).  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.
>
>
>
>
>
> Overall text proposal looks good to me. I would assume this belongs in a
> 3.x section in the document.
>
>
>
>
>
> I suggest that this could be a subsection "3.5.1.  Information Received
> via Open Message from PCC"
>
>
>
> Thanks!
>
> Dhruv
>
>
>
>
>
> 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 <
> draft-ietf-pce-state-s...@ietf.org>, Andrew Stone (Nokia) <
> andrew.st...@nokia.com>
> *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

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

[Samuel Sidor (ssidor)]

Hi Andrew, Dhruv,

Proposed text looks fine to me.

Do we also need to consider future result of discussion for controlled ID? E.g. 
if decision will be done to use Notification message for ID space 
advertisement, will we need to synchronize content of those on top of TLVs from 
Open object?

Thanks,
Samuel

From: Dhruv Dhody 
Sent: Tuesday, July 9, 2024 11:18 AM
To: Andrew Stone (Nokia) 
Cc: draft-ietf-pce-state-s...@ietf.org; pce@ietf.org; pce-chairs 

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

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia) 
mailto:40nokia@dmarc.ietf.org>> 
wrote:
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.


Dhruv: I suggest adding this here ->

   *  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.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  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.


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


I suggest that this could be a subsection "3.5.1.  Information Received via 
Open Message from PCC"

Thanks!
Dhruv


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 mailto:d...@dhruvdhody.com>>
Date: Saturday, July 6, 2024 at 7:52 AM
To: 
draft-ietf-pce-state-s...@ietf.org 
mailto:draft-ietf-pce-state-s...@ietf.org>>,
 Andrew Stone (Nokia) mailto:andrew.st...@nokia.com>>
Cc: pce@ietf.org mailto:pce@ietf.org>>, 
pce-chairs mailto:pce-cha...@ietf.org>>
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 

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

[Cheng Li]

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: Where the Controlled ID info shuold be carried/encoded?

[Dhruv Dhody]

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  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 
> 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
>>
>> l  Open message
>>
>> l  Use PCEP-LS encoding and make this a node attribute
>>
>> l  New type of notification
>>
>> l  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

[Dhruv Dhody]

Hi Andrew,

On Mon, Jul 8, 2024 at 4:37 PM Andrew Stone (Nokia)  wrote:

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

Dhruv: I suggest adding this here ->

   *  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.  The PCE MUST exchange this notification prior to the
  State Synchronization (described in Section 3.2).  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.



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

I suggest that this could be a subsection "3.5.1.  Information Received via
Open Message from PCC"

Thanks!
Dhruv



> 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 <
> draft-ietf-pce-state-s...@ietf.org>, Andrew Stone (Nokia) <
> andrew.st...@nokia.com>
> *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
>