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]<mailto:[email protected]>>
Subject: Re: [OSPF] IETF 81 WG Minutes
Date: July 31, 2011 12:13:02 PM EDT
To: Acee Lindem <[email protected]<mailto:[email protected]>>,
"Abhay Roy (akr)" <[email protected]<mailto:[email protected]>>
Cc: OSPF List <[email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
OSPF mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
