[Tony Li] : RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Non-member post.

> Subject: Re: RE : Last call for draft-ietf-tewg-interarea-mpls-te-req-01.txt 
> Date: Thu, 27 May 2004 12:44:00 -0700
> To: "LE ROUX Jean-Louis FTRD/DAC/LAN" <jeanlouis.leroux@francetelecom.com>
> X-Mailer: Apple Mail (2.618)
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com
> X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS 
> autolearn=no version=2.63
> X-Spam-Level: 
> 
> >> As an example, I would like to be able to leak detailed topology
> >> information from
> >> my IS-IS L2 database down into an L1 area.  I would NOT want to leak
> >> bandwidth
> >> information.
> >
> > I don't see the gain, as regards inter-area TE,
> > in leaking detailed topology information from L2 into L1 without 
> > leaking any bandwidth information...
> >
> 
> 
> The gain is that the bandwidth information is in continual flux, and 
> leaking
> that just sloshes L1.  Plus, by the time signaling gets there, the 
> information
> will likely be out of date.
> 
> Combine this with the fact that the primary reason to use this 
> information
> is to ensure an optimal exit from the L1 area, and there doesn't seem 
> like
> a real need to worry about instantaneous capacity.
> 
> Again, what I'm suggesting is just an example of one overhead vs. 
> optimality tradeoff.
> 
> 
> >> I would want to leak an abstraction of another L1 area
> >> down into an
> >> L1 area, but I would definitely want that to be an
> >> abstraction, NOT the
> >> full
> >> database.
> >
> > Of course, else you come back to a single area network !
> > But IMHO such abstraction, to be useful, i.e. to allow computing an 
> > inter-area TE path,
> > would require to take into account a large set of constraint 
> > combinations,
> > and this would likely lead to major impact on IGP scalability.
> >
> 
> 
> You're making the assumption that the head end of the LSP is computing 
> the entire
> path.  Again, I'm advocating a somewhat different position (ala 
> Nimrod): the path
> is computed with more refinement as you get closer to the destination.  
> The
> head end might be able to provide an explicit path through the 
> originating L1
> area, and based on its L2 topology information, it might select the 
> exit point
> from that area.  However, the L2 router would be responsible for 
> computing
> the remainder of the path, and the L2 router would have current 
> information
> about L2 and some topology information about the destination L1 area.  
> It
> might compute a path that transits L2 optimally and also selects the L2
> exit router.  The L2 exit then computes an optimal transit of the L1 
> destination.
> 
> By chaining together 3 locally optimal paths, we will NOT achieve global
> optimality, but we will get a good first approximation for a fraction
> of the cost.
> 
> 
> > Not so sure, there are schemes that allow computing an optimal 
> > inter-area path without adding any byte in LSA/LSP...
> >
> 
> 
> Which would take us back down the crankback path.  No thank you.
> 
> 
> >> Tony
> 
> 
> 
>