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

[Cyril Margaria]

Hi,

I have the following (hopefully not too late) comments/questions:

Section 5.3 ERO Object

 S: When this bit is set, the SID value in the subobject body is
 null.  In this case, the PCC is responsible for choosing the
 SID value, e.g., by looking up its TED using the NAI which, in
 this case, MUST be present in the subobject.


- What is the associated procedure if the PCC cannot resolve the NAI to a
SID? Should there be associated error codes. For instance the PCC may not
be able to resolve the NAI  at all or the resolution may fail. In case the
PCC does not support the NAI resolution, having this capability part of the
capability exchange would improve interop, as the PCE can be capable to
provide the SID.
- If Both S and F are cleared, should the PCC do the NAI resolution and
verify that the SID match? Would error codes be needed)

Thanks,
Cyril


On 30 January 2018 at 01:19, Dhruv Dhody  wrote:

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

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

[Julien Meuric]

Hi all,

This LC has ended.
Adrian, Dhruv (on HAST time), thanks a lot for your valuable reviews.
Authors, please address identified issues and update the I-D.

Cheers,

Julien


Jan. 15, 2018 - Julien Meuric:
> 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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Review of for draft-raghu-pce-lsp-control-request

[Dana Kutenicsova]

Hello,
we have reviewed and are supportive of draft-raghu-pce-lsp-control-request
Regards,
Dana Kutenicsova
Software Engineer
Frinx s.r.o.
Mlynské Nivy 48 / 821 09 Bratislava / Slovakia
+421 2 20 91 01 41 / dkutenics...@frinx.io / 
www.frinx.io
[cid:image002.png@01D24FBB.70342570]

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

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

[Dhruv Dhody]

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:pce-boun...@ietf.org] On Behalf Of Julien Meuric
> Sent: 15 January 2018 15:08
> To: pce@ietf.org
> 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
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce