Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt

["Adrian Farrel" <[e-mail]>]

Hi Dhruv, Authors,

Thanks for -06 and -07 addressing comments, and -08 fixing the ToC.

I have just been through the diffs comparing against my review comments. You seem to addressed most of my concerns, but not quite all of them. You also introduced a couple of new issues....

Thanks for the work,
Adrian
--
Fairy tales from North Wales brought to you for Christmas
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

===

In 2.1.2 you now have " there is three new".  s/is/are/

---

I don't think you have completely addressed my concerns in 2.2. In fact you have changed the text to say...
   A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE
   Capability" TLV, described in Section 3.1.1, in the OPEN Object to
   advertise its support for PCEP extensions for H-PCE Capability.
But the very next paragraph says only that " it would assist network operators if the child and parent PCEs could indicate their H-PCE capabilities." In other words, you have created a conflict. Either it is PCEs and PCCs that support this document MUST advertise that capability in the Open message, or it is RECOMMENDED.

Maybe, in the first line s/includes/can include/ 

Or maybe (having re-read 3.1.1) you intend to go beyond 6805 section 4.8.2 and make the capabilities in the Open Message mandatory for H-PCE pairings. It would help if you were clear about this such as...
OLD
   A PCEP Speaker (Parent PCE or Child PCE or PCC) includes the "H-PCE
   Capability" TLV, described in Section 3.1.1, in the OPEN Object to
   advertise its support for PCEP extensions for H-PCE Capability.

   Parent and child PCE relationships are likely to be configured. 
   However, as mentioned in [RFC6805], it would assist network operators
   if the child and parent PCEs could indicate their H-PCE capabilities.
NEW
   A PCEP Speaker (Parent PCE or Child PCE) that supports and wishes
   to use the procedures described in this document must advertise
   the fact and negotiate its role with its PCEP peers. It does this using
   the "H-PCE Capability" TLV, described in Section 3.1.1, in the OPEN
   Object to advertise its support for PCEP extensions for H-PCE
   Capability.
END

---

3.1.1. is a lot better, thanks.

You have...
   The inclusion of this TLV in an OPEN object indicates that the H-PCE
   extensions are supported by the PCEP speaker.  The child PCE MUST 
   include this TLV and set the P flag.  The parent PCE MUST include 
   this TLV and unset the P flag. The PCC MUST include this TLV to 
   indicate that it understands the H-PCE extensions with P flag unset.

The first two sentences are good: the function allows two PCEs to work out the direction of the relationship between them.

However, I don't understand the final sentence. Why would a PCC need to indicate that it understands the H-PCE extensions? Given that it:
- cannot be a parent PCE because it is not a PCE
- cannot be a child PCE because it is not a PCE
...why would it ever indicate that it supports the H-PCE extensions? Actually, why would it ever be implemented to support those extensions? Furthermore, by including the TLV but not setting the P flag, it gives the impression that it is willing to be a parent PCE.

I would replace this with, "A PCE MUST NOT include this TLV."

You also, nicely, have
   If both peers attempt to set the P flag then the session 
   establishment MUST fail, and the PCEP speaker MUST respond with PCErr
   message using Error-Type 1: "PCEP Session Establishment Failure" as 
   per [RFC5440].
Which catches one half of the 'race' condition.
I think you should add that, "If neither peer sets the P flag then the session establishment can proceed and the relationship between the PCEs continues as normal for cooperating PCEs."

---

3.1.1.1 is a bit week. You have two error conditions to handle:

1. What if the H-PCE-CAPABILITIES TLV is present in an Open Object and the receiver does not understand it?
2. What if H-PCE capabilities were not successfully negotiated, but some H-PCE feature is included in a later message?

Both of these cases are certainly as you describe, but perhaps you need to be more explicit?

Perhaps...

OLD
   If the PCE does not understand an H-PCE path computation request as 
   specified in this document, the PCE will ignore the H-PCE related
   parameters, and behave as per [RFC5440].
NEW
   Section 7.1 of [RFC5440] requires that "Unrecognized TLVs MUST be
   ignored."  

   That means that a PCE that does not support this document but that
   receives an Open Message containing an Open Object that includes
   an H-PCE-CAPABILITIES TLV will ignore that TLV and will continue to
   attempt to establish a PCEP session. It will, however, not include the
   TLV in the Open message that it sends, so the H-PCE relationship will
   not be created.

   If a PCE does not support the extensions defined in this document but
   receives them in a PCEP message (notwithstanding the fact that the 
   session was not established as supporting a H-PCE relationship), the
   receiving PCE will ignore the H-PCE related parameters because they
   are all encoded in TLVs within standard PCEP objects.
END

---

In 3.3.1 you fixed up MBN nicely so that I can understand it. Thanks. 

Except that you have made the description work well for IGP areas/levels and not so well for ASes. In other words, you cope well with the situation where the domain boundary is on the node, but not well when it is on the link.
That is, to which domain does the inter-AS link belong? I should think that both ASes might consider it belongs to them and your algorithm might not count it at all. Alternatively, both might think it doesn't blong to them and you might count it twice.

Aren't you actually trying to minimise domain transitions (which is different from MTD)? Wouldn't it be easier to say so? This especially since the Metric in 3.4 counts domains. 

I could re-draft the description of MBN in line with this if that would help, but I don't want to do that if I have misunderstood your objective to "minimise the number of domain transitions". 

BTW s/D(Lpi) if/D(Lpi) is/

---

I can now parse 3.3.2 to answer my original questions ("How do you handle an H-PCE OF that conflicts with a regular OF?"), but I wish you had made it clearer.

Probably no further action on this point, but I am grumbling 😊

---

Finally, I think it is a shame to drop the Implementation Status information from the draft at this stage (i.e., before the IESG can see it). But I don't insist it is added back.


-----Original Message-----
From: Dhruv Dhody <[e-mail]> 
Sent: 06 December 2018 14:21
To: Daniel King <[e-mail]>; Farrel Adrian <[e-mail]>
Cc: [e-mail]; Dhruv Dhody <[e-mail]>
Subject: Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt

Hi Daniel,

Thanks for handling my comments, BTW page numbers are missing in the
table of contents.
Intrestingly that does not show up in id-nits [1] or mentioned in RFC
style guide [2], but anyways page numbers in ToC are useful :)

Hi Adrian,

Are you happy with the resolution of your comments?

Thanks!
Dhruv

[1] https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-hierarchy-extensions-07.txt
[2] https://tools.ietf.org/html/rfc7322#section-4.7
On Thu, Dec 6, 2018 at 1:25 AM <[e-mail]> wrote:
>
> Dear PCE'rs,
>
> Please find a new version of draft-ietf-pce-hierarchy-extensions (07) addressing comments from the most excellent Dhruv, our Document Shepherd.
>
> BR, Dan.
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: 05 December 2018 19:53
> To: Oscar de Dios <[e-mail]>; Daniel King <[e-mail]>; Fatai Zhang <[e-mail]>; Oscar Gonzalez de Dios <[e-mail]>; Quintin Zhao <[e-mail]>; Ramon Casellas <[e-mail]>
> Subject: New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt
>
>
> A new version of I-D, draft-ietf-pce-hierarchy-extensions-07.txt
> has been successfully submitted by Daniel King and posted to the
> IETF repository.
>
> Name:           draft-ietf-pce-hierarchy-extensions
> Revision:       07
> Title:          Extensions to Path Computation Element Communication Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)
> Document date:  2018-12-05
> Group:          pce
> Pages:          27
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-pce-hierarchy-extensions-07.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-pce-hierarchy-extensions/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-pce-hierarchy-extensions-07
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-pce-hierarchy-extensions
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-hierarchy-extensions-07
>
> Abstract:
>    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.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce