Subject: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt> (Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 23 Aug 2016 10:58:54 -0700

The IESG has received a request from the Path Computation Element WG
(pce) to consider the following document:
- 'Extensions to the Path Computation Element Communication Protocol
   (PCEP) to compute service aware Label Switched Path (LSP).'
  <draft-ietf-pce-pcep-service-aware-12.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-09-06. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   In certain networks, such as, but not limited to, financial
   information networks (e.g. stock market data providers), network
   performance criteria (e.g. latency) are becoming as critical to data
   path selection as other metrics and constraints.  These metrics are
   associated with the Service Level Agreement (SLA) between customers
   and service providers.  The link bandwidth utilization (the total
   bandwidth of a link in current use for the forwarding) is another
   important factor to consider during path computation.

   IGP Traffic Engineering (TE) Metric extensions describe mechanisms
   with which network performance information is distributed via OSPF
   and IS-IS respectively.  The Path Computation Element Communication
   Protocol (PCEP) provides mechanisms for Path Computation Elements
   (PCEs) to perform path computations in response to Path Computation
   Clients (PCCs) requests.  This document describes the extension to
   PCEP to carry latency, delay variation, packet loss and link
   bandwidth utilization as constraints for end to end path computation.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-service-aware/ballot/

No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-pce-stateful-pce: PCEP Extensions for Stateful PCE (None - IETF stream)
Note that some of these references may already be listed in the acceptable Downref Registry.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Aug 2016 15:13:34 +0100

I just read this document for IETF last call.

I feel a little bad that I didn't review the document in WG last call since I
normally participate in the PCE WG, but the timing wasn't good.

The document is both well written and clear.  I support advancing this document,
but I have a few small comments.

Thanks,
Adrian

---

Requirement 4 has

   4.  A PCE is not required to support service aware path computation.
       Therefore, it MUST be possible for a PCE to reject a PCReq
       message with a reason code that indicates service-aware path
       computation is not supported.

It may be better to phrase this in terms of legacy systems since
(obviously), a PCE that does not support this spec must still be able to
reject requests. Perhaps...

   4.  A PCE that supports this specification is not required to provide
       service aware path computation to any PCC at any time.
       Therefore, it MUST be possible for a PCE to reject a PCReq
       message with a reason code that indicates service-aware path
       computation is not supported.  Furthermore, a PCE that does not
       support this specification will either ignore or reject such
       requests using pre-existing mechanisms, therefore the requests
       MUST be identifiable to legacy PCEs and rejections by legacy
       PCEs MUST be acceptable within this specification.

This is not a change to the requirement and doesn't change your protocol
solution.

---

4.1.1 has...

   - A path delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.

Is it worth noting that the path delay metric is not the effective delay
along the path? That is, delay on the path will also be introduced by
delays in the nodes along the path. However, information about the
delays introduced by nodes along the path is not currently made
available through the routing protocols, and is unlikely to be
consistent as network load varies.

Note that your definition of path delay is good. I am not proposing
any change to the definition, just and explanation of what it is not.

---

In several places in Section 4 you refer to specific bits (P bit,
B bit...). I think it would be helpful to understand that these are
bits in the flags field of the Metric object. Maybe an easy way to
deal with this is...

OLD
   The METRIC object is defined in section 7.8 of [RFC5440], comprising
   metric-value, metric-type (T field) and flags.  This document defines
   the following types for the METRIC object.
NEW
   The METRIC object is defined in section 7.8 of [RFC5440], comprising
   metric-value, metric-type (T field) and a flags field comprising a
   number of bit-flags (B bit, P bit).  This document defines the
   following types for the METRIC object.
END

---

I think you need to add (a very small amount of) text to describe how
this all works for initiated LSPs. Just like Section 5.

---

4.1.1.1

   [RFC7471] and [RFC7810] define the "Unidirectional Link Delay Sub-
   TLV" in a 24-bit field.

I think this should be...

   [RFC7471] and [RFC7810] define the "Unidirectional Link Delay Sub-
   TLV" to report link delay in microseconds in a 24-bit field.

Similarly in 4.1.2.1

---

4.1.6 has

   This section defines the following optional types for the METRIC
   object for P2MP TE LSPs.

4.1 does not say whether the P2P metrics are optional or mandatory.
I suspect you mean...
- Implementations of this spec must implement TBD1, TBD2, and TBD3
- Implementations of this spec that support P2MP (which is an optional
  feature) must support TBD8, TBD9, and TBD10.

---

In 4.1.6.1 when you wrote

   - The P2P path delay metric of the path to destination Dest_j is
   denoted by LM(Dest_j).

I wonder whether you were thinking "LM means Link delay Metric"?
A bit odd that you have actually written "LM means P2P path delay 
metric"

Ditto LVM in 4.1.6.2

---

4.2.3.1

   A PCC SHOULD request the PCE to factor in the bandwidth utilization
   during path computation by including a BU object in the PCReq
   message.

I don't understand the use of "SHOULD" here. I suspect you mean...

   A PCC that wants the PCE to factor in the bandwidth utilization
   during path computation includes a BU object in the PCReq message.

What you have is a statement that unless there is a good reason why not,
a PCC is supposed to request the PCE to factor in the bandwidth 
utilization during path computation.

---

4.2.3.1

I found the following clumsy and suggest a change...

OLD
   Multiple BU objects MAY be inserted in a PCReq or a PCRep message for
   a given request but there MUST be at most one instance of the BU
   object for each type.  If, for a given request, two or more instances
   of a BU object with the same type are present, only the first
   instance MUST be considered and other instances MUST be ignored.
NEW
   A PCReq or PCRep message MAY contain multiple BU objects so long as
   each is for a different bandwidth utilization type.  If a message
   contains more than one BU object with the same bandwidth utilization
   type, the first MUST be processed by the receiver and subsequent 
   instances MUST be ignored.
END

---

4.2.3.1 should not define legacy behavior. A legacy node will not see 
this spec and cannot be influenced by what you write. So...

OLD
   If a PCE receives a PCReq message containing a BU object, and the PCE
   does not understand or support the BU object, and the P bit is clear
   in the BU object header then the PCE SHOULD simply ignore the BU
   object.

   If the PCE does not understand the BU object, and the P bit is set in
   the BU object header, then the PCE MUST send a PCErr message
   containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object)
   and Error-value = 1 (Unrecognized object class) as per [RFC5440].
NEW
   The behavior of a PCE that does not understand an object that it
   receives on PCReq message is defined in [RFC5440] and depends on the
   setting of the P bit in the object header (P bit clear means ignore
   the object, P but set means return an "Unknown object" error).
END

---

4.2.3.1

Your use of passive voice may cause confusion. You write...

   The path computation
   request MUST then be cancelled.

Does this mean:
1. The PCE must do not more processing on the request and the PCC must
   not expect any further response
2. The PCC is required to issue a message to cancel the request

There are two cases of this text in this section.

---

Section 5 does a nice job for stateful PCE. I think you also need to 
cover PCE initiated LSPs.

---

Section 6 needs a reference to RFC 5511 so that the message formats can
be understood.

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of The IESG
> Sent: 23 August 2016 18:59
> To: IETF-Announce
> Cc: [email-masked]; [email-masked]; draft-ietf-pce-pcep-service-
> [email-masked]
> Subject: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt>
(Extensions
> to the Path Computation Element Communication Protocol (PCEP) to compute
> service aware Label Switched Path (LSP).) to Proposed Standard
> 
>

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 31 Aug 2016 09:29:37 +0000

Hi Adrian, 

Thanks for your review and especially for providing suggested text.
I have attached the working copy and diff. 

> From: Pce [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 30 August 2016 19:44
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt>
> (Extensions to the Path Computation Element Communication Protocol (PCEP)
> to compute service aware Label Switched Path (LSP).) to Proposed Standard
> 
> I feel a little bad that I didn't review the document in WG last call since
> I normally participate in the PCE WG, but the timing wasn't good.
> 
> The document is both well written and clear.  I support advancing this
> document, but I have a few small comments.
> 
> Thanks,
> Adrian
> 
> ---
> 
> Requirement 4 has
> 
> It may be better to phrase this in terms of legacy systems since (obviously),
> a PCE that does not support this spec must still be able to reject requests.
> Perhaps...
> 
[Dhruv] Updated!  
> along the path? That is, delay on the path will also be introduced by delays
> in the nodes along the path. However, information about the delays introduced
> by nodes along the path is not currently made available through the routing
> protocols, and is unlikely to be consistent as network load varies.
> 
> Note that your definition of path delay is good. I am not proposing any change
> to the definition, just and explanation of what it is not.
> 
[Dhruv] Agreed, I can add a note with reference to [RFC7823] for this. 
> ---
> 
> In several places in Section 4 you refer to specific bits (P bit, B bit...).
> I think it would be helpful to understand that these are bits in the flags
> field of the Metric object. Maybe an easy way to deal with this is...
> 
> OLD
[Dhruv] Done!
> ---
> 
> I think you need to add (a very small amount of) text to describe how this
> all works for initiated LSPs. Just like Section 5.
> 
[Dhruv] Added! 
>    TLV" to report link delay in microseconds in a 24-bit field.
[Dhruv] Done! 
>   feature) must support TBD8, TBD9, and TBD10.
[Dhruv] I will remove the word optional from 4.1.6 to keep it consistent with P2P, and avoid the confusion. 
> A bit odd that you have actually written "LM means P2P path delay metric"
> 
> Ditto LVM in 4.1.6.2
> 
[Dhruv] Yes that is odd, Updated to PDM and PDVM for path delay metric and path delay variation metric. 
> a PCC is supposed to request the PCE to factor in the bandwidth utilization
> during path computation.
> 
[Dhruv] Good catch! 
>    instances MUST be ignored.
[Dhruv] Updated!
> ---
> 
> 4.2.3.1 should not define legacy behavior. A legacy node will not see this
> spec and cannot be influenced by what you write. So...
> 
> OLD
[Dhruv] I have updated it as - 
     If the BU object is unknown/unsupported, the PCE MUST follow
     procedures defined in [RFC5440]. That is, if the P bit is set, the
     PCE sends a PCErr message with error type 3 or 4 (Unknown / Not
     supported object) and error value 1 or 2 (unknown / unsupported
     object class / object type), and the related path computation
     request MUST be discarded.  If the P bit is cleared, the PCE is
     free to ignore the object.
> There are two cases of this text in this section.
[Dhruv] You are right, I have updated it to - 
     ... and the related path
     computation request MUST be discarded.

> ---
> 
> Section 5 does a nice job for stateful PCE. I think you also need to cover
> PCE initiated LSPs.
> 
[Dhruv] I have tried to handle it. 

> ---
> 
> Section 6 needs a reference to RFC 5511 so that the message formats can be
> understood.

[Dhruv] added.

Thanks again for your comments!
 
Dhruv

> > to the Path Computation Element Communication Protocol (PCEP) to
> > compute service aware Label Switched Path (LSP).) to Proposed Standard
> >
> >
> > [email-masked] mailing lists by 2016-09-06. Exceptionally, comments may
> > be sent to [email-masked] instead. In either case, please retain the
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 31 Aug 2016 14:17:59 +0100

Nice job and very fast!

I am happy with all the changes, but one caution...

>      free to ignore the object.

You still have normative language in this document to describe how an
implementation that has not read this document is required to behave.  I don't
think that can work.

I suggest s/MUST/will/.

Cheers,
Adrian

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 31 Aug 2016 18:10:17 +0000

Hi Adrian, 

Ack.
Updated in working copy. 

Regards,
Dhruv

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 31 August 2016 18:48
> To: Dhruv Dhody <[email-masked]>; [email-masked]
> [email-masked]; 'Dhruv Dhody' <[email-masked]>
> Subject: RE: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt>
> > > 4.2.3.1 should not define legacy behavior. A legacy node will not
> > > see this spec and cannot be influenced by what you write. So...
> > >
> > > OLD
> implementation that has not read this document is required to behave.  I
> don't think that can work.
> 
> I suggest s/MUST/will/.
> 
> Cheers,
> Adrian

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 31 Aug 2016 20:55:02 +0000

Hi Everyone,

    Customers are very interested in the H-PCE and as we continue to develop the H-PCE we would like to minimize the amount of manual configurations. Two key areas for better automation are:

    1. Advertisement of inter-domain connections (inter-domain links and ABRs) from child PCE to parent PCE
    2. Construction of the parent PCE TED based on the advertisement

    Existing methods for these two objectives require manual efforts. Some automation is possible if the parent PCE can also join the IGP instance of a child PCE domain to learn inter-domain TE link info, but not all operators would want to allow this. It was expected that this type of information would be statically configured. As the numbers of domains increase that a parent PCE is managing, it will become a configuration burden to update the parent PCE manually. The BGP-LS may be another option but I am not sure all operators will want to use the BGP-LS. Why not continue to use PCEP with extensions if it is being used for the H-PCE.

    In the existing PCEP, there are not any procedures or data defined for a child PCE to send and summarize the connections and access points to its parent PCE, and for a parent PCE to receive and process the connections and access points from its child PCEs to construct the parent PCE TED. The extensions proposed in our draft "Connections and Accesses for Hierarchical PCE" https://datatracker.ietf.org/doc/draft-chen-pce-h-connect-access/ specify the procedures and define the data, in which a child PCE advertises and summarizes its inter-domain connections and access points to its parent PCE,  which constructs the parent PCE TED.

    Note that in the existing PCE-LS draft, there are not any procedures defined for a child PCE to send and summarize the inter-domain connections and access points to its parent PCE, and for a parent PCE to receive and process the inter-domain connections and access points from its child PCEs.

    What our draft proposed seems a new work. I hope for good discussions on this topic on the list.

Best Regards,
Huaimo