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