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

[Wenhu Lu <[e-mail]>]

Hi Ramon,
Thank you for your review and sharing. Please see my comments inline [wenhu].


________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ramon Casellas
Sent: Wednesday, July 20, 2011 12:10 AM
To: [e-mail]
Subject: Re: [Pce] New Version Notification for draft-lu-ospf-area-tlv-01.txt

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

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

Regards,
-wenhu


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