Re: [Last-Call] [Gen-art] Genart last call review of draft-ietf-pce-pcep-extension-for-pce-controller-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gyan, thanks for your review. Shuping, thanks for responding. I entered a No Objection ballot.

Alissa


On Feb 12, 2021, at 3:35 AM, Gyan Mishra <hayabusagsm@xxxxxxxxx> wrote:


Hi Shuping 

I reviewed the updated version and it looks good ready for publication.

Kind Regards 

Gyan

On Thu, Feb 11, 2021 at 3:50 AM Pengshuping (Peng Shuping) <pengshuping@xxxxxxxxxx> wrote:
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

_______________________________________________
Gen-art mailing list
Gen-art@xxxxxxxx
https://www.ietf.org/mailman/listinfo/gen-art

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux