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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
