Hi Julien, My comments inline. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Julien Meuric Sent: Sunday, August 07, 2011 6:23 AM To: Ramon Casellas Cc: [email protected] Subject: Re: [Pce] [OSPF] IETF 81 WG Minutes
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, [wenhu] That is right. Router-level TE-enable info is too coarse. The draft covers the link cases exactly as your mentioned. the available bandwidth may not be enough, the SRLG/administrative groups may not suit... [wenhu] The intra-area CSPF is designed to handle these. The draft doesn't reinvent them. Thus the extension would only save very few crankbacks, and might not be worth the effort. [wenhu] Savings? Methods like BRPC doesn't even work and is blind in terms of following area sequence. Regards, -wenhu 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 _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
