Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

From: Dhruv Dhody <[email-masked]>
Date: Thu, 1 Sep 2016 11:03:38 +0200

Hi Huaimo,

You say...

   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.

[PCEP-LS]​ draft says...

   Further [RFC6805] describes Hierarchical-PCE architecture, where a
   parent PCE maintains a domain topology map.  To build this domain
   topology map, the child PCE MAY carry the border nodes and inter-
   domain link information to the parent PCE using the mechanism
   described in this document.  Further as described in
   [I-D.dhody-pce-applicability-actn], the child PCE MAY also transport
   abstract Link-State and TE information from child PCE to a Parent PCE
   using the mechanism described in this document to build an abstract
   topology at the parent PCE.​

Thus I respectfully disagree with your assertion. I think the confusion
for you might be because you are expecting a new set of procedures and
encoding to be used especially for the purpose of H-PCE from child PCE
to parent PCE. When there is no need for a *new* set of procedure and
encoding. The child PCE, acting as a PCC, is responsible for deciding
what information needs to be transported to the parent PCE, and in this
case can use the existing LS node object to carry boundary node
information and existing LS link object to carry the inter-domain
link. The LS node/link descriptor TLVs has information that will
identify that the node/link is boundary-node/inter-AS-link respectfully.

For ex, incase of inter-AS-link, the local node descriptor and remote
node descriptor will have different AS number clearly identifying that
the link is inter-AS.

I hope this clarifies the intention from the [PCEP-LS] point of view.

I do not have regular access to email this and coming week, so there
might be delay from my side in replying future post.

Thanks!

Regards,
Dhruv

On Wed, Aug 31, 2016 at 10:55 PM, Huaimo Chen <[email-masked]>
wrote:

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

---

From: Huaimo Chen <[email-masked]>
Date: Wed, 14 Sep 2016 15:43:20 +0000

Hi Dhruv,

     You said that

[I-D.dhody-pce-applicability-actn] is an informational draft. In this draft, there is not any concrete procedure that describes how to summarize multiple domains under a child PCE/controller (also as a parent PCE/controller of other child PCEs/controllers) by this child PCE/controller into one domain to its parent PCE/controller.

In my opinion, a procedure is a concrete procedure with enough details. In addition to not having complete concrete procedures for H-PCE in PCEP-LS draft, some data for H-PCE seemed missing. Note that some procedures and/or data for H-PCE were added into the PCEP-LS draft recently and after my drafts.

For example, the procedure about border nodes seems added on 8/30/2016 in version 05. See part of the diff screen shot below.

Best Regards,
Huaimo
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Thursday, September 01, 2016 5:04 AM
To: Huaimo Chen
Cc: [email-masked]; Dhruv Dhody
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

Hi Huaimo,

You say...

[PCEP-LS]​ draft says...

Thanks!

Regards,
Dhruv

On Wed, Aug 31, 2016 at 10:55 PM, Huaimo Chen <[email-masked]<mailto:[email-masked]>> wrote:
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

_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce

---

From: Dhruv Dhody <[email-masked]>
Date: Sat, 17 Sep 2016 08:51:55 +0000

Hi Huaimo,

Sorry, I took a few days to send you this reply.

I think we have a disagreement on what needs to be in a draft/RFC to let border nodes and inter-domain links be sent from a child PCE to parent PCE.

(1)    The most important for the standards is to have the encoding and message formats and what change in the protocol is needed to accommodate this.

(2)   The secondary is what you call “concrete procedures”.

Let me tackle them one after the other.

As you can note that the message/objects/TLV/sub-TLV and the mode of operations defined in the PCEP-LS can be used without any change to also encode border nodes and inter-domain links. There is no change needed in what was already defined in PCEP-LS from the start.

Now for (2) , the draft describes how any PCEP speakers can use PCEP-LS. It describes what new operations, the PCEP speakers need to do. IMHO there is no need to define any new procedures when it comes to parent and child PCE as there is no change in the protocol. This is just another use case/deployment and  warrant no new procedures. What I added in the latest version was an example in the appendix to explain the usage. Please also see inline….

From: Huaimo Chen
Sent: 14 September 2016 21:13
To: Dhruv Dhody <[email-masked]>
Cc: [email-masked]; Dhruv Dhody <[email-masked]>
Subject: RE: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

Hi Dhruv,

     You said that

[Dhruv] I don’t understand why this should be in the draft.
How the summarization (or abstraction) is done is internal to the PCE and doesn’t need to be standardized. If this PCE is responsible for multiple domains, it is under its purview to decide if it “summarize” it into a single domain or keep multiple domains as well as apply local policy decisions. Why do you think we need to spill this out? You can also check RFC7752 and it only describes the standard track changes required on the wire and protocol for any BGP speaker that’s all.

What matters is if the PCE choose to summarize, can it send that information via the PCEP-LS messages/objects/TLVs? And the answer is resounding “yes”!

[Dhruv] We have been able to implement PCEP-LS in H-PCE using the draft with no issue, we plan to show this during the IETF 97. If you feel some changes are required I hope you could provide us with the suggestions and we will incorporate them.

I am not sure if it matters, but as you can clearly see in the below screenshot, what is added is a clarification stating that the same procedures which were already defined in this document can be used as it is. These are not “some procedures and/or data for H-PCE “ that is added later. Our claim itself is that we need no new procedure and/or data for the specific case of H-PCE!!!!

I did not modify anything as far as (1) is concerned. No change in PCEP message/object/TLV/sub-TLV or mode of operations. I added a few sentences to make it *clear* that it is also applicable to H-PCE/ACTN. In my view that was enough and it makes it clear that we really don’t need a new set of messages/objects/TLV/sub-TLV for a specific use case where child PCE to parent PCE transports the border nodes and inter-AS links.

Thanks!
Dhruv

Best Regards,
Huaimo
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Thursday, September 01, 2016 5:04 AM
To: Huaimo Chen
Cc: [email-masked]<mailto:[email-masked]>; Dhruv Dhody
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

Hi Huaimo,

You say...

[PCEP-LS]​ draft says...

Thanks!

Regards,
Dhruv

Best Regards,
Huaimo