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

From: <[email-masked]>
Date: Wed, 5 Dec 2018 19:54:47 -0000

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: [email-masked] <[email-masked]> 
Sent: 05 December 2018 19:53
To: Oscar de Dios <[email-masked]>; Daniel King <[email-masked]>; Fatai Zhang <[email-masked]>; Oscar Gonzalez de Dios <[email-masked]>; Quintin Zhao <[email-masked]>; Ramon Casellas <[email-masked]>
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

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 6 Dec 2018 19:50:40 +0530

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 <[email-masked]> wrote:
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: <[email-masked]>
Date: Thu, 6 Dec 2018 14:45:25 -0000

Doh! Indeedy, my script failed at the ToC generation! Will fix and upload a new version. 

BR, Dan. 	

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

Hi Daniel,

Hi Adrian,

Thanks!
Dhruv

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Dec 2018 18:47:40 -0000

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 <[email-masked]> 
Sent: 06 December 2018 14:21
To: Daniel King <[email-masked]>; Farrel Adrian <[email-masked]>
Cc: [email-masked]; Dhruv Dhody <[email-masked]>
Subject: Re: [Pce] New Version Notification for draft-ietf-pce-hierarchy-extensions-07.txt

Hi Daniel,

Hi Adrian,

Thanks!
Dhruv

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 7 Dec 2018 04:29:42 +0000

Hi Adrian, 

Thanks for your email, let me tackle a few.... 

Regards,
Dhruv

> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 07 December 2018 00:18
> To: 'Dhruv Dhody' <[email-masked]>; 'Daniel King'
> <[email-masked]>
> Subject: RE: [Pce] New Version Notification for draft-ietf-pce-hierarchy-
> extensions-07.txt
> 
> Hi Dhruv, Authors,
> 
> 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
> --
> 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.
> 
> 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
[[[Dhruv Dhody]]] I agree with your suggested wording, it is much clearer. 
> 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 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.
> 
[[[Dhruv Dhody]]] We want the PCC and child PCE to include this TLV in case they would like to use this PCEP extension, which includes various new information that can be encoded in PCReq from PCC towards the child PCE such as - RP object changes (section 3.2) and new OF codes and inclusion of TLV (section 3.3) etc. 

We would like this to be done on a PCEP session between PCC towards child PCE when we know that this child PCE understands the H-PCE extension as described in this document.

The setting of P flag (parent PCE request bit) means that the PCEP speaker wants the peer to be a parent PCE, so in the case of PCC_Child-PCE both parties do not set the bit. 

Dan, maybe we should we spell this out more clearly?

> 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."
> 
[[[Dhruv Dhody]]] Good suggestion. 
> 2. What if H-PCE capabilities were not successfully negotiated, but some
> H-PCE feature is included in a later message?
> 
[[[Dhruv Dhody]]] Thanks for the text, looks good!   
> 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".
> 
[[[Dhruv Dhody]]] I was assuming that when inter-domain link is encountered, it is NOT considered as part of the domain. 

.....AS100-----X---ASBR1---ASBR2---Y----AS200.....

D(Lpi = X-ASBR1) = 1 (because X-ASBR1 and ASBR1-ASBR2 belong to different domains)
D(Lpi = ASBR1-ASBR2) = 1 (because ASBR1-ASBR2 and ASBR2-Y belong to different domains)

So in case inter-AS it is counted twice, it is domain transition from my PoV. 

Could you think of a way to make this clearer? 

> ---
> 
> 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.
> 
[[[Dhruv Dhody]]] :)
> ---
> 
> 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.
> 
> 
[[[Dhruv Dhody]]] I put a note in the shepherd report, if that helps! 

> Thanks for handling my comments, BTW page numbers are missing in the table
> of contents.
> [1]
> https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draf
> t-ietf-pce-hierarchy-extensions-07.txt
> > Please find a new version of draft-ietf-pce-hierarchy-extensions (07)
> addressing comments from the most excellent Dhruv, our Document Shepherd.
> >
> > BR, Dan.
> >
> > To: Oscar de Dios <[email-masked]>; Daniel King <[email-masked]>;
> > Fatai Zhang <[email-masked]>; Oscar Gonzalez de Dios
> > <[email-masked]>; Quintin Zhao <[email-masked]>; Ramon
> > Casellas <[email-masked]>
> > Subject: New Version Notification for
> > draft-ietf-pce-hierarchy-extensions-07.txt
> >
> >
> > has been successfully submitted by Daniel King and posted to the IETF
> > repository.
> >
> > Title:          Extensions to Path Computation Element Communication
> Protocol (PCEP) for Hierarchical Path Computation Elements (PCE)
> > 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
> >
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Dec 2018 11:23:37 -0000

Brilliant! Thanks, Dhruv.

I think we are down to two points.

> [[[Dhruv Dhody]]] We want the PCC and child PCE to include this TLV in case
> they would like to use this PCEP extension, which includes various new 
> information that can be encoded in PCReq from PCC towards the child PCE
> such as - RP object changes (section 3.2) and new OF codes and inclusion of
> TLV (section 3.3) etc. 
>
> We would like this to be done on a PCEP session between PCC towards child
> PCE when we know that this child PCE understands the H-PCE extension as
> described in this document.
>
> The setting of P flag (parent PCE request bit) means that the PCEP speaker 
> wants the peer to be a parent PCE, so in the case of PCC_Child-PCE both
> parties do not set the bit.

Firstly, I wonder whether we are confusing ourselves (or I am confusing myself :-) with the terms PCC and child-PCE. Of course, in some senses the child-PCE acts as a PCC in its relationship with the parent-PCE, but it might help if we consider the strict three entities and relationships as: parentPCE----childPCE----PCC

Now, with the representation, we must ask why would a PCC ever use these extensions? You are suggesting that the PCC might want to use features such as the new OFs, and that is reasonable if we define these as "multi-domain OFs" and not actually anything to do with H-PCE. For example, if the PCC's PCE uses BRPC or any other magic, those OFs would still apply.

> Dan, maybe we should we spell this out more clearly?

OK. Now I understand what you want to do, it is relatively simple. What we need is a description (like we have arrived at above) of when and why a PCC might use these extensions, and a statement (like you just gave) that in those circumstances the PCC and the child PCE are not acting in parent-child relationship, but that the extensions are being used so that the child PCE may pass them on to the parent PCE.

That doesn't feel like more than one or two short paragraphs. Probably worth putting them in a new subsection "Applicability to PCC-PCE Communications" relatively high up the document.

> [[[Dhruv Dhody]]] I was assuming that when inter-domain link is encountered,
> it is NOT considered as part of the domain. 
>

Right, so your algorithm counts 1 for each ABR when there is a domain transition, and 1 for each ASBR when there is a domain transition. I see that this is counting “border nodes only when there is a domain transition” and is counting each border node. 

That works. It is slightly counter intuitive (to me) because I would have wanted to count domains (which this doesn’t do). But OK.

There is a potential issue in that you favour ABRs over ASBRs in this case. That probably doesn’t matter except for convoluted IGP area construction with virtual or pass-through links.

So, no change to this section needed. It is doing what you intended and my mistake was to try to make it do what I intended!

Thank you so much for this constructive engagement. I realise it comes very late in the process and so I am doubly grateful for your accommodation of my concerns.

Best,
Adrian