Subject: RE: Draft charter for L2VPN - IPLS & ARP Mediation

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Thu, 15 May 2003 16:49:01 -0400

Ali,

> 
> IPLS has been designed and optimized for VPLS-challenged PE 
> routers. In 
> other words, PE routers that perform IPLS are not expected to 
> perform VPLS 
> functionality.
> 

Not sure I understand your conclusion. IPLS looks designed for 
IP-based CEs. I am not sure why a PE that provides IPLS service 
cannot provide as well VPLS service to other CEs 
(for example LAN switches) - if that PE can handle both -. 
The operator has the choice anyway given the situation and
what functionality is supported on that PE.

> All I want to do is to make sure that operators are O.K. with 
> it. In other 
> words, to have one PE for IPLS functionality and another for VPLS 
> functionality. 

If an operator plans to provide IPLS or VPLS
wouldn't she/he engineer the PE to meet the vpls/ipls requirements?

>In cases that the operator doesn't need to offer VPLS 
> functionality, then all they need is an IPLS-capable PE. I 
> just want to 
> confirm if that's what the operators expect.
> 

You may be asking fair question, I just don't see why an
operator needs two distinct PEs if it needs to
offer both IPLS and VPLS?

Looking at the IPLS draft, I may agree with you that there
is too much emphasis that an IPLS-capable-PE is a PE
that cannot provide VPLS service while in fact - in my
opinion - it should state that if an operator knows apriori
that the CEs are all IP host/routers, then an IPLS like
service may be offered (to what extent it simplifies/optimize
the PE compared to VPLS service needs to be known)...and IPLS 
(as Steven pointed out) is considered just additional tool in 
an operator toolbox (unless in your question you wanted 
to refer/point to something else).

Hamid.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 16 May 2003 09:53:28 -0400

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.

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.

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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 29 May 2003 09:17:20 -0700

This is a reminder that charter-related threads are being
redirected to the l2vpn and l3vpn specific mailing list.

See my message "Decision on work split" on May 23rd, 2003
for more info on the mailing lists.

Alex