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

[Jonathan Hardwick <[e-mail]>]

Hi Dhruv

My apologies for the delay.  Please find my replies and comments below.

Cheers
Jon

-----Original Message-----
From: Pce [mailto:[e-mail]] On Behalf Of Dhruv Dhody
Sent: 30 January 2018 09:20
To: Julien Meuric <[e-mail]>; [e-mail]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

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.

[Jon] OK with me - I'll trim it. [/Jon]

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

[Jon] Changed introduction text as follows and added normative references.

The SR architecture can be implemented using either an MPLS forwarding plane [I-D.ietf-spring-segment-routing-mpls] or an IPv6 forwarding plane [I-D.ietf-6man-segment-routing-header].  The MPLS forwarding plane can be applied to SR without any change, in which case an SR path corresponds to an MPLS Label Switching Path (LSP). This document is relevant to the MPLS forwarding plane only.

[/Jon]

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

[Jon] I changed it to:

      This specification relies on the procedures specified in [I-
      D.ietf-pce-lsp-setup-type] to exchange the segment routing
      capability and to specify that the path setup type of an LSP
      is segment routing..
[/Jon]

   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. 

[Jon] Changed bullet 2 to:

An ordered set of SIDs, with or without the corresponding IP addresses.

[/Jon]

   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.

[Jon] For backwards compatibility with shipping implementations that omit it. [/Jon]

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

[Jon] OK [/Jon]

   Section 7

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

[Jon] Done [/Jon]

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

[Jon] Done [/Jon]

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

[Jon] Have tweaked it a bit but I think (nay, hope) what we have is OK as it passed for the LSP setup type draft. [/Jon]

   Nits
   ----

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

[Jon] Above you point out that RFC5440 does not deal with unrecognised subobjects. I have changed the text along the lines you suggested above. [Jon]

   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

_______________________________________________
Pce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pce