The MPLS WG Archive

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



[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 and Hop by Hop Routed Traffic

  • From: jsullivan@quarrytech.com
  • Date: Thu, 24 Oct 2002 15:19:12 -0400
  • Cc: jsullivan@quarrytech.com



This is a question regarding LDP, which supports MPLS forwarding along
normally routed paths, 
and sections 4.1.3. and 4.1.4 of the MPLS architecture spec which describe
the rules for using the 
Hop by Hop path as the LSP, and when an LSR  is considered 
to be an LSP Egress for an address prefix respectively. 


Section 4.1.3 includes the following example: 
(assume that LDP running on R1, R2, R3)

Suppose, for example, that packet P, with destination address
   10.2.153.178 needs to go from R1 to R2 to R3.  Suppose also that R2
   advertises address prefix 10.2/16 to R1, but R3 advertises
   10.2.153/23, 10.2.154/23, and 10.2/16 to R2.  That is, R2 is
   advertising an "aggregated route" to R1.  In this situation, packet P
   can be label Switched until it reaches R2, but since R2 has performed
   route aggregation, it must execute the best match algorithm to find
   P's FEC.

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 ?


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.  

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