Thank you Samuel for your support and comments, we are working on the replies
to address the comments received in the WG adoption call.
Will need some time, so please expect some delay. The reply will be sent to
our mail list next week š
Thanks,
Cheng
From: Samuel Sidor (ssidor) <ssi...@cisco.com>
Sent: Friday, May 31, 2024 2:16 PM
To: draft-li-pce-controlled-id-sp...@ietf.org
Cc: pce-chairs <pce-cha...@ietf.org>; Dhruv Dhody <d...@dhruvdhody.com>;
pce@ietf.org
Subject: RE: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16
Hi authors,
I support adoption of this document.
A few comments/questions:
* Is there reason to limit applicability of that draft to SR-MPLS/SRv6
(e.g. in Section 3.2)? I can imagine that for example BSID allocation may be
applicable to RSVP-TE LSPs as well
* Is it really good idea to use TLVs in Open message to exchange ID space?
* There is no capability advertised before that TLV is included (and
there is no way to do it since Open message is 1st message sent in that PCEP
session), so when PCC is including it, it does not know whether PCE can support
it or not. If PCE is responding with Keepalive message, it can mean 2 things
with no simple way to figure out which of them occurred:
* ID space control procedure was successful
* PCE does not support that TLV and ignored it completely
* If any of those ranges has changed, then PCEP session flap will be
required (I assume that those are changing often, so this may be acceptable).
If any other PCEP message is used, which can be sent on already established
PCEP session, then it can be modified without requiring PCEP session flap.
Maybe consider using PCNtf or some completely new PCEP message and in such case
you can even use explicit capability to indicate whether PCEP extensions from
this draft are supported or not
* Does it make sense to define some sub-type of delegated space? For
example, if PCC included 3 ranges in āLABEL-CONTROL-SPACE TLVā, then there can
be some registry of types to specify that 1st range is for BSID, 2nd one for
SRGB or SRLB,ā¦ How PCE should know which range is supposed to be used for what
purpose? (I can imagine that for SRGB, SRLB, it can be derived from complete
SRGB/SRLB range learned from IGP, but such approach probably cannot be used for
all ranges).
* Maybe consider renaming āBlockā field in āLABEL-CONTROL-SPACE TLVā to
something like āNumber of blocksā (see for example PST capability TLV in
https://www.rfc-editor.org/rfc/rfc8408.html#section-3) or even potentially drop
that field completely as number of ranges can be derived from TLV length
* In section 6, you pointed out that synchronization mechanism should be
used if same label ranges were allocated for multiple PCEs, but it would be
good to specify details how state-sync will solve synchronization issue (if PCC
is connected to both PCEs, then both PCEs should see already allocated labels
from PCRpt messages directly from PCC)
* One small type in section 1 āThis documnet adds tā¦āā
Thanks,
Samuel
From: Dhruv Dhody <d...@dhruvdhody.com<mailto:d...@dhruvdhody.com>>
Sent: Friday, May 17, 2024 1:10 PM
To: pce@ietf.org<mailto:pce@ietf.org>
Cc: pce-chairs <pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>>;
draft-li-pce-controlled-id-sp...@ietf.org<mailto:draft-li-pce-controlled-id-sp...@ietf.org>
Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16
Hi WG,
This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16
https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/
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 3rd June 2024.
Please be more vocal during WG polls!
Thanks!
Dhruv & Julien
_______________________________________________
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org
