El 01/08/2011 6:16, JP Vasseur escribió:
On Jul 31, 2011, at 8:10 PM, Ramon Casellas wrote:
As detailed below, I tend to think there is a use case to be able to
dynamically map "TE enabled ABRs" and the domains (areas) they belong to.
Let's discuss this aspect. It was explained that there was a need to
know that a router was TE-enabled to avoid a signaling failure … how
is that different from other parameters ?
I'm afraid I don't understand the question, sorry :) Just in case, I did
not mean that TE enabled bit was needed. For simplicity, assume all ABRs
are TE enabled.
Second question is what can you do with the OSPF area ID ? I cannot
see any reason for knowing the area ID an ABR is connected to for
inter-area TE LSP computation ?
Thinking about it, it may not be strictly needed, although I was
thinking on corner cases such as the following. Consider the topology
below (paraphrasing parts of Section 1.2 RFC 3509), where an ABR has no
backbone connection
. .
. Area 0 .
+--+ +--+
..|R1|.. ..|R2|..
. +--+ .. +--+ .
. .. .
. +--+ .
. Area1 |R3| Area2 .
. +--+ +--+ .
. .. |R4| .
. . . +--+ .
....... .......
Being an ABR, R3 can only consider summary-LSAs from the backbone
when building the routing table (according to section 16.2 of
[RFC2328]), so it will not have any inter-area routes in its routing
table, but only intra-area routes from both Area 1 and Area 2.
Consequently, according to section 12.4.3, R3 will originate into Areas
1 and 2 only summary-LSAs covering destinations in the directly attached
areas. At the same time, router R2, as an ABR connected to the backbone,
will inject into Area 2 summary-LSAs describing the destinations in Area
0 (the backbone), Area 1 and other areas reachable through the
backbone. (...) This results in a situation where internal router R4
(or PCE) calculates its routes to destinations in the backbone and areas
other than Area 1 via R2. (Rcas: although this may be addressed with a
virtual link, as RFC3509 mentions later on)
So in our use case:
- R4 (or PCE) may want to compute an inter-area path towards some
endpoint at area1. It may also be requested to follow e.g. a domain
sequence within the IRO, listing areas 2 and 1. I would like a clean way
to consider R2 and R3 somehow differently. I believe here that knowing
the ABRs and the involved areas can be "a good thing" e.g. in minimizing
OF codes such as "minimum number of domains". of ocurse, if there is no
virtual link, I can deduce that R2 is attached to Area 0 since it is
announcing summary LSAs for Area0 and areas other than 1 but I cannot
rely on this.
- If PCE within Area1 does not support BRPC/VPST, PCE in Area2 could
explicitly select P2P paths from R3, selecting those ABRs that are
directly attached to Area1. Knowing that R2 is not directly attached to
Area1 allows PCE within area 2 to not request the R2 path.
- Knowing the area ids of the ABRs provides a simple mechanism to
somehow deduce a domain sequence and trigger the approporiate mechanism.
Finally, somehow unrelated but in a wider scope, I am still wondering
whether "deducing" things directly from summary LSAs rather that from
dedicated opaque information that clearly decouples control and data
plane is the right thing to do. Ideally (augmented) TED info should be
self-contained in opaques :)
Probably I am missing something, so I'd be happy to stand corrected :)
Thanks
R.
--
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
