Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

[Dhruv Dhody <[e-mail]>]

Hi, 

   I had reviewed and given comments on the I-D in the past, which the
   authors had addressed. I found these additional nits/suggestions.
   Apologies for being late by a day.  

   Suggestions
   -----------

   Section 1

   (1) Though it is true that a child PCE act as a PCC towards the
   parent PCE, I feel it is not wise to say the opposite, that is a PCC
   is acting as a PCE in this context. I see no advantage to bring up the
   H-PCE in this context. I suggest we remove it. 

      A PCE, or a PCC operating as a PCE (in hierarchical PCE
      environment), computes paths for MPLS Traffic Engineering LSPs
      (MPLS-TE LSPs) based on various constraints and optimization
      criteria.

   (2) Since this document is related to MPLS data plane only, it would
   be nice to include a pointer to the SRv6 work in PCEP for the benefit
   of the readers.

   (3) Regarding first mention of PST
   OLD:
      This specification relies on the procedures specified in [I-
      D.ietf-pce-lsp-setup-type].
   NEW:
      This specification relies on the procedures specified in [I-
      D.ietf-pce-lsp-setup-type] for the path setup type for SR.

   Section 3

   (4) Regarding this text - 

      SR-TE LSPs
      computed by a PCE can be represented in one of the following forms:

      o  An ordered set of IP address(es) representing network nodes/links:
         In this case, the PCC needs to convert the IP address(es) into the
         corresponding MPLS labels by consulting its Traffic Engineering
         Database (TED).

      o  An ordered set of SID(s).

      o  An ordered set of both MPLS label(s) and IP address(es): In this
         case, the PCC needs to convert the IP address(es) into the
         corresponding SID(s) by consulting its TED.

   Each SR-ERO object can include both SID and NAI (IP address); this
   case is different from the case 3 above, I suggest if some text can
   be added to make things clearer. 

   Section 5.1.1

   (5) Why SHOULD in this text?

      A PCEP speaker SHOULD indicate its support of the function described
      in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
      OPEN object with this new PST included in the PST list.

   Section 6

   (6) Regarding, 

      A PCEP speaker that does not support the SR PCEP capability cannot
      recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
      PCEP error with Error-Type = 4 (Not supported object) and Error-Value
      = 2 (Not supported object Type) as per [RFC5440].

   RFC 5440 did not state the behavior for unknown sub-object. My
   suggestion would be - 

      A PCEP speaker that does not support the SR PCEP capability and
      thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
      respond according to the rules for a malformed object as per
      [RFC5440].

   Section 7

   (7) Suggest to make Manageability Consideration section as per RFC
   6123

   (8) PCEP-Yang should be mentioned in section 7.2

   Section 8
 
   (9) Suggest we expand the security consideration section a bit based
   on recent DISCUSSes.


   Nits
   ----

   Section 5.3.1

   s/MUST not/MUST NOT/

   Section 5.3.3

   (2) 
   OLD:
      A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
      PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
      message and MUST send a PCErr message with Error-Type=3 ("Unknown
      Object") and Error-Value=2 ("Unrecognized object Type") or Error-
      Type=4 ("Not supported object") and Error-Value=2 ("Not supported
      object Type"), defined in [RFC5440].
   NEW:
      A PCEP speaker that does not recognize or support the SR-ERO
      subobject in PCRep, PCInitiate, PCUpd or PCRpt messages MUST
      reject the entire PCEP message and MUST send a PCErr message with
      Error-Type=3 ("Unknown Object") and Error-Value=2 ("Unrecognized
      object Type") or Error- Type=4 ("Not supported object") and Error-
      Value=2 ("Not supported object Type"), defined in [RFC5440].

   (3) I agree with Adrian that the ".. not identical" needs to change.
   Since you mean all subobject in ERO must be of SR-ERO type, we should
   just call it that! (also applicable for SR-RRO).

   Thanks! 
   Dhruv


> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Julien Meuric
> Sent: 15 January 2018 15:08
> To: [e-mail]
> Subject: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
> 
> Dear PCE WG,
> 
> Best wishes for this new year, full of interoperable specifications. Let
> us begin by resuming our work in progress.
> 
> This message starts a 2-week WG last call for draft-ietf-pce-segment-
> routing-11. Please send your feedback on the I-D to the PCE mailing list
> by Monday January 29.
> 
> Regards,
> 
> Jon & Julien
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce