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

[Dhruv Dhody <[e-mail]>]

Hi Adrian, 

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

Regards,
Dhruv

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 07 December 2018 00:18
> To: 'Dhruv Dhody' <[e-mail]>; 'Daniel King'
> <[e-mail]>
> Cc: [e-mail]; Dhruv Dhody <[e-mail]>
> Subject: RE: [Pce] New Version Notification for draft-ietf-pce-hierarchy-
> extensions-07.txt
> 
> 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
> 
[[[Dhruv Dhody]]] I agree with your suggested wording, it is much clearer. 
> ---
> 
> 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.
> 
[[[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 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."
> 
[[[Dhruv Dhody]]] Good suggestion. 
> ---
> 
> 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
> 
[[[Dhruv Dhody]]] Thanks for the text, looks good!   
> ---
> 
> 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/
> 
[[[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.
> 
> Probably no further action on this point, but I am grumbling 😊
> 
[[[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! 

> -----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/draf
> t-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