Hi All,
Just to continue on this discussion, I wanted to mention that there is another school of thought that has been discussed by few of the authors of HPCE. The idea is to keep the Parent-PCE's topology graph free of BNs (Boundary Nodes) and inter-AS TE link; it being composed only of neighbor domain adjacency. In this case no flooding of BNs and TE-Links via PCNtf or Routing is needed. This is esp useful when Parent PCE is used only to get domain-sequence and BRPC is applied to get the end-to-end path. IMHO, I agree with Oscar that we should scope all the contributions/opinions based on multiple scenarios. There are two approach to find the domain of a given endpoint, as mentioned Ramón proposal where child PCE send addresses reachable in a its domain to the Parent PCE via PCNtf. Another method is polling done by Parent PCE, it can flood the request to all child PCE to find in which domain the endpoint lies. Regards, Dhruv *************************************************************************************** Dhruv Dhody, Senior Technical Leader, Huawei Technologies, Bangalore, India, Ph. +91-9845062422 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Oscar González de Dios Sent: Monday, September 26, 2011 7:52 PM To: Olivier Dugeon; Ramon Casellas Cc: [email protected] Subject: Re: [Pce] PCE and TED - was: Adoption of draft-king-pce-hierarchy-fwk-06 Hi Ramón, all... First of all, I would like to point out that we may differentiate several environments with different requirements for the multidomain problem. The PCE is scoped for any kind of network, from transport networks (OTN/SWON) with a rather limited number of domains, few interconnections, and few confidentiality issues, transport networks with a large number of domains, MPLS networks with several administrative domains, and big IP/MPLS networks with a large number of domains with peering agreements. For each of them, a different solution for the multi-domain path computation may apply. A solution may not be scalable for one, but perfect for another. In this WG, each of us has one particular scenario in mind... so we need to clearly scope all the contributions/opinions. In my case, I have in mind more the scenario of a transport network with a reduced number of domains. In each of the above scenarios, different level of information can be sent to the entity in charge of computing the end to end path. Thus, I would allow different levels of information exchange, always based on a standard approach, and let each network operator choose the one that better fits the needs for the particular case. Thus, there would be a trade-off between scalability and quality of the computed paths. Said that, if we feel that using current standards are too complex for one scenario, or are not sufficient, then I would support going for the necessary extensions, maybe not in PCE WG, but more in the routing related WGs. If we think that, it is just a matter of specifying how to use current standards to cover the different scenarios, elaborating an informational RFC would be the best solution. Anyway, I would decouple the needs of the PCEP protocol (that should be focused on providing a standard way to cover the needs of the interactions between PCEs of different domains, or between a H-PCE and PCEs of different domains, a common way of representing the multidomain path with different levels of detail) and how to fill the TED (that includes which information to send, e.g. summarized information, inter-as information, etc. and the protocol to exchange it). So... unless we see that using IGP for feeding the routing information to the H-PCE is like to crack a nut with a sledgehammer, I would avoid including in the PCEP protocol the routing information (even though it is easy to implement), but I agree on specifying how to exchange this information (with IGP or any other protocol) for particular scenarios. So... if we demonstrate that having a full IGP stack only brings interoperability problems, adds unnecessary complexity, consumes more resources and does not give additional value, I would support going to the simple approach of clearly specifying the LSAs to embed in PCNtf. We need to update soon the draft for the solution of the hierarchical PCE, so we must agree on these issues in order to have a common approach. Finally, I have another doubt... what about the reachability information when BGP is not used? Ramón proposed, in the scope of WSON networks, in an OFC research paper, to send the reachability information, that is the addresses reachable in a given domain, in a PCNtf as, e.g. IPv4 prefixes (in a BGP style). This information is needed by the PCE to know which is the domain of a given endpoint. Best Regards, Óscar >-----Mensaje original----- >De: [email protected] [mailto:[email protected]] En nombre de >Olivier Dugeon >Enviado el: lunes, 26 de septiembre de 2011 15:13 >Para: Ramon Casellas >CC: [email protected] >Asunto: Re: [Pce] PCE and TED - was: Adoption of draft-king-pce-hierarchy- >fwk-06 > >Hello Ramon, all, > >Thanks for your comment. I'm agree with you and I just try to reactivate the >debate too. > >IMHO, if we want PCE do a good job, i.e. not only finding the shortest path, >but also the one which fit optimally the request we need first to compute the >AS path to know with which PCE I will collaborate. This AS path is not >necessary the shortest one or the one provide by BGP. For such AS path >Computation, PCE needs suitable information i.e. at least TE of the peering >point. >Exchange such information is more a routing space and a problem of flooding. > >Now the question is: can we used existing protocol (IGP-TE are good >candidate) or do we modify PCEP for that purpose ? > >Regards, > >Olivier > >Le 23/09/11 10:55, Ramon Casellas a écrit : >> Dear Olivier, all >> >> Please see inline >> >> >> El 22/09/2011 18:22, Olivier Dugeon escribió: >>> >>> IMHO, I think that it is missing something in the different proposal >>> to compute inter-domain tunnel. This is related to the TED. Indeed, >>> there is no proposal to collect suitable information that could help >>> the PCE (in BRPC or in H-PCE) to select (compute) the AS path, and so >>> select the better (regarding the request) peer PCE. Such information, >>> like TE of the peering point between two ASs, are mandatory if we >>> want to select alternate AS path than the one announced by BGP. If >>> such mandatory information are out of scope of PCE WG, I'm afraid >>> that, for me, their is no difference between the BRPC and H-PCE, >>> instead on how PCE are cooperate. The result will be the same in term >>> of path computation. >>> >> >> As you may know, the issue of TED management and, in particular, TED >> management in the context of multi-domain path computation is raised >> regularly (including myself!) and no consensus seems to be reached. >> >> To some extent, I understand the (architectural and functional) idea >> of keeping TED management somehow decoupled from the actual path >> computation function, as it is done in the context of single domain >> path computation, where the way the PCE obtains the TED is out of the >> scope (and in some sense, orthogonal). >> >> However, I believe that in some cases both functions (path computation >> and TED management) are slightly coupled (border node identification, >> endpoint localization and topology aggregation for domain sequence >> selection, to name a few in which an IGP-based TED may not be >> sufficient). For what is worth, an approach that we proposed in the >> past (as well as other implementers) has been to use PCNtf with >> embedded OSPF-TE LSUs / LSAs (or XML files or any other encoding) TED >> "slices". >> >> This approach -- completely non-standard -- can be used for both >> wrapping and forwarding InterAS links [RFC5392] -- which, I agree with >> you, seems relevant for a more efficient selection of the AS path and >> would seem to address your requirement. This is briefly mentioned in >> Fatai's and Dan's draft-zhang-pcep-hpce -- the same approach can be >> used to wrap any other topological information. We did in a research >> project, including "virtual links or nodes" for topology aggregation >> (i.e. full-mesh) in H-PCE. In private communications I got the feeling >> that this is somehow "frowned upon" ;) and that AS peering and >> connectivity is managed at another (i.e. managed) level. >> >> >>> Is this make sense for the PCE WG and if yes, do you think it is >>> suitable to propose a draft for that purpose (we have some ideas for >>> that here) ? >> >> I am not against such a proposal, since it is easier and simpler to >> "stick to a common way of doing things", although it is difficult to >> decide and I would understand the WG position against it, if it was >> the case. Nonetheless I, for one, would be interested in hearing your >> ideas :) >> >> Thanks >> >> Ramon >> > >-- > >Orange > >*Olivier Dugeon* >FT/NSM/RD/CORE/M2I/CRM >Senior research engineer, QoS and network control >Phone/Fax: +33 296 05 2880/1470 >Mobile: +33 6 82 90 37 85 >[email protected] <mailto:olivier.dugeon@orange- >ftgroup.com> > >France Telecom > > >_______________________________________________ >Pce mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/pce Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
