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
