The MPLS-OPS Archive

[Robert Raszuk <raszuk@cisco.com>]

 > About RR'r, nothing stops you from meshing your
 > PE's to avoid the RR - not that is makes much sence, but you can
 > certainly do it.

Well actually it makes some sense to mesh BGP peers ;) Of course I would 
not recommend to do it by hand but with some automation tool.

> BGP - yes it scales well, but
> for signalling??  So a signalling packet hits the RR which then reflects
> that signal to each end point??  That's slightly silly in my mind

Isn't it the case that each "end point" in VPLS will require such a 
signaling information as topology is usually full mesh ? Isn't it also 
the case that for over 6 years we are sending from the same RR all 
L3VPNs routes to all client PEs just for them to drop it on the floor if 
not needed ? And yes although the company I work for does not share this 
opinion I personally like this label block hack Kireeti came up with. 
It's just few extra bytes on top of already required BGP based auto 
discovery which everybody seems to agree to support (except few Radius, 
AAA, DNS, LDAP based proposals :).

 > Also I believe that the
> RFC/IETF bods are nearly edging towards LDP as the signalling protocol for
> vpls and such and in that instance the companies who have been arguing over
> BGP being better than LDP will have to rethink their strategy.

I am not sure if much thinking is required :) IMHO they just need to 
support LDP for signaling as well and let the customer choose.

Cheers,
R.

PS. But I think moving away from turning WAN into LAN is a bit better 
solution. For long term scaling of 2547 I think CSC model will be the 
winner and very direct introduction to control and forwarding plans 
separation with out of band routing information exchange.


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