Subject: RE: Comments on the L2 VPN framework and solutions documents

From: Joris wils <[email-masked]>
Date: Mon, 21 Apr 2003 10:16:40 -0400

Muneyoshi,

>I think there is a much simple and robust solution. Connect Provider
Bridges
>with point-to-point LSPs and use STP/RSTP in the network, and don't use 
>split-horizon scheme. Needless to say LSPs must be raw mode; tagged mode
>violates the standard. 

>In this case, if PEs are connected with full mesh LSPs, reliability of a 
>single PE is:

>1- {(1- R^2) ^ (N -1)}.

>Obviously, this is a robust solution because it use LSPs as parallel
system.
>Furthermore, this does not need to revise the existing standards, it only
>needs Q-in-Q or MAC-in-MAC specification in 802.1ad.

Please verify my understanding: are you proposing that vendors add Bridging
to their MPLS devices; Bridging over MPLS as it were, MPLS is the Transport.
correct?  If so, I have noticed, that vendors are quietly adding Bridging to
their ATM, Frame and TDM devices as well.  802.1ad could interconnect all
these devices, regardless of which media they use as the Transport.  

My question is: how do you deal with (portions of) the network, for which a
spanning tree would be a very inefficient forwarding means, because the
physical topology does not approximate a tree?

Thank you,
Joris Wils 
Consulting SW Engineer
Coriolis Networks
[email-masked]/978-264-1904x667

---

From: "Per Hansen" <[email-masked]>
Date: Mon, 21 Apr 2003 19:43:48 +0200

Your comment seems valid - there are always good and bad.
However on the other hand just using standard L2 bringing over 
LSPs is very simple and in some way straight forward because:
  
*  it just adapt to probably the most installed standard
in the world. 
*  The learning curve is simpler for everybody
*  Network Administration of Bridges are probably simpler
*  The development effort can be held on a minimum, known
   technology in combination with MPLS,
*  Silicon solutions can probably come faster to market and
   drive the cost down.
*  Virtual MAC switches can be provided with aggregation
   using MPLS labes via same links.
*  L2 Protocol software can faster be adapted.
*  Even LSPs can be setup by operator configuration, not 
   signalling.

-----Original Message-----
From: Joris wils [mailto:[email-masked]] 
Sent: 21. april 2003 16:17
To: 'Muneyoshi Suzuki'; [email-masked]
Cc: [email-masked]
Subject: RE: Comments on the L2 VPN framework and solutions documents

Muneyoshi,

Bridges

system.
>needs Q-in-Q or MAC-in-MAC specification in 802.1ad.

Please verify my understanding: are you proposing that vendors add
Bridging
to their MPLS devices; Bridging over MPLS as it were, MPLS is the
Transport.
correct?  If so, I have noticed, that vendors are quietly adding
Bridging to
their ATM, Frame and TDM devices as well.  802.1ad could interconnect
all
these devices, regardless of which media they use as the Transport.  

My question is: how do you deal with (portions of) the network, for
which a
spanning tree would be a very inefficient forwarding means, because the
physical topology does not approximate a tree?

Thank you,
Joris Wils 
Consulting SW Engineer
Coriolis Networks

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Tue, 22 Apr 2003 09:57:28 +0900 (JST)

Joris,

> correct?  

Correct.

> If so, I have noticed, that vendors are quietly adding Bridging to

Exactly.

> physical topology does not approximate a tree?

Could you clarify this? What is spanning tree in the above context?
802.1D STP, or STP/RSTP/MSTP?

If you are claiming STP topology change time is inefficient, the use of
RSTP/MSTP should be considered.

If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify
the issues?

Thanks,

Muneyoshi Suzuki
Nippon Telegraph and Telephone Corp.

---

From: Muneyoshi Suzuki <[email-masked]>
Date: Tue, 22 Apr 2003 13:20:15 +0900 (JST)

Per,

> *  Even LSPs can be setup by operator configuration, not 

Agreed.

Standard L2 bringing over LSPs is already proposed in 
draft-lee-ppvpn-hybrid-vpls-00.txt. And MAC-in-MAC described in 
draft-radoaca-ppvpn-gvpls-01.txt supports clear separation between
the customers and provider address spaces. I think these documents
need to update, but are a good start point to discuss robust 
architecture of virtual private bridged lan.

Thanks,

Muneyoshi Suzuki

---

From: Norman Finn <[email-masked]>
Date: Fri, 25 Apr 2003 09:16:25 -0700

Muneyoshi,

If you use spanning tree among the pseudowires connecting Islands,
as in:
                       pw A
     island 1 --------------------- island 2
           \                         /
       pw B \_______       _________/ pw C
                    \     /
                    island 3

then one of pw A, pw B, or pw C must be blocked.  Let's suppose it's
pw C.  Then, all traffic from island 2 to island 3 must be relayed
by island 1.

In other words, since wires are almost "free" in this space, one
tends to have a lot of them.  It the extreme case that you have a
full mesh of connections among all the participants in a net, spanning
tree is a particularly wasteful approach; it guarantees to block all
but N of the N*(N-1)/2 pseudowires!  (: Yes, a bridge-bigot is saying
that spanning tree is not optimal for all interconnect plans. :)

If you configure a relatively sparse interconnect plan, using just
a few pseudowires, and if those pseudowires approximate physical
reality, then spanning tree becomes more viable.  The scaling
problem for 3000 VPLS instances at 10 pseudowires each becomes 3000
VPLS instances at 2-3 pseudowires each, reducing the BPDU load from
20,000 to 7,500.  I would remark that our best bridges top out at
somewhere on the order of 1,000 - 2,000 BPDUs per second, at this
time.  I need to think a bit more before I agree that this solution
"simple and robust".

-- Norm

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 29 Apr 2003 16:03:00 -0400

Norm, Muneyoshi,
> that spanning tree is not optimal for all interconnect plans. :)
If in the problem we are trying to solve, the islands are end customers
LAN, and the traffic are mostly flowing to/from one or few hubs to a
larger number of spokes, then there is no need to have a full-mesh of PW
(partial mesh is sufficient), and the case where traffic flow is not
optimal is infrequent then. 
I think it's fine to solve 80% of the problem well and optimize for the
remaining 20%. A full-meshed with split-horizon seems to be optimized
for the minority of requirements, but not solving the majority of the
problem well (issues already being discussed and acknowledged on this
list).

If the problem we are trying to solve is building very large LANs, then
I think it's worth considering Neil Harrison point that "There is a
massive difference in recognising the importance of ethernet as a key
CPE *interface* and then (somehow) making the (wrong) extrapolation that
this means ethernet is a great WAN technology." 

> time.  I need to think a bit more before I agree that this solution
If we keep bridging to the furthest edge possible (e.g. in CLE or MTU if
need be), then the number of VPLS instances is drastically reduced. 

Perhaps until we agree on the problem we are trying to solve, it's hard
to scope VPLS problem space.

Regards,
Cheng-Yin