(moving to a new thread)
El 26/09/2011 16:22, Oscar González de Dios escribió:
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.
PCErs, all,
The current H-PCE draft on PCEP protocol extensions uses a form of
polling to locate an endpoint amongst the child PCE. As Oscar mentions,
I believe this is not / should not be the only option. We discussed
about this with Dhruv in Prague, IIRC.
In summary, regarding reachability we are again at the edge of "path
computation"/"TED management" and what is considered to be in scope of
the functions of a PCE. So the different options are:
i) Since both are different functions, maintain their strict separation.
A Parent PCE is able to map an endpoint to a given (child) domain. The
way it does this is out of the scope of the work in H-PCE. I would agree
that this seems to fit with the "philosophy" of PCE at least in the way
TED is managed. However, saying it is not in scope does not really solve
the problem ;) it simply moves it to another place....
ii) Allow, in the scope of H-PCE, to have the parent PCE "poll" children
to locate an endpoint. Personally I am unsure of the approach, specially
using a Path Computation Request / Response with some bit set which
magically means "I don't want to compute, just to find a node. The path
/ nopath and other attributes are meaningless". Without precluding that
the parent PCE may use some form of caching of endpoints and their
domain, it is not only the fact that relies on polling, but the fact
that uses a requests/response message exchange what somehow confuses me.
iii) Our proposal, since it was already proposed that the child PCE
could disseminate OSPF-TE encoded TE links wrapped in notifications,
reachability could also be managed this way. This is why in our tests we
simple add "ERO-like" TLVs that announce reachability using CIDR
prefixes within notifications. Maybe both ii) and iii) could be used
Finally,
iv) Start work regarding a unified way TED (specially TED in
multi-domain) is managed. This is the main / major issue that most of
the mails have been referring to lately, ranging from extending OSPF-TE
to disseminate Area IDs (draft-lu-ospf-area-tlv-01.txt) , extensions to
BRPC to have bidirectional TE information
(draft-wang-pce-inter-as-extentions-01), H-PCE InterAS, AS connectivity,
Border nodes identification, endpoint localization.... All this concepts
have in common the limitations of current visibility outside a given TE
domain. I guess a potential solution to this is what Olivier refers to
as "hierarchical TED" (?)
My personal preference, if we do not address iv) which is in itself
quite a significant work, would be iii) ii) and i) -- although I would
prefer other messages to be used in ii)
I am aware Dhruv et al. may prefer polling.
Thanks for reading
Ramon
--
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
