The MPLS-OPS Archive

["Gopal@Yahoo" <gnaganab@yahoo.com>]

you may consider:
1. Summerize the networks into IGP on the edge
routers.
Or,
2. Run Mpls TE Tunnels across the edge routers and
have the edge rtrs learn these lot-of-routes thru TE
tunnel(auto-route announce).
3.Ibgp---you already said this;-)

Rgds,
Gopal

--- Intae Jung <yjim@lge.com> wrote:
> Hello,
> I'd like to ask a couple of questions regarding a
> scalability of LDP, 
> especially when it is deployed in an ATM-LSR,
> adopting Downstream on
> Demand distribution with conservative label
> retension and ordered control,
> where labels (VPI/VCI) are a relatively scarce
> resource that must be conserved
> in ATM switch. The VPI/VCI is a particularly
> valuable and limited resource that 
> should be saved when an ATM LSR is not able to
> support VC-merging capability.
> Unfortunately the system I'm managing has no
> VC-merging capability.
> As defined in the standard, LDP attempts to setup or
> release a hop-by-hop LSP 
> whenever a new route is added or deleted in an ATM
> LER through routing protocols, 
> mainly IGP such as OSPF, ISIS or RIP.
> Let me assume a sample ATM-MPLS network as follows.
> 
> Network1 - R1 <-> LER1 <-> LSR1 <-> LSR2 <-> LER2
> <-> R2 - Network2
> 
> <---IP Network---><------------MPLS
> Network---------><---IP Network--->
> 
> R1, R2: Router operating IGP (OSPF or RIP)
> LER1, LER2: Edge ATM LSR operating LDP and IGP (iBGP
> if needed)
> LSR1, LSR2: ATM LSR operating LDP and IGP (OSPF or
> IS-IS)
> 
> OSPF or RIP is used in the IP Network and OSPF or
> IS-IS is deployed 
> in the MPLS Network. An i-BGP session could be setup
> between LER1 and LER2
> if needed, but not necessarily since LER1 and LER2
> are not supposed to provide 
> BGP/MPLS functionality, in other words, they don't
> work as a PE(Provider Edge) router. 
> LER1, LER2, LSR1 and LSR2 support only LDP as an
> MPLS signaling protocol.
> 
> The problem is that the number of LSP's from LER1 to
> LER2 increases
> as the number of networks increases in the Network2,
> meaning that the number of
> routing entries in LER1 increases accordingly,
> wherease the number of LSPs supported
> by LER1 is a lot smaller than the number of its
> route entries.
> Eventually, as the number of LSPs setup exceeds the
> maximum number of LSP's,
> we'll not be able to setup an LSP any more even
> though new routes are added.
> As I mentioned above, LSR1 and LSR2 don't support
> VC-merging capability, 
> thus the scalability becomes quite servere.
> Therefore w're trying to figure out how to support a
> lot of routing entries using
> a limited number of LSP's. We are trying to come up
> with a mechanism that setups 
> just one LSP between LER1 and LER2, which could be
> shared between all best-effort
> traffic between Network1 and Networks2.
> 
> The problem we faced is how to setup only 1 LSPs
> between LERs automatically, 
> and then how to map a lot of route entries to the
> shared LSP.
> Although two LER's are shown in the example, the
> number of LSP's between LER's
> can be quite large as the number of LER's increases.
> We're considering to setup a full-mesh iBGP sessions
> between all LER's, and
> to use BGP next hop gateway in order to get an
> FEC-to-NHFLE mapping.
> In other words, routes from Network2 will be
> redistributed to LER1 via iBGP session
> between LER1 and LER2, and then LER1 will setup just
> one LSP for the BGP next hop
> address and map all routes from Network1 to the LSP.
> However it enforces us to setup iBGP sessions
> between all of LER's even though
> we don't need them unless we deploy MPLS. We're also
> wondering whether
> we'll be able to solve the problem using any IGP
> capability, like tag field of AS-external 
> LSA in OSPF.
> 
> Please enlighten us on this issue. 
> Any experience or idea will be greatly appreciated.
> Thanks in advance.
> 
> Regards,
> 
> Jung.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-------
The MPLS-OPS Mailing List
Subscribe/Unsubscribe:  http://www.mplsrc.com/mplsops.shtml
Archive: http://www.mplsrc.com/mpls-ops_archive.shtml