Subject: RE: TE Extension of IGP and draft-ietf-mpls-te-feed-00.txt

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Mon, 24 Apr 2000 21:56:46 -0500

To be polite (but blunt). I believe you are wrong for the following reasons.

For a centralized solution to have accurate information it must gather
information from all nodes at approximately the setup/clearning rate of LSPs
in the network. This of course is impractical because the setup/clearing
rate may be 1000's per second during failure/resetup events.

A far more practical approach is to have all nodes aware of general trends,
via the normal OSPF/IS-IS floods and significant floods, and to then
feedback information along routes that are being used either successfully or
unsuccessfully. This allows those nodes that are sourcing LSPs to stay
fairly close to in sync with respect to the real network state, at least for
the slices through the network they are using. We have done considerable
simulation and implementation of this kind of approach and it works quite
well.

See the following draft for descriptions of how this works. I also have a
presentation that was given at the IETF that I can forward to anybody that
is interested. 

http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-00.txt> 

Oh, while I am at it, I am hoping to get a last call on this document ...
George, Vijay?

Cheers,

Peter Ashwood-Smith

	-----Original Message-----
	From:	MPLS [SMTP:[email-masked]]
	Sent:	Monday, April 24, 2000 10:46 PM
	To:	Chiu, Angela L, ALSVC
	Cc:	HANSEN CHAN; Daniel Awduche; [email-masked]
	Subject:	RE: TE Extension of IGP

	As far as my understanding of path computation goes, in online path
	computation scenario, which Dan mentioned is more likely to be the
case,
	what ensures that the ingress node(s) have a consistent view of the
	network, how do we make sure that IGPs have converged and each node
has
	correct topology as well as TE database ? 

	An offline tool i think "might" give a more realistic picture of the
	network resource allocation state at any time, correct me if i am
wrong. 

	Manish

	On Mon, 24 Apr 2000, Chiu, Angela L, ALSVC wrote:

	> Hansen,
	> 
	> See comments in line.
	> 
	> Angela
	> 
	> AT&T Labs
	> Room C4-3A22
	> 200 Laurel Ave.
	> Middletown, NJ 07748
	> Tel. (732) 420-2290
	> Fax (732) 368-1746
	> Email: [email-masked]
	> 
	> > -----Original Message-----
	> > From:	HANSEN CHAN [SMTP:[email-masked]]
	> > Sent:	Monday, April 24, 2000 6:17 PM
	> > To:	Chiu, Angela L, ALSVC
	> > Cc:	Daniel Awduche; [email-masked]
	> > Subject:	Re: TE Extension of IGP
	> > 
	> > Angela,
	> > 
	> > > I just want to add one other point. When a network operator
wants to use
	> > a
	> > > small set of LSPs to remove a few hot spots in the network
assuming all
	> > > other links having satisfactory performance, an offline tool
may be the
	> > > preferred way to identify which traffic trunks that contribute
to those
	> > > congestion points should be re-routed away from those hot
spots, and
	> > then
	> > > figure out what the new non-shortest path should be, and leave
all the
	> > rest
	> > > of the traffic on its normal shortest path.
	> > 
	> > If I understand the picture correctly, that offline tool should
do the
	> > following:
	> > 
	> > 1. collect statistics from the network and analyze network trunk
bandwidth
	> > utilization to understand where the hot spot is
	> > 2. compute the LSP paths (offline) with certain algorithm for
the optimal
	> > use of
	> > trunk bandwidth in the network
	> 	[Chiu, Angela L, NNAD]  Yes. As I pointed out before,
between your
	> steps 1 and 2, the offline tool needs to identify, for each hot
spot, a set
	> of traffic trunks that contribute to the congestion and need to be
rerouted.
	> 
	> 
	> > But as Dan said in his message, LSPs are more likely to be
computed
	> > online. I
	> > cannot see how a node can compute all LSPs for the whole
network. It might
	> > be
	> > able to do a good job for LSPs originating from itself. But for
LSPs
	> > originating
	> > from other edge LSR? I would think a offline tool is a better
place to
	> > plan for
	> > all LSPs.
	> 	[Chiu, Angela L, NNAD]  Actually, it is the ingress node
(the node
	> where an LSP originates) that is responsible for the path
computation based
	> on the link state information propagated via IGP extension.
	> 
	> 	Angela
	> 
	> > Cheers,
	> > Hansen
	> > 
	> > >
	> > >
	> > > As far as I know, all the online LSP path computation
algorithms
	> > provided by
	> > > the vendors are not capable of taking the normal IP traffic
into account
	> > > since the algorithms only see the bandwidth requirements from
traffic on
	> > > LSPs. If one has to use the online LSP path computation
algorithm,
	> > he/she
	> > > needs to use some offline tool to figure out the aggregate
bandwidth
	> > > requirement by the normal IP traffic on each link (excluding
the traffic
	> > > trunks that will be routed via LSPs), substract that from the
total
	> > > available bandwidth for that link, and make that the new
available
	> > bandwidth
	> > > for the online LSP path computation algorithm to use.
	> > >
	> > > Regards,
	> > > Angela
	> > >
	> > > AT&T Labs
	> > > Room C4-3A22
	> > > 200 Laurel Ave.
	> > > Middletown, NJ 07748
	> > > Tel. (732) 420-2290
	> > > Fax (732) 368-1746
	> > > Email: [email-masked]
	> > >
	> > > > -----Original Message-----
	> > > > From: Daniel Awduche [SMTP:[email-masked]]
	> > > > Sent: Monday, April 24, 2000 1:59 PM
	> > > > To:   HANSEN CHAN
	> > > > Cc:   Anoop Ghanwani; [email-masked]; Daniel Awduche
	> > > > Subject:      Re: TE Extension of IGP
	> > > >
	> > > > Hansen,
	> > > >
	> > > > Online LSP path computation is the preferred operational
model in many
	> > > > contexts -- for many good reasons.  Obviously, service
providers
	> > > > have the option to activate these aspects according to their
	> > > > circumstance and needs...
	> > > >
	> > > > As a simple rule of thumb, in networks with adequate
capacity, online
	> > > > constraint-based routing should suffice for LSP path
placement. In
	> > > > relatively under-capacitated networks, however, significant
	> > > > offline effort may be required to squeeze additional utility
from the
	> > > > infrastructure.
	> > > >
	> > > > Cheers,
	> > > > /Dan
	> > > >
	> > > > On Fri, Apr 21, 2000 at 11:06:08PM -0400, HANSEN CHAN wrote:
	> > > > > Dan,
	> > > > >
	> > > > > I agree that most MPLS implementations perform LSP path
computations
	> > > > online. But I
	> > > > > always thought the working LSPs deployed in the networks
are still
	> > > > computed
	> > > > > offline. You only use online computations when you're
	> > > > re-routing/repairing the LSPs
	> > > > > around some failure. Is my understanding correct?
	> > > > >
	> > > > > Cheers,
	> > > > > Hansen
	> > > > >
	> > > > > Daniel Awduche wrote:
	> > > > >
	> > > > > > Hansen,
	> > > > > >
	> > > > > > Yes, many (perhaps most) contemporary implementations
perform
	> > > > > > LSP path computations online. This is a mandatory
requirement
	> > > > > > in some operational contexts. It's also possible to
augment
	> > > > > > the online system with offline software tools.
	> > > > > >
	> > > > > > Cheers,
	> > > > > > /Dan
	> > > > > >
	> > > > > > On Thu, Apr 20, 2000 at 06:04:13PM -0400, HANSEN CHAN
wrote:
	> > > > > > > Dan,
	> > > > > > >
	> > > > > > > To make sure I understand. Do you mean the path of
LSPs is
	> > computed
	> > > > on the
	> > > > > > > node, not by software tools?
	> > > > > > >
	> > > > > > > Thanks,
	> > > > > > > Hansen
	> > > > > > >
	> > > > > > > Daniel Awduche wrote:
	> > > > > > >
	> > > > > > > > Actually, the original assertion/generalization is
false
	> > > > > > > > (i.e. that "LSPs in today's MPLS network are usually
computed
	> > > > > > > > off-node").
	> > > > > > > >
	> > > > > > > > Cheers,
	> > > > > > > > /Dan
	> > > > > > > >
	> > > > > > > > On Thu, Apr 20, 2000 at 02:08:22PM -0400, Anoop
Ghanwani
	> > wrote:
	> > > > > > > > >
	> > > > > > > > >
	> > > > > > > > > > I am trying to understanding the use of TE
extension of
	> > IGP in
	> > > > a MPLS
	> > > > > > > > > > network. From my understanding, you need TE
extension when
	> > > > you're doing
	> > > > > > > > > > on-node path computation. However, since LSPs in
today's
	> > MPLS
	> > > > network
	> > > > > > > > >
	> > > > ^^^^^^^^^^^^^^^^^^^^
	> > > > > > > > >
	> > > > > > > > > We're hoping it won't stay that way forever
because it's
	> > > > limiting
	> > > > > > > > > to have to rely on offline tools for all traffic
engineering
	> > :-)
	> > > > > > > > >
	> > > > > > > > > That means that traffic engineering would need to
be more
	> > > > dynamic,
	> > > > > > > > > and the routers would play a more active role in
determining
	> > > > paths
	> > > > > > > > > and possibly doing network optimization.  Hence
the IGP
	> > > > extensions.
	> > > > > > > > >
	> > > > > > > > > > are usually computed off-node (in software
tool), why
	> > would
	> > > > the use of
	> > > > > > > > > > TE extension be critical?
	> > > > > > > > > >
	> > > > > > > > > > Appreciate if someone can shed some light on
this
	> > question.

---

From: "HANSEN CHAN" <[email-masked]>
Date: Tue, 25 Apr 2000 08:06:24 -0400

Peter,

> information from all nodes at approximately the setup/clearning rate
> of LSPs in the network. This of course is impractical because the
> setup/clearing rate may be 1000's per second during failure/resetup
> events.

Other than initial setup/failure/resetup time, I do not think there will
be a huge amount of activities on the signalling plane. There might be a
few sporadic events in response to hot spots. Then following this
reasoning, the centralized solution should be able to have a pretty
accurate information of the network.

Comment?

Cheers,
Hansen

>
>
> A far more practical approach is to have all nodes aware of general
> trends, via the normal OSPF/IS-IS floods and significant floods, and
> to then feedback information along routes that are being used either
> successfully or unsuccessfully. This allows those nodes that are
> sourcing LSPs to stay fairly close to in sync with respect to the real
> network state, at least for the slices through the network they are
> using. We have done considerable simulation and implementation of this
> kind of approach and it works quite well.
>
> See the following draft for descriptions of how this works. I also
> have a presentation that was given at the IETF that I can forward to
> anybody that is interested.
>
> Oh, while I am at it, I am hoping to get a last call on this document
> ... George, Vijay?
>
> Cheers,
>
> Peter Ashwood-Smith
>
>      computation scenario, which Dan mentioned is more likely to be
>      the case,
>      network, how do we make sure that IGPs have converged and each
>      node has
>      > > > other links having satisfactory performance, an offline
>      tool may be the
>      > > > preferred way to identify which traffic trunks that
>      contribute to those
>      > > > figure out what the new non-shortest path should be, and
>      leave all the
>      > > rest
>      > > If I understand the picture correctly, that offline tool
>      should do the
>      > > following:
>      > >
>      > > 1. collect statistics from the network and analyze network
>      trunk bandwidth
>      > of traffic trunks that contribute to the congestion and need to
>      be rerouted.
>      >
>      >
>      > > able to do a good job for LSPs originating from itself. But
>      for LSPs
>      > > originating
>      > > > since the algorithms only see the bandwidth requirements
>      from traffic on
>      > > > requirement by the normal IP traffic on each link
>      (excluding the traffic
>      > > > trunks that will be routed via LSPs), substract that from
>      the total
>      > > > > offline effort may be required to squeeze additional
>      utility from the
>      > > > > infrastructure.
>      > > > >
>      > > > > Cheers,
>      > > > > /Dan
>      > > > >
>      > > > > > always thought the working LSPs deployed in the
>      networks are still
>      > > > > computed
>      > > > > > > > > Actually, the original assertion/generalization
>      is false
>      > > > > > > > > (i.e. that "LSPs in today's MPLS network are
>      usually computed
>      > > > > > > > > off-node").
>      > > > > > > > >
>      > > > > > > > > Cheers,
>      > > > > > > > > /Dan
>      > > > > > > > >
>      > > > > > > > > > > on-node path computation. However, since LSPs
>      in today's
>      > > MPLS
>      > > > > network
>      > > > > > > > > >
>      > > > > ^^^^^^^^^^^^^^^^^^^^
>      > > > > > > > > >
>      > > > > > > > > > to have to rely on offline tools for all
>      traffic engineering
>      > > :-)
>      > > > > > > > > >
>      > > > > > > > > > That means that traffic engineering would need
>      to be more
>      > > > > dynamic,
>      > > > > > > > > > and the routers would play a more active role
>      in determining
>      > > > > paths

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Thu, 27 Apr 2000 10:47:03 -0400

HANSEN CHAN wrote:
> > For a centralized solution to have accurate information it must gather information from all nodes at approximately
> > the setup/clearning rate of LSPs in the network. This of course is impractical because the setup/clearing rate may
> > be 1000's per second during failure/resetup events.
> 
> Other than initial setup/failure/resetup time, I do not think there will be a huge amount of activities on the
> signalling plane. There might be a few sporadic events in response to hot spots. Then following this reasoning, the
> centralized solution should be able to have a pretty accurate information of the network.
> 
> Comment?
> 
> Cheers,
> Hansen

  If you only have a few traffic engineered LSPs then you could even manually provision them
and not worry about even ANY signaling. When you design a routing protocol you have to assume
it is going to get used and on a large scale. Then, if you have done your design properly it
can extend to larger and larger scales without having to be redesigned or new versions put in the network. 

  When we are lucky enough to work on routing protocol design and code, we try to make it work
to the extreme limits of our abilities. This means distributed mechanisms with better more
accurate ways of getting topology data than simple flooding. These are good mechanisms that
scale and work well in relatively large networks. I am not aware of any other mechanisms that
scale as well. 

  I guess I don't subscribe to the "its good enough" model of design. I want to participate
in the design and implementation of things as close to perfect as I know how to make them.
I know it sounds corny but that's how these protocols should be designed, not just for
quick and dirty or short term profit reasons.

  Ok, off my soap box now ...

  Cheers,

  Peter