IPLS & VPLS...

"Hamid Ould-Brahim" <[email protected]> Thu, 22 May 2003 15:39:38 -0400
Newsgroups gmane.ietf.ppvpn
Message-ID <[email protected]>
Eric,

[Catching up on my emails...]

> 
> 
> 
> Ali's  point is  that once  you have  deployed  a PE  which 
> can  do the  MAC
> learning in  the data plane, you  can always shut off  the 
> other unnecessary
> parts of  the VPLS service  (e.g., bridging control  
> protocols, sequencing),
> and you have the equivalent of an IPLS service.
> 
> This assumes that all the PEs on  which you want to provide 
> the IPLS service
> also provide the VPLS service.  It also assumes that the MAC 
> learning in the
> data plane  comes "for free", so that  there is no advantage  
> to shutting it
> off on certain ports and on certain pseudowires.
> 

Sure.

> It also overlooks the fact that  the IPLS is a true 
> multipoint service; like
> L3VPN, but  unlike VPLS, when  you receive a  packet from a  
> pseudowire, you
> don't care where it  came from because you don't have to  do 
> any MAC address
> learning  from  the packet.   Since  there  is  no 
> point-to-point  state  to
> maintain, the overhead is less and the service should be more 
> scalable. 
> 
> If  you think that  the main  requirement is  providing an  
> ethernet service
> which allows  you to transparently  connect bridged ethernet  
> networks, then
> you'll tend to think VPLS solves the  problem and IPLS is 
> just a niche which
> doesn't really merit its own architecture.  If, on the other 
> hand, you think
> that  the main  requirement is  providing  a lan-like  
> intetrconnect for  IP
> routers, and  that the  generalized ethernet service  is just 
> a  niche, then
> IPLS seems much more important, as VPLS is really overkill.
> 

Okay. The argument looks more that since VPLS and IPLS provides
the same service (for IP/host/routers), there should be
only one service that needs to be developed, and since VPLS 
interconnects as well switches, then VPLS is the right service to
follow for all cases. While in the IPLS case, the assumption is
that if the intent is really to interconnect routers, then VPLS 
functionality may not all be needed and IPLS can do the job.

Maybe the questions should be:

a) How many service providers will be deploying VPLS with
   the intent to just interconnect IP host/routers? 

b) How many service providers that intent/prefer to deploy first
   IPLS for IP host/routers and then later on VPLS for interconnecting
   switches/IP host/routers (on the same or different PEs)? 

c) How many SP will be deploying VPLS with the exclusive intent
   to interconnect switches?

No sure we can have all the answers, it will be good to have an
idea for what deployment scenario VPLS service will be used 
in general.

> I also don't see any reason why IPLS and "VPLS as restricted 
> to interconnect
> of IP routers" cannot be made interoperable. 
> 
> 

Yes, and I don't see why a provider that needs to deploy
both IPLS and VPLS (for whatever reasons) needs necessarily two 
distinct PEs.

Hamid.