Dear Wenhu, JP, Ramon and All,
I just wanted to add this - >From RFC 5441, section 4.2: Note that PCE(i) only considers the entry BNs of domain(i), i.e., only the BNs that provide connectivity from domain(i-1). In other words, the set BN-en(k,i) is only made of those BNs that provide connectivity from domain (i-1) to domain(i). If we want to follow RFC completely and correctly, PCE must select only those boundary nodes that provides connectivity between the domain (i-1) and (i), and this could only be done when PCE is aware of both the BNs and their connecting domains to make this decision correctly. Regards, Dhruv From: [email protected] [mailto:[email protected]] On Behalf Of Wenhu Lu Sent: Monday, August 01, 2011 10:01 PM To: JP Vasseur; [email protected] Subject: Re: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Hi JP and all, Thanks everyone for the comments and discussions regarding this ID during and after the PCE session. I agree with JP that we shouldn't make changes unless they are necessary or beneficial. I also agree with Ramon, Dhruv and Jonathan that we shouldn't settle on manual provisioning if we can do auto-discovery, and we shouldn't settle on brute force approaches if we can do things systematically. The discussion during the PCE WG session boiled down to the question: for inter-area path computation, is the "brute force" method good enough that the draft method provides little merit? Here the "brute force" means that a PCE can use OSPF type-3 LSAs to figure out the ABRs and the reachability to the LSP tailend and do path computation accordingly, regardless whether ABRs are TE enable, or which areas the ABRs are connecting to. If an ABR is not TE capable, it will be discarded later by the next PCE. Please correct me if my interpretation is wrong. My arguments are following (Ramon already explained a use-case of the area-id in an earlier email. Here I add to it a few more points): 1. In BRPC method, the area (domain) sequence will help accomplish the inter-area path computation. Nevertheless, knowing not the area-id, the "bruth-force" won't work with the area sequence. 2. The area-id TLV also implies ABR's TE capability. A typical OSPF topology is a backbone with many surrounding non-backbone areas. There can be many ABRs from the backbone's perspective. This means that without the ABR's TE info, the crankback method will have to spend long time to go through the list. This also means that the BRPC method will have to build a very fat-tree (VSPT). It cannot trim the tree by excluding the non-TE ABRs and non-related areas until the VSPT is passed to the next PCE. For a deployed LSP based network, the number of LSPs can be thousands. Considering the re-optimization, make-before-break, bypass and backup path computation, the scalability and computation efficiency are very important factors. The "brute force" apparently is not designed for such heavy computation tasks. It may quickly become the scalability bottleneck. 3. In terms of information propagation, the intra-area path computation is self-sustained. The PCE gets everything from the TED. For the inter-area path computation, the self-sustaining nature can be easily preserved with the addition of the area-id-tlv. In this sense, the "brute force" is not only slow, it has to resort to some "out-of-band" methods to acquire the ABR information. 4. To answer Abhay's question, RFC 5088 is for PCE auto-discovery. It is not for TE-ABR auto-discovery. As Ramon pointed out, they are orthogonal and complimentary. Thanks, -wenhu _____ From: [email protected] [mailto:[email protected]] On Behalf Of JP Vasseur Sent: Sunday, July 31, 2011 9:43 AM To: [email protected] Subject: [Pce] Fwd: [OSPF] IETF 81 WG Minutes Begin forwarded message: From: JP Vasseur <[email protected]> Subject: Re: [OSPF] IETF 81 WG Minutes Date: July 31, 2011 12:13:02 PM EDT To: Acee Lindem <[email protected]>, "Abhay Roy (akr)" <[email protected]> Cc: OSPF List <[email protected]> Thanks Acee, Just a feed-back on one ID after the PCE WG meeting: 8) Updates to OSPF TE Extension for Area IDs Slides draft-lu-ospf-area-tlv-01.txt - Wenhu Lu 10 minutes See slides Abhay: What were comments in PCE presentation? Wenhu: Good reception. Why do we need to know Area ID? Isn't it enough to simply know if ABR is TE enabled? Solution avoids "brute force" solution and produces faster convergence. Abhay: Discussed with PCE chairs. RFC 5088 - extensions for PCE. Look at those extensions to see if they can be used. Wenhu: Will do that. JP> The draft was discussed in the PCE WG meeting, but there was no consensus that this document provides an extension that addresses a use case for PCE. To be discussed on the PCE mailing list and we will keep you posted. Thanks. JP. On Jul 29, 2011, at 9:30 PM, Acee Lindem wrote: I've posted the IETF WG Minutes. Thanks much to Les Ginsberg for taking them. There was one ISP representative from Asia who commented but we did not get his name. If this was you, please unicast me and I will update the minutes with your name. Abhay and I will follow up with E-mails on specific documents presented at IETF 81. http://www.ietf.org/proceedings/81/minutes/ospf.txt Thanks, Acee _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
