Subject: Re: [Pce] PCE - New Charter Proposal

From: [email-masked]
Date: Tue, 29 Mar 2011 11:02:47 +0100 (GMT+01:00)

Dear Ramon, all,

we also support the idea to extend the PCEP protocol with notifications for specific topology information.
This could be particularly useful in hierarchical PCE deployments and could also result in a vendor-independent way/mechanism/interface for feeding up routing info.

We're adopting this approach mainly for updating info about inter-domain TE links in the GEYSERS FP7 project (http://www.geysers.eu/). Moreover, the information feed-up via PCNtf seems to work well also for the dynamic update of additional TE information, e.g. related to power consumption of nodes and links (to be used to implement energy-aware routing) and network end-points.

Perhaps, this WG re-chartering could be the opportunity for progressing these discussions and try to converge towards common approaches.

Best regards,
Giada Landi

--
Giada Landi 
R&D - Solutions Architect
Nextworks S.r.l.
Via F.Turati, 43/45
56125 - Pisa - Italy
www.nextworks.it
--

----- Original Message -----
From: "Ramon Casellas" <[email-masked]>
To: [email-masked]
Sent: Friday, 25 March, 2011 18:50:05 GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Pce] PCE - New Charter Proposal

> example, we must fulfil PCE database by hand to provision ASBR 
> information, inter link connectivity, IP
> address of neighbour PCE, originating network prefix attached to the AS 
> and so on. I now that PCE database
(...)

> by avoiding to flood all PCE). So,I wonder if other peoples are 
> concerned 

(...)
> point couldbe added to the new PCE charter. The idea would be to define 
> a new protocol or extensions to the
> PCEP protocol

Dear Olivier, all

My 0.02 €, for what is worth

Until now, our main approach (also shared by other implementors, afaict) is either to behave as a passive OSPF-TE listener, to collocate the PCE in a node running OSPF, or to implement a (non-standard) interface (XML/SOAP) to request the TED from a topology server. 

ABR / ASBRs are "indentified" by parsing External / Summary LSAs (which means that not only AS/Area TE opaques must be parsed), along with the relevant CIDR prefixes (we assume that control plane nodeids and router addresses -- as in OSPF-TLVs -- are equal). Inter-AS OSPF-TE links are "learnt" by parsing InterAS new TLV (rfc5392), although only in the outbound direction. This has been "enough" to test BRPC and H-PCE in a multi-AS scenario, with reduced manual provisioning, but, as you say, in BRPC, PCE peers (along the prefixes / domains they are responsible for) are pre-configured at each PCE. In H-PCE, the mapping PCEs/domains/endpoints are announced in the OPEN with the parent.

However, when working on H-PCE, child PCEs cooperate to "build" the parent aggregated TED. In this sense, we have also implemented the possibility to wrap OSPF-TE (either full LSU packets or selected LSAs, including the advertising router) within PCEP using a non standard Notification type / value and TLVs (alternatively the TED "pieces" are encoded as XML and also wrapped in another TLV). CIDR Address prefixes for endpoint localization at the parent level are forwarded in ERO-like objects. This approach has worked on relatively well, -- and I would like to discuss it within draft-h-pce-pcep -- but I am still unsure whether it should be included in the charter or not (I would not object to it). I am not knowledgeable enough regarding IS-IS to elaborate.

I would also appreciate other PCE'rs feedback.

Best regards,
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 16 -- Fax. +34 93 645 29 01

-- 

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce