[Pce] PCE and (multi-domain) TED

[Ramon Casellas <[e-mail]>]

(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.: [phone] -- Fax. [phone]