Subject: [Pce] WG Last Call for draft-ietf-pce-hierarchy-extensions

From: Julien Meuric <[email-masked]>
Date: Thu, 6 Sep 2018 17:32:23 +0200

Hi all,

This message initiates a 2-week WG last call for
draft-ietf-pce-hierarchy-extensions-05. Please review and share your
feedback on the PCE mailing list. This LC will end on Thursday
September, 20.

Regards,

Jon & Julien

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 17 Sep 2018 09:36:17 +0100

Authors,

Thanks for this draft: it describes function for which there are clear
requirements. Section 9 is very helpful in assessing the practicality
of these protocol extensions.

Apologies for not having reviewed this earlier in the cycle, it's not
something I have an implementation for. 

I have quite a catalogue of comments, but in view of the existing 
implementations it would be acceptable for you to respond to some of
them with: "We could have done it like that, but what we have documented
has been proven to work and there are implementations."

Thanks for the work.

Adrian

---

Per idnits, RFC 5226 has been replaced by RFC 8126

---

Abstract

OLD
   The Hierarchical Path Computation Element (H-PCE) architecture RFC
   6805, provides a mechanism to allow the optimum sequence of domains
   to be selected, and the optimum end-to-end path to be derived through
   the use of a hierarchical relationship between domains.

   This document defines the Path Computation Element Protocol (PCEP)
   extensions for the purpose of implementing necessary Hierarchical PCE
   procedures and protocol extensions.
NEW
   The Hierarchical Path Computation Element (H-PCE) architecture is
   defined in RFC 6805.  It provides a mechanism to derive an optimum
   end-to-end path in a multi-domain environment by using a hierarchical
   relationship between domains to select the optimum sequence of
   domains and optimum paths across those domains.

   This document defines extensions to the Path Computation Element
   Protocol (PCEP) to support Hierarchical PCE procedures.
END

---

1.

OLD
   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.
NEW
   The Path Computation Element communication Protocol (PCEP) provides
   a mechanism for Path Computation Elements (PCEs) and Path Computation
   Clients (PCCs) to exchange requests for path computation and
   responses that provide computed paths.
END

---

1.1

You might find RFC 7399 a useful reference in this section.

---

2. and sub-sections

I don't think the use of 8174 language in these sections is necessary.

---

2.1.2

s/objective Function/Objective Function/  *2
s/objective function/Objective Function/  *5

---

2.1.2 has

   For inter-domain path computation, there is one new objective
   Function which is defined in section 1.3.1 and 4.1 of [RFC6805]:

   o  Minimize the number of domains crossed.  A domain can be either an
      Autonomous System (AS) or an Internal Gateway Protocol (IGP) area
      depending on the type of multi-domain network hierarchical PCE is
      applied to.

   Another objective Function to minimize the number of border nodes is
   also defined in this document.

So the first line must be wrong because the second paragraph defines a
second OF. But section 3.3 defines 3 new OFs (although it claims to only
define 2).

I'll defer my discussion of the OFs themselves to section 3.3.

---

2.1.2

There may be a few too many words in this section since mainly it
describes how PCEP already carries OFs. Apart from the new OF codes and
the final paragraph, there doesn't seem to be any new requirement in
this section.

Not saying this is a requirement to change the text, but it might be
nice to prune it a bit.

---

2.1.2

   A parent PCE MUST be capable of ensuring homogeneity, across domains,
   when applying OF codes for strict OF intra-domain requests.

I am not completely sure what this means. You might be saying that the
OFs must be interpreted in the same way in each domain. Sounds good, but
how can a parent PCE ensure that? And why would a domain be trusted?

---

2.2 goes further than 6805 section 4.8.2. 6805 does not suggest that the
child PCE needs to make any indication in its Open message.

Everything is good (including the section title!) except for the
inclusion of the following sentence.

   During the PCEP session establishment procedure, the child PCE needs
   to be capable of indicating to the parent PCE whether it requests the
   parent PCE capability or not.

This seems peculiar and unnecessary as follows:
- If a PCE is capable of being a parent for a specific child it will
  say so in its Open message to that child, and it will be willing to
  receive H-PCE requests from that child.
- A child PCE can only send H-PCE requests to another PCE if that PCE
  has indicated that it is a parent.
- Requesting another PCE to be a parent will not change its capabilities
  or willingness.
- Requests sent by a parent PCE to another PCE are (should be)
  indistinguishable from requests sent by any PCC to that PCE. So there
  is no need to register any capabilities in this regard.

(BTW - I'm seriously wishing you had called this the "Are you my mummy?"
 function.)

---

2.3.  Do you mean "PCE Domain Discovery" or "PCE Domain Identification"?

The section does talk about identifiers, but not about discovery.

---

3.

OLD
   This section defines PCEP extensions to ([RFC5440]) so as to support
   the H-PCE procedures.
NEW
   This section defines extensions to PCEP [RFC5440] to support the 
   H-PCE procedures.
END

---

3.1.1

Per my comment on 2.2, I don't believe there is a need for the R-flag.

Furthermore, if there's no need for the R-flag (assume it is removed) 
then the I-flag would always be set when the TLV is present. So, if the
R-flag is removed, then the I-flag can be removed, too.

---

3.1.1

s/indicate that/indicates that/
s/parent PCE receive/parent PCE receives/

---

3.1.1

   If such capability is not exchanged and the parent PCE receive a "H-
   PCE path computation request", it MUST send a PCErr message with
   Error-Type=TBD8 (H-PCE error) and Error-Value=1 (Parent PCE
   Capability not advertised).

This isn't how backward compatibility works. True that an H-PCE-capable
PCE that doesn't want to support H-PCE communications with a peer could
return this error, but a legacy PCE will not be able to return this new
error type (because it doesn't support H-PCE). 

Probably the way to handle this is:
- add a new section (towards the end) called "Backward Compatibility" 
- point to that from 3.1.1 for "PCE's that don't support H-PCE 
  extensions as defined in this document"

---

3.1.2
s/domain(s)/domains/

---

3.2.2

Does the use of the Domain-id TLV in the RP object open us up to a new
error code if the destination is not actually in the indicated domain?

---

3.3.1 contains three new OFs, not two as the text says.

You need to format the text so all of the bullets are consistent. 

"the H-PCE experiment" Maybe not an experiment?

---

3.3.1 MTD

I think you should clarify the way domains are counted. Specifically, 
it appears from your algorithm that domain re-entry does not increment
the count of domains. It is worth making this point explicitly.

---

3.3.1 MBN

This is slightly hard to be clear about.

AS1       :  AS2
          :
A---B---C===D
        | :
        | :
        E :

Consider the path ABCE. C is an ASBR. C is on the path, but is not used
as a border node. Should it be counted? Your algorithm says so.

Is the count of border nodes intended to minimise domains *and* minimise
(while still allowing) domain re-entry?

---

3.3.1 MCTD could usefully also have an "Objective" since it explains
things so much more clearly.

Currently the description is ambiguous:

   o  Description: Find a set of paths such that it passes through the
      least number of common transit domains.

This could mean "aim to common transit domains, but reduce the number"
or "aim to not have common transit domains."

BTW s/least/fewest/

---

3.3.2 describes how to include multiple OFs for an H-PCE computation.
This function is needed as the new OFs are supplementary to pre-existing
OFs. However, there are some issues:

1. The normal path OF could be in conflict with the H-PCE OF.
   Consider the path OF asking for least cost (MCP) and the H-PCE OF
   asking for fewest transit domains (MTD). Now consider...
   ................   .......................
   :              :   :                     :
   : src---A---B--------C---D---E---F---dst :
   :           |  :   :             |       :
   :...........|...   ..............|.......:
               |                    |
             ..|....................|...
             : |                    |  :
             : X--------------------Y  :
             :                         :
             :.........................:

   ABXYF is a lower cost path, but invokes an extra domain. How is this
   resolved?

2. The structure of the OF object allows TLVs to be included to qualify
   the OF (more example metrics). Now if you are allowing additional OFs
   to be present in an OF-list TLV, there is a question about how you 
   carry additional TLVs for those TLVs (understanding that you may have
   to tightly bind the additional TLVs to one OF and not to another).

3. As you note, 5541 indicates that only one OF can be present. This is
   (presumably?) to avoid conflicting or contradictory OFs. Now that you
   allow two OFs to be present you need to say something to stop the
   presence of two competing (pre-existing) OFs. You could (probably?)
   say that only H-PCE OFs may be present in one place, and only non-H-
   PCE OFs in the other place.

4. Had you considered using multiple OF objects?

---

3.4

Does the domain count include the source and destination domains? Does
it count a domain twice if the domain is re-entered?

---

3.4

The two paragraphs about the B-flag, don't add anything beyond 5440, do
they?

---

3.5

s/proposes/defines/

---

4.1 has

   When a specific child PCE sends a PCReq to a peer PCE that requires
   parental activity and the peer PCE does not want to act as the parent
   for it, the peer PCE should send a PCErr message to the child PCE and
   specify the error-type=TBD (H-PCE error) and error-value=2 (parent
   PCE capability cannot be provided) in the PCEP-ERROR object.

while 7.7 has

                Error-value=2 Parent PCE
                Capability not supported

The name in 7.7 may be closer to the "does not want" idea in 4.1.

---

4.2.  Procedure to obtain Domain Sequence

s/obtain/Obtain/

It would be good to clarify whether the sequence of domains has been
verified to provide a path. The difference lies in whether the parent
PCE only looks at the domain interconnection, or consults the child 
PCEs.

---

7.3

You need to specify the IANA allocation policy

---

7.9
s/TBD13/TBD12/

---

8.
Any reason why you mention TCP-AO without a reference to 5926

---

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Julien Meuric
> Sent: 06 September 2018 16:32
> To: [email-masked]
> Subject: [Pce] WG Last Call for draft-ietf-pce-hierarchy-extensions
> 
> Hi all,
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 17 Sep 2018 14:20:35 +0530

Hi Adrian,

Thanks for your comments.
I am the document shephered for this I-D, I will work with the authors and
put out an update SOON :)

Regards,
Dhruv

---

From: Julien Meuric <[email-masked]>
Date: Fri, 21 Sep 2018 12:15:25 +0200

Hi,

This LC has ended. Thank you Adrian for the review. Authors, please
resolve the open items and publish a revision accordingly.

Cheers,

Julien