Subject: draft-lasserre-vkompella-ppvpn-vpls as working group draft

From: "Rick Wilder" <[email-masked]>
Date: Thu, 10 Apr 2003 11:20:21 -0400

As noted in the minutes, at the San Francisco meeting strong interest
was expressed in pursuing the "draft-lasserre-vkompella-ppvpn-vpls" as a
working group draft. We agreed to finalize that decision only after the
WG participants who weren't there could have a say.
 
So, if there are opinions that have not been heard, now is the time, and
this list is the place. Let's set a one-week limit to conclude this
issue.
 
Rick
 
------------------------------------------------------------------------
------------------------------------------------------------------------
---
From the minutes:
 
Alex: For a document to become a WG draft, it doesn't have to be 100%
correct.  It can become a WG document if it is a good start.
Matt: I wanted to make the same comment.  
 
[snipped] 
 Marco: asked for show of hands to make this a wG draft. 
Strong interest was shown in room. Further discussion on the list.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 10 Apr 2003 19:48:16 +0300

> WG participants who weren't there could have a say.

there was also lots of support in s.f. regarding the radius discovery
draft and i got the impression that confirmation about its wg status was
suppose to happen after the meeting on the mailing list.  i have a new
version written, but i would like to publish it as a wg, rather than
an individual document.

-- juha

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 10 Apr 2003 10:27:13 -0700 (PDT)

Hi Rick,

If you are going down the path of progressing VPLS docs, could you
also test for consensus to make draft-kompella-ppvpn-vpls-01.txt a
PPVPN WG doc?

Thanks,
Kireeti.

---

From: "himanshu shah" <[email-masked]>
Date: Thu, 10 Apr 2003 15:28:41 -0400

Ditto for draft-shah-ppvpn-ipls-01.txt.

/himanshu

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Thursday, April 10, 2003 1:27 PM
To: [email-masked]; [email-masked]
Subject: progressing docs ...

Hi Rick,

Thanks,
Kireeti.

---

From: Ron Bonica <[email-masked]>
Date: Thu, 10 Apr 2003 22:39:42 -0400

Rick,

I would like to voice support for draft-kompella-ppvpn-vpls-01. If we use
BGP to distribute VPN information in L3VPNs, there is a certain
elegance in using the same tools to solve the same problem at lower layers.

                                        Ron

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Fri, 11 Apr 2003 15:14:40 +0900 (JST)

Rick and Marco,

According to your slide in the March meeting, L2 FW doc is requested
to review by IEEE 802.1 WG. How did they commented on the L2 FW doc?

IMHO, before moving forward, the WG should verify consistency with 
existing LAN/Bridge implementations and standards in architecture level,
because architecture level error is usually fatal and beyond recall,
as I pointed out in the PWE3 WG.

I thinks it is not late to decide/select something after we receive
comments from experts of LAN technology area.

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: Javier Achirica <[email-masked]>
Date: Fri, 11 Apr 2003 10:25:00 +0200 (MEST)

I'd also like to support that draft for the same reason.

Javier Achirica

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 12 Apr 2003 18:42:50 -0700

Ron,

> elegance in using the same tools to solve the same problem at lower layers.

I'd like to add my support for this as well.

Yakov.

---

From: "yuichiro wada" <[email-masked]>
Date: Mon, 14 Apr 2003 19:35:48 +0900

Hi,

I would like to add support for this draft as well, 
in order to advance further discussions on vpls specification.

---
yuichiro wada
NTT Communications

---

From: Eric Rosen <[email-masked]>
Date: Mon, 14 Apr 2003 13:00:52 -0400

Kireeti> If you are going down the  path of progressing VPLS docs, could you
Kireeti> also test for  consensus to make draft-kompella-ppvpn-vpls-01.txt a
Kireeti> PPVPN WG doc? 

I  think  this  document  is  a very  different  case  than  draft-lasserre-
vkompella. 

The Lasserre/VKompella  draft is  a valuable basis  for VPLS  work primarily
because of its  specification of the way the data plane  works for flat VPLS
and hierarchical VPLS.   The signaling it proposes to  use is basically PWE3
signaling, with some  extensions, and it is not  dependent on any particular
auto-discovery scheme.

I don't  think that  draft-kompella-ppvpn-vpls adds anything  significant to
the other draft's discussion of the  data plane, and we certainly don't need
two documents serving as the base specification for VPLS forwarding. 

Draft-kompella-ppvpn-vpls  specifies the  use  of BGP  as an  auto-discovery
protocol, which I think is fine.  However, BGP-based auto-discovery could be
used as well  with the PWE3-based signaling of the  other draft.  This piece
could be taken out and presented as a separate auto-discovery specification,
possibly incorporated into draft-ietf-ppvpn-bgpvpn-auto. 

The other area covered in draft-kompella-vpls is the specification of how to
use BGP  for use as a  signaling protocol to  set up p2p circuits.   I think
this is  a rather poor idea (BGP  as a mechanism for  p2p communication !?),
and  we should  not  accept it  as a  WG  document.  At  least, not  without
discussing the  pros and  cons in  some detail.  (I've  tried to  start this
discussion  several times  in  the past,  without  generating much  interest
either way.)

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 14 Apr 2003 11:22:43 -0700

Eric,

> two documents serving as the base specification for VPLS forwarding. 

The fact that the two drafts share the same data plane is a feaure,
not a bug.

> possibly incorporated into draft-ietf-ppvpn-bgpvpn-auto. 

Or it could be left in draft-kompella-ppvpn-vpls.

> this is  a rather poor idea (BGP  as a mechanism for  p2p communication !?),

On this we should probably agree to disagree.

> discussion  several times  in  the past,  without  generating much  interest

Perhaps the fact that it didn't generate much interest either way
could be taken as an indication of the *practical* relevance of
this discussion...

Yakov.

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 15 Apr 2003 18:49:58 -0400

Rick, Marco,
Before considering progressing VPLS solutions as WG drafts, I think it
is useful to understand how the different solutions meet the
requirements in
http://www.ietf.org/internet-drafts/draft-augustyn-ppvpn-l2vpn-requirements-02.txt
(at least for some of the basic LAN emulation service requirements, if
not all).

Ignoring some of these requirements may render a solution not useful to
end customers.
For e.g. if the following requirements are not met, an operator may not
be able to provide a functional service and as a result, some end
customers may choose to setup their own virtual private LAN instead, and
provider provisioned VPLS may not become as successful as hoped.
 
1) Traffic Looping 

                  +----------------                  
                  |                                    
               +------+                           
     +---------|  PE  |                  
     |         |device|                  
     |         +------+                  
  +------+         |                
  |  CE  |         |                  
  |device|         |   SP network     
  +------+         |                 
     |         +------+                 
     |         |  PE  |                 
     +---------|device|                  
               +------+                           
                   |                                   
                   +----------------                   
                  (a)    

If CE is a hub, does lasserre-vkompella support this valid configuration
requirement (to make the service more resilient to PE or MTU-S
failure)?  How to prevent traffic from looping in the e.g. above taken
from the requirements document? 
I think loop issues were first brought up in 2001, but it has not been
addressed.
(I don't think the answer is rate-limiting of customer traffic ;-)).

In the case of Hierarchical VPLS, the above configuration cannot be
supported either.
If this configuration cannot be supported, then if a PE-rs is down, all
CEs & MTU-S connected to the PE-rs are partitioned from the VPLS
network.

                  +----------------                  
                  |                                    
               +------+                           
     +---------| MTU-S|------------------PE-rs               
     |         |device|                    |
     |         +------+                    |
  +------+                                 |
  |  CE  |                                 |
  |device|            SP network           |
  +------+                                 |
     |         +------+                    |
     |         | MTU-S|                    |
     +---------|device|------------------PE-rs                 
               +------+                           
                   |                                   
                   +---------------------

For e.g. (if one were to attempt to use the above configuration
requirement for Hierarchical VPLS) :
Traffic will loop as well (for different customers connected to MTU-S
devices in this fashion) and VPLS cannot be enabled for these customers.
If however, the MTU-S are connected directly and the PE-rs removed, the
MTU-S (if they are IEEE 802.1d/q bridges) can form a spanning tree and
loops are avoided, i.e. the VPLS service can be enabled then. 
I think the fundamental problem here is PE bridges customer traffic but
have no means to prevent loops in the forwarding path.

2) Improper LAN Emulation
If a VC in a full-mesh failed and cannot be restored, CE routers in the
VPLS do not have a consistent view of all CE routers.

 CEA---PEA--------PEB---CEB
          \      /
           \    /
            \  /
             \/
            PEC
              |
            CEC

E.g. if the link between PEA and PEB fails:
If there are routers using the emulated LAN or if CEs are routers, then
I don't see how customer routing protocol like OSPF will work. CEA will
not see CEB, but CEC sees CEA & CEB, and vice-versa.
The consequence is that, I don't think CEC can route to CEA or CEB at
all if PEA-PEB link is down.
If STP is used instead of full-meshed reverse split horizon forwarding,
at least CEC can still route to CEB (and CEA, if PEA-PEC link becomes
active), i.e. at least some sites can still reach each other.

In the case of solutions using full-meshed including Hierarchical VPLS,
while a link/VC between two PEs is down or cannot be recovered,
customers VPLS services for all sites will become dysfunctional.
This will affect CE routers, CE bridges as well as MTU-S devices
operation. When it affects MTU-S devices, all customers VPLS with
connectivity  to the MTU-S devices will be affected as well.

In the above cases, full-meshed reverse split horizon forwarding is not
functional and the related solutions cannot be used.
I hope these issues will not be disregarded or trivialized because it is
unlikely end customers will. There are other important issues that need
to be addressed as well, but it's useful to understand how these
problems are handled to start with.

Thanks
Cheng-Yin

---

From: [email-masked]
Date: Wed, 16 Apr 2003 15:13:23 -0400 (EDT)

Cheng-Yin,

I see #1 as being a serious issue.  Many people in the VPLS community
believe that the CE device will always be a router running an IGP.  But as
we all know, customers may want to simplify the solution and cut their
costs by using a bridge or repeater.  This discussion is focused on
looping, but filtering database scalability is also an issue.

A problem with using spanning tree or rapid spanning tree is that some
service providers would not want an injection of BPDUs into their network
from customer sites.

The 802.1 working group is solving these problems with their new draft,
802.1ad, Provider Bridges.  Does this vpls internet draft plan to
reference that document?  My concern is that ppvpn will come up with one
solution and 802.1 will solve this in a different manner.  The problem is
that these 2 solutions are not mutually exclusive and will both be
implemented on many devices.

Thanks,
-Ben

----------------------

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Wed, 16 Apr 2003 17:18:44 -0400

Ben,

[email-masked] wrote:
> I see #1 as being a serious issue.  
The repercussion of #2 could be varied and may affect CE bridges too.
See Muneyoshi Suzuki's email on "Comments on the L2 VPN framework and
solutions documents", point #2.
If the LAN is not properly emulated (connectivity/reachability do fail,
and not just from link failures alone) and BPDUs are not received by
some CEs bridges, are loops not a possibility as well?

> Many people in the VPLS community
I agree filtering database scalability is also an issue, and the L2VPN
requirements doc do state that the L2VPN solution should be scalable
(some example numbers given) in this respect.

> service providers would not want an injection of BPDUs into their network
The BPDUs may not necessarily be injected into the provider's central
office network, but could be limited to (provider owned) customer
premises equipment, for lack of a better term.
OTOH, trying to prevent loops over multiple trees (independent customer,
providers forwarding paths, concatenated) may be more challenging.

> solution and 802.1 will solve this in a different manner.  
Well, there is IEEE bridging and there is PPVPN full-meshed
split-horizon forwarding.
> The problem is
I'll let you argue this one :-).
Perhaps you could also point to sections in 802.1ad which addresses the
issues being discussed here?

Thanks
Cheng-Yin

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 17 Apr 2003 15:40:14 -0700

Cheng-Yin,

The issues that you are bringing up in here are not just specific to our 
draft but also applies to other drafts (e.g., draft-kompella-vpls, 
draft-gvpls, ).

If you have attended the IEEE 802.1 meeting, you should know that the first 
issue has been discussed there (both in the meeting as well as the mailing 
list) and there are two parts to it (and you only mention one of them):
a) how does SP deal with customer loops
b) how does SP react to customer TCN

This issue is being addressed in within the 802.1ad and it is pertinent to 
bridging aspect of VPLS which is being handled by IEEE. So lets not confuse 
the issue in here. There are many things regarding VPLS that are not 
addressed by any of the drafts. VPLS is an end-to-end service (from 
customer uni to customer uni), IETF only deals with the provisioning of 
this service over MPLS/IP network. This service consists of bridging 
portion that is being dealt with IEEE. If you look at the l2vpn framework, 
the PE device consists of bridging module and "LAN emulation" module. What 
you are talking about will be taken care by bridging module by IEEE.
Also what you are suggesting (e.g., SP participating in customer's STP) is 
not the answer !!! and this is not the right forum to discuss it either. It 
should be discussed in IEEE.

Regarding the second point, of a PW failure without restoration, I find it 
very interesting that we can rely on failure recovery mechanism in bridges 
but not in routers !!! One thing that routers are good at, is to find 
alternate routes in case of link or node failure !!!

-Ali