The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2002-Oct> msg00139



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

LDP support for deaggregation as described in MPLS Arch MPLS an d Hop by Hop Routed Traffic

  • From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
  • Date: Thu, 24 Oct 2002 14:46:13 -0700

 
> 1. This example implies to me that an LSR must be able to support the
> ability to be both an egress and an ingress for the same FEC, in
> this case 10.2/16.   For example R2 must be the deaggregation
> point and thus the egress for 10.2/16, which will force a BMP
> lookup which may then match 10.2/16(because it didn't match 
> either of the more specific routes),  causing a labeled packet
> to be sent to R3.     
> Is my understanding of this correct ?

Yes. R2 must terminate the incoming LSP, do an IP lookup and
forward the packet in a new LSP.

> 
> 
> 2.  As a practical consideration it is worth asking under what
> conditions is it reasonable to expect an LSR to have knowledge of
> the routes in upstream LSRs, that would allow it to make the 
> correct decision regarding deaggregation for a particular FEC. 
> I would be interested in hearing what consideration was 
> given to this issue in real product implementations.

LSR2 does not need any knowledge of upstream LSRs. The decision
to aggregate/de-aggregate the routes is local to R2.

-Shahram
  
> 
> Possible Strategies: 
> a) Assume all LSRs have the exact same set of routes and 
> don't worry about deaggregation.  
> 
> b) Use route summary information to affect the deaggregation 
> decision.  
> Is this practical to implement ? 
> 
> c) other considerations ? 
>  
> 
>  
> thanks Jim 
> 
> 
> 
>      
> 
>    
> 
> 
>