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

Reply via email to