| Gyan, thanks for your review. Shuping, thanks for responding. I entered a No Objection ballot.
Alissa
Hi Shuping
I reviewed the updated version and it looks good ready for publication.
Kind Regards
Gyan
Hi Gyan,
Many thanks for your review. Please find my responses inline below.
I have also uploaded the new version of this draft according to your reviews and suggestions. .
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-controller-12
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-controller-12
Please let us know if there is any further comments.
Thank you!
> -----Original Message-----
> From: Gyan Mishra via Datatracker [mailto:noreply@xxxxxxxx]
> Sent: Thursday, February 11, 2021 7:03 AM
> To: gen-art@xxxxxxxx
> Cc: draft-ietf-pce-pcep-extension-for-pce-controller.all@xxxxxxxx;
> last-call@xxxxxxxx; pce@xxxxxxxx
> Subject: Genart last call review of
> draft-ietf-pce-pcep-extension-for-pce-controller-11
>
> Reviewer: Gyan Mishra
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please treat these comments just like any other last call
> comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-pce-pcep-extension-for-pce-controller-??
> Reviewer: Gyan Mishra
> Review Date: 2021-02-10
> IETF LC End Date: 2021-02-08
> IESG Telechat date: 2021-02-25
>
> Summary:
> This document is very well written and describes a new PCEP protocol
> extension for using PCE as a centralized controller PCECC for provisioning
> using its own discrete label space for all or discrete parts static LSP ERO
> path.
>
> Major issues:
> None
>
> Minor issues:
>
> For stateful PCE how do you prevent label collisions when both the PCE is
> provisioning using its own label space and the routers also are using their
> own label space as well and have a mix of both. After the label download
> and sync at each router hop PCE PCC session their maybe some nodes that
> use the router label space and other nodes using PCE label space.
>
This is covered in Section 3, I have added text to clarify further -
As per Section 3.1.2. of [RFC8283], the PCE-based controller will
take responsibility for managing some part of the MPLS label space
for each of the routers that it controls, and may take wider
responsibility for partitioning the label space for each router and
allocating different parts for different uses. The PCC MUST NOT make
allocations from the label space set aside for the PCE to avoid
overlap and collisions of label allocations.
> It would seem more complicated to have a mix of having both PCE managed
> label space and non PCE managed label space and for this draft since it’s
> about provisioning static LSP using PCE discrete label space I think it would
> make more sense to have entire LSP to be provisioned using PCE label space
> to prevent label collisions. This caveat I think should be added to the
> considerations section as well.
OK, I have added -
It is RECOMMENDED that
PCE makes allocations (from the label space set aside for the PCE)
for all nodes along the path.
> I did not see it mentioned but I think it’s
> also worthwhile mentioning what is the advantage of using this extension
> where the PCE uses its own label space. Also list the disadvantages as well
> so the operator had a clear picture of reasons to use this extension and
> maybe reasons to not use. It maybe also worthwhile to mention use cases
> where it makes sense to use this extension and others where it is not.
I have added the following text, which includes the correct references -
[RFC8283] examines the motivations and applicability for PCECC and
use of PCEP as an SBI. Section 3.1.2. of [RFC8283] highlights the
use of PCECC for label allocation along the static LSPs and it
simplifies the processing of a distributed control plane by blending
it with elements of SDN and without necessarily completely replacing
it. This allows the operator to introduce the advantages of SDN
(such as programmability) into the network. Further Section 3.3. of
[I-D.ietf-teas-pcecc-use-cases] describes some of the scenarios where
the PCECC technique could be useful. Section 4 of [RFC8283] also
describe the implications on the protocol when used as an SDN SBI.
The operator needs to evaluate the advantages offered by PCECC
against the operational and scalability needs of the PCECC.
>
> In section 9 I agree it’s a good idea to have mutually authentication and
> encrypted sessions for all PCE PCC sessions to prevent malicious PCE using
> this extension.
>
> Nits/editorial comments:
> The abstract states the following in the last sentence which I think should
> better describe the goal and purpose of the draft.
>
> “ This document specifies the procedures and PCEP extensions for using
> the PCE as the central controller.”
>
> I would say use of PCE as a centralized controller for provisioning RSVP-TE or
> SR-TE static LSP explicit ERO path for all or parts of an LSP using its own
> discrete label space.
>
Updated to -
This document specifies the procedures and PCEP extensions for using
the PCE as the central controller for provisioning labels along the
path of the static LSP.
Best regards,
Shuping
![]()
Gyan Mishra Network Solutions Architect M 301 502-1347
13101 Columbia Pike
Silver Spring, MD
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
