Hi Ramon.
My interference below.
Cheers,
Julien
Le 01/08/2011 10:11, Ramon Casellas a écrit :
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.
I think JP was referring to the discussion in Quebec. (If you missed it
like me, audio archives may help to catch up.)
During the meeting, it seemed that "there was a need to know that a
router was TE-enabled to avoid a signaling failure". If it is not known
a priori, it is discovered at signaling time and crankback may be used.
Nonetheless, knowing that the ABR is TE-enabled is not enough: the links
to the destination may still not be TE-enabled, the available bandwidth
may not be enough, the SRLG/administrative groups may not suit... Thus
the extension would only save very few crankbacks, and might not be
worth the effort.
But I note that this is not the use case you have in mind.
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)
Thanks for providing this. If you believe this is an actual use case, it
may be relevant to the Wenhu's I-D. You also mentions 2 significant
things: it might be a corner case and existing solutions may already be
enough...
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.
It looks like there a lots of assumptions here. Per area-PCE function
out of ABRs? If so, why using PCE? The PCE architecture already provides
some solutions to that problem: PCE-capable ABR, virtual link between
PCE and remote areas... Before moving forward, I think the context
should be elaborated.
- If PCE within Area1 does not support BRPC/VPST,
This reads to me like "if the existing solution is not supported, let us
define a solution". :-) Both scenarios would require upgrade, so what
motives another one?
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.
So it seems that it would help in reducing the number of requests to be
sent. But what if, instead of R3, we have R3a and R3b? It would not help
here, while VSPT does.
- Knowing the area ids of the ABRs provides a simple mechanism to
somehow deduce a domain sequence and trigger the approporiate mechanism.
I like "simple". But adding a simple extension to address corner cases
is still introducing complexity somewhere... Currently, the question is
on the use cases for advertising area IDs: there might be some, but they
are not obvious to me yet.
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 :)
Opinions from others about this issue would be valuable.
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
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
