The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Apr> msg00257



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "Peter Ashwood-Smith" <petera@nortelnetworks.com>
  • Date: Thu, 27 Apr 2000 10:47:03 -0400
  • Organization: Nortel Networks

HANSEN CHAN wrote:
> 
> Peter,
> 
> > 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.
> 
> 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