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

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jun 2018 17:23:33 +0000

Hi Adrian

Sorry for the delay.  Thanks again for the carefully considered feedback.  I've trimmed out points below where I agreed and no comment was necessary.  Please find answers and clarifications below.

---

Section 3

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

But I am surprised that this work is offloaded to the PCC since the PCE has all the information to do this task. Why did the WG want to add this option?

And then...

   o  An ordered set of SID(s)

s/SID(s)/SIDs/

This list of SIDs would need to be converted to labels by the PCC by applying the SRGB offsets. Again, why make the PCC do this?

And finally...

   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.

This mixture of the previous two cases seems to compound the level of complexity. Can't the PCE just know it is making an SR path and supply a list of MPLS labels corresponding to the SIDs?

[Jon] Having consulted the authors, the reason is that different PCE implementations have different approaches, which can all be accommodated fairly straightforwardly in the draft's format. Having said that, it seems harsh to force the PCC into having to provide an NAI-resolution service for the PCE.  Therefore, I have added a capability flag so that the PCC can indicate that it cannot / will not do NAI resolution. [/Jon]

---
                                                 
5.1.2 ----> 6

   If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
   PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is
   absent, then the PCEP speaker MUST send a PCErr message with Error-
   Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
   assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
   close the PCEP session.

Suppose an implementation receives an Open with PST=1 but doesn't understand (or doesn't support) that value. Is it still required to perform this check? Hopefully not.

[Jon] Nope.  Have changed to

   If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
   PST list containing PST=1, and supports that path setup type, then it
   checks for the presence of the SR-PCE-CAPABILITY sub-TLV.  If that sub-TLV is
   absent, then the PCEP speaker MUST send a PCErr message with Error-
   Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
   assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
   close the PCEP session.
[/Jon]

---

5.3.1 (under Length) has

      As mentioned earlier, an SR-ERO
      subobject MUST have at least SID or NAI.

This is good and does tie in with what is written in earlier sections.

However, 5.3.1 starts with

   An SR-ERO subobject consists of a 32-bit header followed by the SID
   and the NAI associated with the SID.  The SID is a 32-bit number.
   The size of the NAI depends on its respective type, as described in
   the following sections.

That makes it sound like they are both mandatory, and the figure doesn't help.

A little rewording would go a long way, and you could add "(optional)" 
to the figure.

[Jon] I have modified the preamble to the following, and have added the word "optional" to the diagram.

   An SR-ERO subobject consists of a 32-bit header followed by the SID
   and/or the NAI associated with the SID.  The SID is a 32-bit number.
   The size of the NAI depends on its respective type, as described in
   the following sections.  At least one of the SID and the NAI MUST be
   included in the SR-ERO subobject, and both MAY be included.
[/Jon]

---

5.3.1

   SID Type (ST)  indicates the type of information associated with the
      SID contained in the object body.  When ST value is 0, SID MUST
      NOT be null and NAI MUST be null.  

Does "null" mean "all zeros" or "absent"?

See also the definition of the S and F flags.

[Jon] It means "absent" (see definition of Length field).  But this is not particularly clear, so I have changed all instances of "null" to "absent". [/Jon]

---

5.3.1

      Other ST values are described
      later in this document.

It would be friendly to provide a list somewhere.
Do you need a registry?

[Jon] I have added a list and created a registry. [/Jon]

---

5.3.1

   Flags  is used to carry any additional information pertaining to SID.

You need to say how to set the unused bits.
Do you need a registry?

[Jon] I have created a registry. [/Jon]

---

5.3.3

   If a PCC receives a stack of SR-ERO subobjects, and the number of
   stack exceeds the maximum number of SIDs that the PCC can impose on
   the packet, it MAY send a PCErr message with Error-Type = 10
   ("Reception of an invalid object") and Error-Value = 3 ("Unsupported
   number of Segment ERO subobjects").

And if it doesn't send the PCErr, what should it do?

[Jon] I think this has to be a MUST, not a MAY. [/Jon]

---

5.3.3

   When a PCEP speaker detects that all subobjects of ERO are not
   identical, and if it does not handle such ERO, it MUST send a PCErr
   message with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value = 5 ("Non-identical ERO subobjects").

"Not identical" could have so many meanings here!
- Presumably you don't mean that all SIDs have the same value
- You might be referring to all flags
- You might be referring to just the M and C flags
- You might mean that the ERO must contain all SR-ERO subobjects or
  no SR-ERO subobjects

Please clarify and possibly rename the error value.

[Jon] It means the last of those. Renamed the error to "ERO mixes SR-ERO subobjects with other subobject types". 
It also means you can't mix labels, SID index values and pure NAI.  I've added that check too.[/Jon]

(See also 5.4.1).

[Jon] "RRO mixes SR-RRO subobjects with other subobject types" [/Jon]

---

5.3.3

   When a PCEP speaker receives an SR-ERO subobject in which ST is 0,
   SID MUST be present and NAI MUST NOT be present(i.e., S-flag MUST be
   0, F-flag MUST be 1, and the Length MUST be 8).  Otherwise, it MUST
   consider the entire ERO object invalid and send a PCErr message with
   Error-Type = 10 ("Reception of an invalid object") and Error-Value =
   11 ("Malformed object").  The PCEP speaker MAY include the malformed
   SR-ERO object in the PCErr message as well.

This text is good.
But it makes me think: what about the ST values 1 through 5 if the NAI is absent?

[Jon] I've generally tightened this area up and have hopefully covered all invalid cases! [/Jon]

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Julien Meuric
> Sent: 15 January 2018 09:38
> To: [email-masked]
> 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.

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

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jun 2018 17:24:03 +0000

Hi Dhruv

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

Cheers
Jon

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 30 January 2018 09:20
To: Julien Meuric <[email-masked]>; [email-masked]
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 SID(s).

   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

> Sent: 15 January 2018 15:08
> To: [email-masked]
> 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
>

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jun 2018 17:24:09 +0000

Hi Dhruv

Thanks – I have addressed this case in the latest version.

Jon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: 04 March 2018 05:41
To: [email-masked]
Cc: Julien Meuric <[email-masked]>; [email-masked]; Dhruv Dhody <[email-masked]>
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

Hi,

As I was updating the PCEP-SRv6 document [1], I noticed that the behavior for 'the unknown ST (SID Type)' is not defined in the SR-ERO/SR-RRO. Could the authors take this into consideration while they make an update.

Also an IANA code point sub registry needs to be setup in this document for the ST Type, so that future extensions (like SRv6) can define new ST types.

Thanks!
Dhruv

[1] https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/

On Tue, Jan 30, 2018 at 2:49 PM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

   Section 1

   Section 3

      SR-TE LSPs

   Section 5.1.1

   Section 6

   (6) Regarding,

   Section 7

   Section 8

   Nits
   ----

   Section 5.3.1

   s/MUST not/MUST NOT/

   Section 5.3.3

   (2)
   OLD:

   (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

> From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Julien Meuric
> To: [email-masked]<mailto:[email-masked]>
> Best wishes for this new year, full of interoperable specifications. Let
> us begin by resuming our work in progress.
>
> routing-11. Please send your feedback on the I-D to the PCE mailing list
> by Monday January 29.
>
> Regards,
>
> Jon & Julien
>
> [email-masked]<mailto:[email-masked]>

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jun 2018 17:24:19 +0000

Hi Cyril

Many apologies for the delay – please see below.

Cheers
Jon

From: Pce [mailto:[email-masked]] On Behalf Of Cyril Margaria
Sent: 30 January 2018 16:49
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

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.

[Jon]
I agree that a capability would be good.  Yes, if the NAI cannot be resolved, it should be rejected.
I have added both of these to the latest draft.
[/Jon]

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

[Jon]
If the SID is a bare label then the NAI may be given to help identify the next hop.  If the SID is an index and NAI is given as well, then the PCC SHOULD use the SID, because it is a more explicit instruction.  The PCE MAY give both SID and NAI for diagnostic / logging purposes.  I don’t think we should require the PCC to validate SID==NAI in that case; it should just use the SID as given.  I will clarify in the draft.
[/Jon]

Thanks,
Cyril

On 30 January 2018 at 01:19, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

   Section 1

   Section 3

      SR-TE LSPs

   Section 5.1.1

   Section 6

   (6) Regarding,

   Section 7

   Section 8

   Nits
   ----

   Section 5.3.1

   s/MUST not/MUST NOT/

   Section 5.3.3

   (2)
   OLD:

   Thanks!
   Dhruv