Wenhu, PCErs
further comments tagged [Ramon]
El 21/07/2011 1:06, Wenhu Lu escribió:
------------------------------------------------------------------------
*From:* [email protected] [mailto:[email protected]] *On Behalf
Of *Ramon Casellas
*Subject:* Re: [Pce] New Version Notification for
draft-lu-ospf-area-tlv-01.txt
To date, we rely on either static provisioning, or dynamic parsing of
external / summary LSAs, identifying advertising routers as either
ABRs or ASBRs. I browsed both drafts and I tend to agree that one of
the main drawbacks of this approach is that the control plane
addressing, etc and the TED are not clearly separated, relying of
router address TLVs to map the advertising router; other details are
given in draft-lu-ospf-area-tlv-01 Section 3.2.
[wenhu] Curiously which component is doing the parsing?
If it's CSPF, there will be quite bit of work.
Or if it's OSPF, how is the result passed to CSPF?
[Ramon] I'm not sure we are doing something terribly complicated or hard
:) in its simplest form, the PCE carries out stateful inspection of
OSPF-TE packets that it can "capture" (sent by other entities, sniffing
the network, via process API, or as an OSPF-TE listener, it's quite
open actually), in order to construct an in memory directed graph (TED)
on top of which perform computation. From the PCE perspective, OSPF-TE
is just one of many ways to get the TED. Basically it proceeds by
parsing the Link State Update packets (discarding the rest), and the
LSAs found within. At the beginning (Single domain) we only parsed e.g.
area / opaque LSAs, but when we started with multi-domain, we started
parsing summary LSAs, ASBR summary LSAs and AS external LSAs. For
summary LSAs, the prefixes announcing "reachability" are parsed with
their metrics etc. getting the masks from within the summaries.
Consequently, from within the PCE, the advertising router is then marked
as a "border node" (ABR or ASBR depending on the LSA type). The PCE kees
thus information on border nodes and reachability, used in BRPC and H-PCE-
As you may guess, some issues arise, solved mainly by the congruent
topology, the 1:1 relationship between GMPLS controller and data plane
node and the fact that we use a single address for advertising router
that corresponds to the Router Address TLVs (ROuter ID, Node Id or
similar names). Otherwise, we are considering latest Andy Malis RFC on
ASON routing.
However, I foresee that the same questions can arise, later on,
regarding reachability of endpoints located in other TED domains. If
one wants to decouple ABRs as advertised within OSPFv2 LSDB and TE
border nodes, would it be reasonable that external / summaries be
decoupled too?
[wenhu] I couldn't agree with you more on this. And IMHO the complete
way of decoupling is not to use external (or summaries) routes for TE
purpose. The external routes may or may not be qualified for TE
reachability. Further the external routes may be multi-homed.
But how can we do multi-AS path computation if we don't use the
external routes ? This is an interesting topic. We can discuss this
offline if you wish.
[Ramon] I'm open to this, it may be a new point for a future re-charter,
but I'm not sure the scope / WG. It has of course strong links with ASON
routing and CCAMP. I fully agree that to enable multi-domain path
computation amongst collaborating PCEs, we need to decouple control
plane and data plane, where the TED refers to the later. Although the
scope of Path Computation seems naturally fitted to a single TE domain,
collaborating mechanisms require somehow "extending" this TED with exit
/ entry points and the relationship with other (at least neighboring
domains) and doing this by virtue of mapping with control plane
identifiers or OSPFv2/BGP reachability may be improved?
PCEers, please voice your opinions whether it's a good idea to
automate the discovery of the OSPF area IDs.
As stated, a mechanism by which a PCE is able to know in which area(s)
is located, and border nodes is desirable. I guess my main comment is
a question; would it be appropriate to generalize this e.g. to Areas
and AS? I do not object to having one draft for the ABR / OSPF-TE
case, but when possible, I would like the PCE architecture to apply to
multi-domain in general, to have a unified approach, both for the
multi-AS (i.e. with inter-domain links) and multi-Area (i.e. with
ABRs) and to treat "TE domains" generically. In other words, how can
we "extend" a TED with automated information enabling multi-domain
path computation - topology and reachability-, generically, while
mantaining a clear separation of control plane and TED.
[wenhu] I'm with you. A unified approach would be ideal. But it may
not be easy to find one shoe that fits all.
[Ramon]The multi-area context ba be a good start
I still have doubts regarding wheter this needs to be a top TLV
(draft mentions RFC3630 section 2.4). What would be the relation with
e.g. RFC4970?
[wenhu] I received some suggestions to place this TLV to under
rtr-address-tlv. I'm open to this part.
RFC4970 is big umbrella that covers all (OSPF router
capabilities). It may serve well to the multi-domain case. For
multi-area purpose I think the proposed ospf area tlv offers a simple
and feasible solution.
[Ramon] No strong opinions, I guess we just need to identify
possibilities and get a consensus on the actual encoding
Thanks and 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 00 -- Fax. +34 93 645 29 01
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
