Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

[Ramon Casellas <[e-mail]>]

Dear PCERs,

Please see inline for my 2 cents...



El 19/07/2011 23:32, Wenhu Lu escribió:
> Thanks Dhruv for the summary.
> At least the authors of the two drafts have the same vision that 
> advertising OSPF area IDs will help PCE's multi-area path computation, 
> so that operators do not have to configure manually the list of 
> boundary routers.

To put it shortly, I agree that dynamic discovery of border nodes for 
the deployment of PCE based multi-domain path computation is desirable.

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.

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?


> 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.

> If we agree that automating the ABR provisioning is a good thing, 
> please be advised that the rationale and approaches of the two drafts 
> are quite different.
> draft-lu-ospf-area-tlv focuses on one thing, i.e. to enable CSPF to do 
> multi-area path computation with no need of manual ABR provisioning. 
> Here're several key points (please refer to the draft for detail):
> 1. An OSPF Area-ID-TLV is introduced. This TLV tells whether and how 
> CSPF can extend its LSP computation to across area boundaries.

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?

> 2. The originating point is OSPF's TE function. The TLV is kept under 
> OSPF TE extensions (like router-address TLV and link TLV). This is to 
> ensure that the ABR is an LSR capable of transit TE traffic. This is 
> important because an ABR is not necessary an LSR.
> 3. >From CSPF point-of-view, if the area-id info is readily available 
> in TED, CSPF's job will be easy (please see use-cases 1 and 2). It 
> doesn't need to talk to OSPF or other network components to acquire 
> ABR information. The change to CSPF is minimal.
> 4. It addresses only multi-area path computation. It does not address 
> multi-AS path computation.
Understood.

> draft-dhody-pce-bn-discovery-ospf is not tied with TE but kept 
> generic (some use-cases would be helpful). It focuses on both 
> multi-area and multi-AS. I believe the topic is also important.
>
Agreed

Thanks and best regards

Ramon