The MPLS WG Archive[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
> 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 > > > > > > > > > |
|