Hi Huaimo, Dhruv,
I think this is an interesting and constructive discussion. Sorry for intervening as non-author for neither of draft, since I'm glad to see it go into deeper, technically. @Dhruv, from my reading, Huaimo is emphasizing "procedure" missing and "statically configuration". And you are saying "MAY carry" in PCEP-LS draft. Maybe a little more detailed explanation for procedure or protocol extension will help. Or missing does exist? So the WG can work on this? @Huaimo, on the other side, how does your draft solve "statically configuration"? Or better on that? Do I make any sense? Regards Eric ----------------------------------------------------------------------------- Date: Thu, 1 Sep 2016 11:03:38 +0200 From: Dhruv Dhody <[email protected]<mailto:[email protected]>> To: Huaimo Chen <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE Message-ID: <cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com<mailto:cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" 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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/pce > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mailarchive.ietf.org/arch/browse/pce/attachments/20160901/e7a65397/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ Pce mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
