Thanks Ramon for the sharing. Regards, -wenhu ________________________________ From: Ramon Casellas [mailto:[email protected]] Sent: Thursday, July 21, 2011 4:50 AM To: Wenhu Lu Cc: [email protected] Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt
Wenhu, PCErs further comments tagged [Ramon] El 21/07/2011 1:06, Wenhu Lu escribió: ________________________________ From: [email protected]<mailto:[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
