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

From: [email-masked]
Date: Thu, 24 Oct 2002 15:19:12 -0400

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

---

From: Shahram Davari <[email-masked]>
Date: Thu, 24 Oct 2002 14:46:13 -0700

> 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.

> 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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 24 Oct 2002 18:23:59 -0400

Jim,
 
-> > 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.

 Addition to what Shahram said, this is "a kind of" LSP stitching.
 As the LDP and RSVP-TE standards stands, LDP can establish
 a single LSP (with out stitched) from one routing to
 another domain (for example, different ISIS levels or OSPF areas).
 But when it comes to aggregation (here in the above example)
 if R2 is an L1/2 or ABR router then the LSR is internally
 split into egress LER and ingress LER to stitch the LSP across
 routing domains. It is a normal convention, at least people think,
 that the LSP stitching is applicable only in TE environments only
 using RSVP-TE (again, because, RSVP-TE as it stands now can't 
 do TE across different TE domains)

 Cheers.
 
--
Venkata