The MPLS-OPS Archive

[Mathew Lodge <mathew@cplane.com>]

At 12:22 PM 7/9/2002 -0500, Christopher Lewis wrote:
>Matthew, I don't understand what you're saying here. We may  be talking at 
>cross purposes.

I'm not sure. The ideas that go into offline TE are fairly radical to many 
people because the way that routes have been computed in the Internet 
hasn't changed for the last 25 years or so. Cheap computing power and the 
software sophistication to make it simple to implement these alternative 
schemes also has not existed until relatively recently.

>Traffic engineering (to me at least) is about controlling how traffic 
>flows on your network. OSPF and IS-IS extensions allow those protocols to 
>communicate resource reservations made on a router.

Yes, the *extensions* communicate the resource reservations. But they are 
extensions to protocols that mandate the use of a single algorithm -- 
Dijkstra's -- to compute the paths in the first place. You can't separate 
the communication of the reservations from the path computation of OSPF and 
IS-IS.

>At 08:25 PM 7/8/2002, you wrote:
>>At 08:25 AM 7/5/2002 -0500, Christopher Lewis wrote:
>>>Plain MPLS or MPLS VPN will work fine with distance vector protocols 
>>>like EIGRP, but as mentioned a link state routing protocol is needed for 
>>>MPLS traffic engineering, as each node needs the topology information 
>>>those protocols provide and OSPF and IS-IS have the opaque LSA 
>>>extensions necessary for traffic engineering.
>>
>>To add to Chris' comments, note that this is for online "on the router" 
>>traffic engineering only. If you're doing off-line traffic engineering, 
>>any routing protocol that allows the control plane to operate will do.
>>
>>Three benefits that offline TE offers vs. OSPF/IS-IS TE:
>>1) You can implement a routing algorithm that does a lot better than 
>>Dijkstra shortest path. For example, you can minimize overall network 
>>utilization and avoid bottlenecks.
>
>MPLS TE using OSPF or IS-IS to communicate reserved resources does not 
>rely on the Dijkstra algorthim to compute a path.

No, they do force the use of Dijkstra's algorithm. OSPF and IS-IS construct 
the reachability graph for the network and compute the shortest path using 
Dijkstra's algorithm. The protocol messages allow the flooding of the 
network reachability information to all participating routers so that the 
graph can be constructed in the first place. In the "-TE" versions, 
resource reservations piggyback on the protocol messages. So, the process 
of computing the paths and communicating the reservations are intertwined 
in OSPF-TE and IS-IS-TE, and you can't just get the reservation capability 
without also getting Dijkstra's algorithm.

RSVP-TE is an example of a protocol that *just* communicates reserved 
resources. In offline TE, you figure out the path (using whatever algorithm 
you want), and then install it using the RSVP-TE explicit route object. In 
OSPF and IS-IS, there is no way to use some other algorithm for determining 
the best path. All you can do are set constraints such as resource class 
affinity, or tinker with path metrics. Constraints merely eliminate some 
number of paths from the input set to the Dijkstra algorithm -- they do not 
change the algorithm. Path metrics are summed by the Dijkstra algorithm for 
the purpose of determining which one is "shortest" -- they do not change 
the algorithm.

>>2) You can pre-calculate and install backup LSPs and ensure that there 
>>are no single points of failure, thereby dramatically improving LSP 
>>restoration time and guaranteeing resiliency.
>
>As you can with MPLS TE and have fast re-route handle swap overs in less 
>than 50 ms without operator intervention.

Yes, offline TE should support both since fast re-route and backup paths 
are complimentary technologies. You can view fast re-route as a fast "band 
aid" around a failure, with the backup path as the preferred longer term 
solution. Fast re-route is very fast but hard to control. Backup LSPs are 
slower to turn on (the failure needs to be signaled back to the head of the 
LSP before traffic can be switched over) but offer more control.

The problem with fast re-route is the lack of control. If you don't reserve 
the FRR paths in advance, there's no guarantee that FRR is going to keep 
your network running. You don't know if there will be enough bandwidth on 
the re-route path to carry the traffic, so you may end up dropping that 
traffic, as well as impacting other traffic carried by neighboring nodes. 
If you reserve all of the fast re-route paths in advance, you're going to 
waste a lot of bandwidth in backup paths that overlap and aren't used most 
of the time. The sub-50ms requirement comes from SONET's protection scheme, 
which is criticized because it wastes 50% of bandwidth for protection 
purposes. Pre-reserved FRR would be more wasteful than that because of the 
overlapping re-route paths.

Clearly, the solution lies with careful FRR path selection and reservation 
based on network demands and revenues, failure group information, and 
integration with a backup LSP scheme. You want management software to 
compute what that is based on your network design, operational  and 
financial criteria -- i.e. an easy to understand application that doesn't 
demand manual calculations and/or hand configuring data into every router 
in your network.

>>3) You can support LSP constraints that are non-additive in nature -- 
>>since shortest path works by adding hop metrics.
>
>As you can with MPLS TE using OSPF or IS-IS extensions, things like 
>affinity allow you to have the path include or exclude specified types of 
>links in the path selection process for example.

Resource class affinities are an example of a constraint that can be 
expressed in additive fashion. They result in the raising of some hop 
metrics to infinity. A counter example might help: what if you wanted to 
select the most reliable path, where you have to multiply reliability 
factors for each hop to calculate end-to-end reliability? You can't do that 
with an algorithm that insists on adding hop metrics.

Cheers,

Mathew

>>>>
>>>
>>>| Mathew Lodge                 | mathew@cplane.com     |
>>>| Director, Product Management | Ph: +1 408 789 4068   |
>>>| CPLANE, Inc.                 | http://www.cplane.com | 

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml