Subject: Time slots for IETF 74 L2VPN WG?
From: Shane Amante <[email-masked]>
To: [email-masked]
Date: Sun, 1 Mar 2009 19:20:23 -0700
List-Id: <l2vpn.ietf.org>

Hi All,

Please let the chairs know if you would like a time slot for the L2VPN  
WG meeting at IETF 74.  We have been tentatively allocated a 2.5 hour  
slot on Tuesday, 3/24:
TUESDAY, March 24, 2009
0900-1130 Morning Session I
Continental 4	INT	l2vpn	Layer 2 Virtual Private Networks WG

-shane

From [email-masked]  Tue Mar  3 23:34:24 2009
Date: Wed, 04 Mar 2009 20:34:46 +1300
From: Kris Price <[email-masked]>
To: [email-masked]
Subject: MPLS version of RBridges

Hi,

I apologise if this is seen as off topic, but what I have been pondering 
may be seen to resemble l2vpns, and some people here (who may not be on 
the RBridge mailing list) may have considered this or have something to 
say about it.

I am talking about approaches to overcoming the shortcomings of bridged 
IEEE LANs. RBridge is probably the most notable, and most advanced, but 
there is other work around, such as Nortel's PLSB. It seems to me that 
these could be achieved using MPLS encapsulation and forwarding. It may 
resemble VPLS in many ways, but would use new or adapted control-plane 
protocols operating at layer-2 instead of layer-3.

Such a system would share many similarities to RBridges and the problems 
that TRILL has already solved (or is solving) for RBridges, but the 
encapsulation and forwarding would be different.

Why MPLS? Mainly for the re-use of existing hardware. I assume adding 
new control-planes is much simpler as it is predominantly a matter of 
software development. Re-using this hardware would reduce development 
costs and the time to market (again, I'm assuming).

Also, since MPLS seems to have become very popular in transport and 
provider areas, there may be practical advantages to consolidating on 
using MPLS hardware for aggregation and campus areas as well. (Rather 
than splitting effort on the ongoing hardware development front.) But 
that's well beyond me to say.

In summary:

Routers run a link-state protocol, building a topological database from 
which they identify the shortest paths to other routers. Routers set up 
label switched paths (LSPs) to the other routers.

Routers use either control-plane or data-plane learning of reachability 
information. In control-plane learning, routers learn the MAC addresses 
of active end stations on attached links, as a normal IEEE bridge would, 
and distribute this over the link-state protocol so that sending routers 
can identify the appropriate LSPs on which to forward frames. If using 
data-plane learning, each router learns the appropriate LSPs by 
examining packets during decapsulation.

When a frame from an end station arrives at a router, the router looks 
up the destination MAC address, identifying the egress router and 
appropriate label switch path. The router encapsulates the frame in an 
MPLS header, and the encapsulated frame is then label switched across 
the network to the egress node. At the egress node the label is popped 
and the frame forwarded out the appropriate interface.

Single-destination frames would be forwarded on multipoint-to-point 
(MP2P) LSPs. For single-destination forwarding, scaling is essentially 
O(n) using MP2P LSPs compared to O(n^2) using P2P LSPs.

It appears from the experience of TRILL that data-plane learning is a 
desirable feature. To achieve this, there are two options apparent to me 
that could be explored:

The first is to place an extra label in the stack when encapsulating a 
frame in MPLS, which can be used by the egress router to identify the 
ingress router. In essence these are P2P LSPs tunnelled over the MP2P LSPs.

The second is to look at using some kind of MAC-in-MAC encapsulation 
before the MPLS encapsulation, with the outer MAC header identifying the 
source and destination addresses of the routers in question (where only 
the source address is actually relevant). The egress router, after 
popping the MPLS label, would learn the ingress router via this outer 
MAC header.

Multi-destination forwarding is naturally trickier. Trees would need to 
be set up, either shared trees as per RBridges using MP2MP LSPs, or 
source-based trees similar to PLSB and approaches considered for VPLS 
using P2MP LSPs. Additional trees would be set up for constrained 
distribution in VLANs and/or IP multicast groups (more later).

With multi-destination forwarding there are so many ways to skin it, and 
it depends on many factors such as: how VLANs and IP multicast is to be 
handled; trade offs between bending the rules in the MPLS architecture, 
any requirements for data-plane learning, and balancing the intricacy of 
the control-plane.

VLANs could be managed in a couple of ways:

Some form of multi-topology routing could be used to discover the 
topology of each VLAN, and when transmitting across each link the outer 
MAC header would contain the VLAN tag of the topology in question, on 
receipt the router can use this additional information to classify the 
packet. This can be seen to increase the MPLS label space 
("per-subinterface") and constrain the forwarding of frames in a VLAN to 
links which are in those VLANs. Directly coupled router to router links 
would simply be full 802.1Q trunks.

Another option is not to be concerned about constraining frames to only 
those links which allow those VLANs, and each router advertises VLAN 
membership, with constrained distribution trees established for each 
VLAN. The outer VLAN tags used on each link wouldn't be relevant.

IP multicast can also be optimised with constrained trees, and the mcast 
group membership information distributed by the link-state protocol.

I did discover that MPLS encapsulation was proposed for RBridges in 
draft-bryant-perlman-trill-pwe-encap-00, which from my understanding 
violates the MPLS architecture, because label assignments are made 
upstream, but that upstream allocation does certainly make things easier 
for the control-plane in a system like this (if it's a violation you can 
live with).

The draft does discuss how the paths would be established and it is 
possible to conceive ways of establishing additional constrained trees 
for VLANs and IP multicast optimisation too. However, after cursory 
examination of methods for this, it would seem to require routers to do 
SPF computations for all routers in the network. A router would need to 
know its position in the tree to decide if it needed to install relevant 
forwarding state. This may be considerable overhead, but that does not 
seem to bother the people behind PLSB, and I do not have the wisdom to 
declare whether it is or is not.

A signalling protocol in the control-plane (perhaps separate, or perhaps 
carried on the link-state protocol) could remove the need to do these 
SPF computations, and remove the upstream assignment of labels, making 
it compliant to the MPLS architecture. But this would be a trade off in 
that the resulting protocol might be considered more intricate.

That is the sum of it. The rest gets into the details of weighing the 
possible approaches for each part against each other and designing the 
protocols.

I apologise if this is seen as off topic, unfortunately I've no one who 
understands these subjects well enough that I can bounce the idea off. I 
just wanted to put it out there in case there were likeminded people who 
have considered this before, are working on it, thought it worthy of 
discussion (perhaps in another forum), or were able to open my mind to 
the flaws in it.

Regards

Kris Price

From [email-masked]  Fri Mar  6 15:00:02 2009
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-ietf-l2vpn-arp-mediation-10.txt 
Date: Fri,  6 Mar 2009 15:00:01 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF.

	Title		: ARP Mediation for IP Interworking of Layer 2 VPN
	Author(s)	: E. Rosen, H. Shah, G. Heron, V. Kompella
	Filename	: draft-ietf-l2vpn-arp-mediation-10.txt
	Pages		: 28
	Date		: 2009-3-6
	
The VPWS service [L2VPN-FRM] provides point-to-point connections 
     between pairs of Customer Edge (CE) devices.  It does so by 
     binding two Attachment Circuits (each connecting a CE device 
     with a Provider Edge, PE, device) to a pseudowire (connecting 
     the two PEs).  In general, the Attachment Circuits must be of 
     the same technology (e.g., both Ethernet, both ATM), and the 
     pseudowire must carry the frames of that technology.  However, 
     if it is known that the frames' payload consists solely of IP 
     datagrams, it is possible to provide a point-to-point connection 
     in which the pseudowire connects Attachment Circuits of 
     different technologies. This requires the PEs to perform a 
     function known as "ARP Mediation". ARP Mediation refers to the 
     process of resolving Layer 2 addresses when different resolution 
     protocols are used on either Attachment Circuit. The methods 
     described in this document are applicable even when the CEs run 
     a routing protocol between them, as long as the routing protocol 
     runs over IP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-arp-mediation-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-l2vpn-arp-mediation-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From [email-masked]  Mon Mar  9 03:52:26 2009
From: "swathi" <[email-masked]>
To: <[email-masked]>
Subject: Doubt on BGP based L2VPN
Date: Mon, 9 Mar 2009 16:18:00 +0530

------=neXtPaRt_1236644443
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C9A0D2.9DE581D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C9A0D2.9DE581D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
            In L2vpn autodiscovery what are the RT and RD's and what's =
the exact format to advertise the vpn information to other pe's using =
BGP.

THANKS & REGARDS,
M.Swathi,

------=_NextPart_000_0019_01C9A0D2.9DE581D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; In=20
L2vpn&nbsp;autodiscovery what are the RT and RD's and what's the exact =
format to=20
advertise the vpn information to other pe's using BGP.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>THANKS &amp; REGARDS,<BR></FONT><FONT =
face=3DArial=20
size=3D2>M.Swathi,<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0019_01C9A0D2.9DE581D0--

------=neXtPaRt_1236644443
Content-Type: text/plain;

************************* www.ceeyes.com **************************************
CONFIDENTIALITY AND DISCLAIMER NOTICE
Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by e-mailing [email-masked], then delete the message from your system without making, distributing or retaining any copies of it. Any views or opinions presented are solely those of the sender and do not necessarily represent those of Ceeyes unless otherwise specifically stated. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.

------=neXtPaRt_1236644443--

From [email-masked]  Mon Mar  9 11:27:36 2009
Content-class: urn:content-classes:message
Subject: RE: IPDir Review of draft-ietf-l2vpn-arp-mediation-09.txt
Date: Mon, 9 Mar 2009 14:10:14 -0400
Importance: normal
Priority: normal
From: "Shah, Himanshu" <[email-masked]>
To: "Margaret Wasserman" <[email-masked]>, <[email-masked]>
Cc: Mark Townsley <[email-masked]>, Himanshu Shah <[email-masked]>

L2VPN Group,

We have posted an updated version of the arp-mediation draft
(draft-ietf-l2vpn-arp-mediation-10.txt) that addresses some=20
of the concerns raised by IPDir review.

In summary,=20

1) the IPv6 support for ARP-Med is completely re-written
(contributed by Neil Hart and Andrew Dolganow from Alcatel/Lucent).

2) Clarification texts added to address some of the concern listed=20
  below

3) Minor Editorial changes

We apologize for the super late response on the following IPDir
review.=20

Please see the detailed comments in line...

Also, please the review the new draft and provide comments before
the meeting, if possible.

/himanshu=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Margaret Wasserman
Sent: Friday, March 21, 2008 4:55 PM
To: [email-masked]
Cc: Mark Townsley; Jari Arkko
Subject: IPDir Review of draft-ietf-l2vpn-arp-mediation-09.txt

NOTE:  I am not on the L2VPN mailing list, so please include me
explicitly on any discussion.

Hi L2VPN Folks,

At Mark Townsley's request, I performed an IP Directorate review of
draft-ietf-l2vpn-arp-mediation-09.txt, paying special attention to the
IPv6 portions of the document.

I found three fairly major IPv6-related issues with the document:

(1) This document makes the incorrect assumption an IPv6 host (non-
router) will only have a single IP address associated with an interface.
Virtually all IPv6 nodes will have more than one address per interface,
and the mechanisms described in this document are incompatible with that
fact in multiple ways:

- If there is more than one IPv6 address in the IP Address List TLV, it
is assumed that the first address is the address of the CE and the other
addresses are "on-link addresses".
- It is assumed that an Inverse Neighbor Discovery Advertisement will
only contain a single address, when it actually contains an address
list.
- The PE operates on the assumption that there is a single CE with a
single IP address, so once it discovers a single address during the
"monitoring state", it communicates that address to the remote PE and
thinks that discovery is complete.  However, this is not valid for an
IPv6 node that may have more than one address on the interface and may
configure new addresses on that interface (such as IPv6 Privacy
Addresses) at any time.

(2) The document reflects a misunderstanding of the contents of an
IPv6 Router Advertisement message, referring to "on-link addresses" =20
while the Router Advertisement actually contains on-link prefixes.  =20
This misunderstanding is reflected in the format of the Address List TLV
which does not include prefix lengths for the on-link prefixes.

(3) I'd like to see some explanation of how this mechanism interacts
with Duplicate Address Detection (DAD).  I believe that DAD will only
function on the AC and not across the PW.  Will the PE-to-PE
communication include a check that no address duplication has occurred?
If not, is there a reason to believe that DAD isn't needed?

himanshu> IPv6 section is completely re-written

I also had concerns or questions about several other portions of the
document:

(4)  The document says:

      "The establishment of the PW occurs independently from local CE
      IP address discovery. During the period when the PW has been
      established but the local CE IP device has not been discovered,
      only broadcast/multicast IP frames are propagated between the
      Attachment Circuit and pseudowire; unicast IP datagrams are
      dropped. The IP destination address is used to classify
      unicast/multicast packets."

Why are unicast packets dropped during this phase?  What are the
implications of dropping these packets if, for example, the CE device is
attempting to perform DHCP?

himanshu> A clarifying text has been added to the draft. In a nutshell,
remote PE can not process
himanshu> unicast IP-DA packet if it does not have the link address of
the attached CE. And note=20
himanshu> that IP-DA in the packet is not necessarily that of the
attached CE.

(5)  The document also says:

      "The unicast IP frames are propagated between AC and pseudowire
      only when CE IP devices on both Attachment Circuits have been
      discovered, notified and proxy functions have completed."

How will both sides know when the other side has completed these
functions?

himanshu> By way of exchanging the IP addresses of the local CE, each PE
himanshu> now has adequate information to complete the proxy function
with
himanshu> the local CE. It is possible that a PE may get IP address
himanshu> from the remote PE, advertise local CE's IP address to remote
PE
himanshu> and follows immediately with IP unicast data packet. There is
a
himanshu> small window here whereby remote PE has started the proxy
function
himanshu> but has not completed it but has started receiving IP data
packets.
himanshu> This should not be an issue, because at this point PE should
have
himanshu> local CE's link information (but CE may-not-yet-have-completed
PE's
himanshu> proxy function). This still allows unicast IP packets received
over
himanshu> PW to be sent out over local AC.

(6)  In section 5.1.4, the document says:

         "o  The PE learns the IP address of the local CE from the
            Configure-Request received with the IP-Address option
            (0x03). The PE verifies that the IP address present in the
            IP-Address option is non-zero. If the IP address is zero,
            PE responds with Configure-Reject (as this is a request
            from CE to assign it an IP address). Also, the Configure-
            Reject copies the IP-Address option with a zero value to
            instruct the CE to not include that option in new
            Configure-Request. If the IP address is non-zero, PE
            responds with Configure-Ack."

It also says:

      "The IPCP IP-Address option MAY be negotiated between the PE and
      the local CE device."

This does not seem to be internally consistent.  Up above, the document
seems to indicate that the PE will reject a configure request with an IP
address of zero (indicating a request to provide
one) and in this paragraph it indicates that the IP-Address option may
be "negotiated".  What does this mean?

himanshu> This only means that PE will not engage in assigning the IP
address to local CE
himanshu> The following text from the draft right below the bullet that
you mention above
himanshu> sheds more light on this.
himanshu> ----- begin of text ----      =20

         "o  If the PE does not know the IP address of the remote CE,=20
           it sends a Configure-Request without the IP-Address=20
           option. =20
                                           =20
        o  If the PE knows the IP address of the remote CE, it sends=20
           a Configure-Request with the IP-Address option containing=20
           the IP address of the remote CE. "
himanshu> ---- end of text ---

(7) In section 5.1.5, the document says:

      In order to learn the IP address of the CE device for a given
      Attachment Circuit, the PE device may execute Router Discovery
      Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
      router solicitation) message is sent using a source IP address
      of zero.

Why is the router discovery packet sent with a source address of zero?

himanshu> Because PE may not have remote CE's IP address that it can use
as proxy as the source IP address

(8) How would this mechanism interact with Secure Neighbor Discovery
(SEND)?  This issue should be covered in the security considerations
section, IMO.

I also found a few borderline-editorial issues that, IMO, merited a
mention:

(9) There is no reference for Inverse ND.  You need to add RFC 3122 as a
normative reference and refer to it in the appropriate location.

himanshu>> fixed in the update.

(10) The document says:

      "Address Family
           Two octet quantity containing a value from the ADDRESS
           FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232]
           that encodes the address contained in the Address field."

There must be an IANA registry for this that it would be better to use
than RFC 3232.

himanshu> Those numbers are referenced, right below in the draft,
exactly a paragraph below.
himanshu> here is the text..     =20
himanshu> ----- begin of text -----     =20
     The following address encodings are defined by this version of=20
     the protocol:  =20
               =20
                    Address Family      Address Encoding  =20
        =20
                    IPv4 (1)             4 octet full IPv4 address  =20
                    IPv6 (2)             Absent=20
himanshu> ------ end of text -------

(11) The reference to RFC 1256: ICMP Router Discovery Messages, should
be normative not informative.

himanshu>> fixed in the update

(12) There are numerous "nits" in the document -- references in the
abstract, acronyms that aren't expanded at first use, etc.  You should
address these in the next update.

Margaret

From [email-masked]  Tue Mar 10 03:11:18 2009
Date: Tue, 10 Mar 2009 11:11:34 +0100
From: Martin Vigoureux <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Time slots for IETF74 joint mpls-tp session
Cc: [email-masked]

all,

this is reminder.
If you wish to have a presentation slot during the joint mpls-tp
session, let me know.
This session is planned Wednesday 25th, 09:00-11:30 am.

martin

From [email-masked]  Tue Mar 10 18:19:24 2009
From: Peng He <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 10 Mar 2009 21:19:42 -0400
Subject: RE: I-D Action:draft-henderickx-l2vpn-vpls-multihoming-00.txt 
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>

Hello Wim and Florin,

I got a question regarding your newly-published I.D. 'BGP based Multi-homin=
g in Virtual Private LAN Service':

Given the following dual-homing CE to dual-homing CE scenario, suppose you =
can not set-up full-meshed PWs among PE1-4 for whatever reason; PE1 can onl=
y communicate to PE3 while PE2 can only communicate to PE4. Then I suppose =
that a link failure in CE1 dual-homing may affect designated PE selection o=
n the remote dual-homed CE2? or, the designated PE selections in the two du=
al-homing CEs are not independent due to the non-full-meshed PW connections=
.  This is regarding your following statements:

"3. BGP based Multi-homing procedures

   This section describes BGP based procedures for electing a designated
   forwarder among the set of PEs that are multi-homed to a customer
   site. Only the local PEs are actively participating in the selection
   algorithm. The PE(s) remote from the dual homed CE are not required
   to participate in the designated forwarding election for a remote
   dual-homed CE.
"

                               PE1---------------------PE3
                           /                                          \
                      __/                                            \__
               CE1                                                        C=
E2
                      __                                               __
                          \                                            /
                            \                                         /
                               PE2-----------------------PE4

Regards,
Peng

________________________________________
From: [email-masked] [[email-masked]] On Beha=
lf Of [email-masked] [[email-masked]]
Sent: Wednesday, March 04, 2009 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-henderickx-l2vpn-vpls-multihoming-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

        Title           : BGP based Multi-homing in Virtual Private LAN Ser=
vice
        Author(s)       : W. Henderickx, F. Balus
        Filename        : draft-henderickx-l2vpn-vpls-multihoming-00.txt
        Pages           : 11
        Date            : 2009-03-04

Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN).  It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing".  This memo
shows how multi-homing can be offered in the context of LDP-based
VPLS using BGP-AD.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henderickx-l2vpn-vpls-multihoming=
-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From [email-masked]  Tue Mar 10 18:48:37 2009
From: Peng He <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 10 Mar 2009 21:49:00 -0400
Subject: Questions about I.D. 'VPLS protection switching with ring access'
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

Hello Xiaojun,

I have a few questions about your ID of 'VPLS protection switching with rin=
g access', which sounds like an interesting approach.

1. page 3, bottom, you use the term 'VPLS CE' to distinguish 'non-VPLS CE'?

2. page 4, middle, by 'PE-CE-CE-PE forms a non-close ring', you mean 'PE1-C=
E1-CE2-PE2' forms a non-close ring as a close ring should be ''PE1-CE1-CE2-=
PE2-PE1'?

3. Both CE and PE can be a master node (there is only one at a time)?

4. What happens if a node, e.g., CE or PE, fails? What happens if a link/no=
de is recovered from a failure?

Seems to me that although there are many Ethernet ring protocols, but most =
of the deployed ones are vendor-specified, expect G.8032, which does not su=
pport overlapping rings yet. So it might be a little bit difficult for a VP=
LS device vendor (L2.5/L3) to implement/emulate a L2 vendor's specific ring=
 protocol, unless everybody supports G.8032. =20

Regards,
Peng=

From [email-masked]  Tue Mar 10 23:33:50 2009
Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-henderickx-l2vpn-vpls-multihoming-00.txt 
Date: Wed, 11 Mar 2009 07:34:21 +0100
From: "HENDERICKX Wim" <[email-masked]>
To: "Peng He" <[email-masked]>, "BALUS Florin" <[email-masked]>
Cc: [email-masked]

Peng,

We are assuming a full mesh PW otherwise there are dual failure
scenario's which will result in loss as well. There are other mechanisms
to solve this particular issue afaik.

Cheers,
Wim

-----Original Message-----
From: Peng He [mailto:[email-masked]]=20
Sent: woensdag 11 maart 2009 2:20
To: HENDERICKX Wim; BALUS Florin
Cc: [email-masked]
Subject: RE: I-D Action:draft-henderickx-l2vpn-vpls-multihoming-00.txt=20

Hello Wim and Florin,

I got a question regarding your newly-published I.D. 'BGP based
Multi-homing in Virtual Private LAN Service':

Given the following dual-homing CE to dual-homing CE scenario, suppose
you can not set-up full-meshed PWs among PE1-4 for whatever reason; PE1
can only communicate to PE3 while PE2 can only communicate to PE4. Then
I suppose that a link failure in CE1 dual-homing may affect designated
PE selection on the remote dual-homed CE2? or, the designated PE
selections in the two dual-homing CEs are not independent due to the
non-full-meshed PW connections.  This is regarding your following
statements:

"3. BGP based Multi-homing procedures

   This section describes BGP based procedures for electing a designated
   forwarder among the set of PEs that are multi-homed to a customer
   site. Only the local PEs are actively participating in the selection
   algorithm. The PE(s) remote from the dual homed CE are not required
   to participate in the designated forwarding election for a remote
   dual-homed CE.
"

                               PE1---------------------PE3
                           /                                          \
                      __/                                            \__
               CE1
CE2
                      __
__
                          \                                            /
                            \                                         /
                               PE2-----------------------PE4

Regards,
Peng

________________________________________
From: [email-masked] [[email-masked]] On
Behalf Of [email-masked] [[email-masked]]
Sent: Wednesday, March 04, 2009 11:00 AM
To: [email-masked]
Subject: I-D Action:draft-henderickx-l2vpn-vpls-multihoming-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : BGP based Multi-homing in Virtual Private LAN
Service
        Author(s)       : W. Henderickx, F. Balus
        Filename        : draft-henderickx-l2vpn-vpls-multihoming-00.txt
        Pages           : 11
        Date            : 2009-03-04

Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private
Network (VPN) that gives its customers the appearance that their
sites are connected via a Local Area Network (LAN).  It is often
required for the Service Provider (SP) to give the customer redundant
connectivity to some sites, often called "multi-homing".  This memo
shows how multi-homing can be offered in the context of LDP-based
VPLS using BGP-AD.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-henderickx-l2vpn-vpls-multihom
ing-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From [email-masked]  Fri Mar 13 08:22:02 2009
From: Peng He <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Mar 2009 11:22:15 -0400
Subject: RE: Questions about I.D. 'VPLS protection switching with ring access'
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDCBcorpe2k7mbx01_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDCBcorpe2k7mbx01_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:SimSun;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
tt
	{mso-style-priority:99;
	font-family:SimSun;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Xiaojuan,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Thanks for your reply. &nbsp;But I am not gonna be in IETF74=
@San
FranCisco, so I prefer to have discussion on line </span><span
style=3D'font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><spa=
n
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'=
><o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Please see in-line.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Peng<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <br>
<b>Sent:</b> Friday, March 13, 2009 5:03 AM<br>
<b>To:</b> Peng He<br>
<b>Cc:</b> [email-masked]; [email-masked]; [email-masked]<br>
<b>Subject:</b> </span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=B4=F0=
=B8=B4</span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: Questions ab=
out
I.D. 'VPLS protection switching with ring access'<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;hel=
lo,peng</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;thank for your attention to my draft.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;</span><tt>1. page 3, bottom, you use the term 'VPLS CE' to
distinguish 'non-VPLS CE'?</tt> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; answer</span><span lang=3DZH-CN style=3D'font-s=
ize:
10.0pt;color:red'>=A3=BA</span><span style=3D'font-size:10.0pt;font-family:=
"Arial","sans-serif";
color:red'> &nbsp;yes, you are right</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;</span><tt>2. page 4, middle, by 'PE-CE-CE-PE forms a non-clos=
e
ring', you mean 'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring sh=
ould
be ''PE1-CE1-CE2-PE2-PE1'?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; <span style=3D'color:red'>&nbsp;answer</span></span><span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> yes too.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<tt>&nbsp; &nbsp; &nbsp; 3. Both CE and PE can be a master node (there is o=
nly
one at a time)?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; answer:</span><tt><span style=3D'color:blue'> <=
/span><span
style=3D'color:red'>&nbsp;</span></tt><span style=3D'font-size:10.0pt;font-=
family:
"Arial","sans-serif";color:red'>a ring only can has one master node at the =
same
time .</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><tt>&nbsp;4. What happens if a node, e.g., CE or PE, fails? W=
hat
happens if a link/node is recovered from a failure?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp;<span style=3D'color:red'> answer</span></span><span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> i am sorry that &nbsp;n=
ode
failure &nbsp;and failur recovery &nbsp;is my little concern in this
version0.thank you for your comment.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; but i think if you want the answer now ,i can
explain briefly now .</span> <br>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;in scenario 1 ,if NODE CE i=
s
down ,the flow will be halted without doubt</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; if NODE PE1 is &nbsp;down, CE can detect the faillure,=
so
do &nbsp;the same action as the PE-CE link down.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; if NODE PE2 is &nbsp;down ,the same way as that PE1 is
down</span> <span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><i><span style=3D'fo=
nt-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[Peng He] whatever=
 PE1
or PE2 fails, there could be a mechanism to inform the far-end PE3 or PE4 t=
hat
now the =A1=AEsame=A1=AF traffic is from PE1 (or PE2) instead of previous P=
E2 (or PE1).
You might need to mention this in your next version of your draft; and what=
 is
the mechanism. (there are some I.D.s talking about this, considering PE1 an=
d
PE2 as a group)<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; in &nbsp;scenario 2, CE1 is a
master,so &nbsp;if NODE CE1 is down ,the flow from CE1 will halt with no do=
ubt.</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'><=
o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><i><span style=3D'fo=
nt-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[Peng He] Yes. But=
 I
am thinking to fully take the advantages of ring-topology access, e.g., the
user access can also join the ring, as shown in your scenario 3; or the use=
rs
have another ring(s) to share a link with the =A1=AEboundary ring=A1=AF. As=
 such, when CE1
or CE2 fails, the users can use CE2 or CE1.&nbsp;&nbsp; What do you think
regarding having an independent particular =A1=AEboundary ring=A1=AF or it =
might be better
to let the users joint the =A1=AEboundary ring=A1=AF?<o:p></o:p></span></i>=
</b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><span style=3D'font-siz=
e:10.0pt;
font-family:"Arial","sans-serif";color:red'>but there is no </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; change for the flow from CE2</spa=
n> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; if NODE PE1 is down,CE can detect the faillure,so do &nbsp;th=
e
same action as the PE-CE</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; link down.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp;if NODE CE2 is down,CE can detect the faillure,the flow
from CE2 will hault with </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no doubt. but there is no
change for the flow from CE1.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp;IF NODE PE2 is down,CE2 will detect it and sent message=
 to
master node CE1,open </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the CE1-CE2link. &nbsp; </span><br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;as regards &nbsp; failure recovery, &nbsp=
;if
failure is detected disappear, master will block one link connected it agai=
n.</span>
<span style=3D'color:#1F497D'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><b><i><span style=3D'fo=
nt-size:
11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>[Peng He] This is =
what
most ring protocols did. My question is if the master node blocks the
original&nbsp; =A1=AEsecondary=A1=AF port or block the newly-recovered port=
? Usually the
L2 ring protocols will block the original =A1=AEsecondary=A1=AF port and se=
nd TC
notification message to flash the FDB tables. But if this is really necessa=
ry,
say, you got traffic loss due to a link/node failure, that is whatever
reasonabl; but why should you still have traffic loss due to a link/node re=
covery,
which seems to be a =A1=AEgood=A1=AF news?<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp; <span style=3D'color:red'>&nbsp;so later i will add th=
ese
detail to my draft.thank you .</span></span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; i =
will
attend 74th IETF meeting</span><span lang=3DZH-CN style=3D'font-size:10.0pt=
'>=A3=AC</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>if you still ha=
ve
some intereste ,we can discuss there. &nbsp; &nbsp; &nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp;</span> <br>
<br>
<br>
<o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%'>
 <tr>
  <td width=3D"26%" valign=3Dtop style=3D'width:26.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <p class=3DMsoNormal><b><span style=3D'font-size:7.5pt;font-family:"Arial=
","sans-serif"'>Peng
  He &lt;[email-masked]&gt;</span></b><span style=3D'font-size:7=
.5pt;
  font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
  <p><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>2009-=
03-11
  09:49</span> <o:p></o:p></p>
  </td>
  <td width=3D"73%" valign=3Dtop style=3D'width:73.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
   style=3D'width:100.0%'>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=B3=AD=CB=CD</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=D6=F7=CC=E2</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>Questions
    about I.D. 'VPLS protection switching with ring access'</span><o:p></o:=
p></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
   </tr>
  </table>
  </td>
 </tr>
</table>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
<br>
<tt>Hello Xiaojun,</tt><br>
<br>
<tt>I have a few questions about your ID of 'VPLS protection switching with
ring access', which sounds like an interesting approach.</tt><br>
<br>
<tt>1. page 3, bottom, you use the term 'VPLS CE' to distinguish 'non-VPLS =
CE'?</tt><br>
<br>
<tt>2. page 4, middle, by 'PE-CE-CE-PE forms a non-close ring', you mean
'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring should be
''PE1-CE1-CE2-PE2-PE1'?</tt><br>
<br>
<tt>3. Both CE and PE can be a master node (there is only one at a time)?</=
tt><br>
<br>
<tt>4. What happens if a node, e.g., CE or PE, fails? What happens if a
link/node is recovered from a failure?</tt><br>
<br>
<tt>Seems to me that although there are many Ethernet ring protocols, but m=
ost
of the deployed ones are vendor-specified, expect G.8032, which does not
support overlapping rings yet. So it might be a little bit difficult for a =
VPLS
device vendor (L2.5/L3) to implement/emulate a L2 vendor's specific ring
protocol, unless everybody supports G.8032. &nbsp;</tt><br>
<br>
<br>
<tt>Regards,</tt><br>
<tt>Peng</tt> <o:p></o:p></p>

<pre><o:p>&nbsp;</o:p></pre><pre>------------------------------------------=
--------------<o:p></o:p></pre><pre>ZTE&nbsp;Information&nbsp;Security&nbsp=
;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;ma=
il&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;or=
ganization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidentia=
l.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nb=
sp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&=
nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&n=
bsp;to&nbsp;others.<o:p></o:p></pre><pre>This&nbsp;email&nbsp;and&nbsp;any&=
nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nb=
sp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;th=
e&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&=
nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;ema=
il&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp=
;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;=
this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp=
;sender.<o:p></o:p></pre><pre>This&nbsp;message&nbsp;has&nbsp;been&nbsp;sca=
nned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Sp=
am&nbsp;system.<o:p></o:p></pre></div>

</div>

</body>

</html>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDCBcorpe2k7mbx01_--

From [email-masked]  Fri Mar 13 08:33:22 2009
From: Peng He <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 13 Mar 2009 11:33:18 -0400
Subject: RE: Questions about I.D. 'VPLS protection switching with ring access'
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDD0corpe2k7mbx01_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDD0corpe2k7mbx01_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:SimSun;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
tt
	{mso-style-priority:99;
	font-family:SimSun;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>One more: how you implement the ring-link between PE1 and PE=
2,
PWE emulated, and can be used by non-user-related data also or not? Or it i=
s an
independent link only for ring usage?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Peng<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <br>
<b>Sent:</b> Friday, March 13, 2009 5:03 AM<br>
<b>To:</b> Peng He<br>
<b>Cc:</b> [email-masked]; [email-masked]; [email-masked]<br>
<b>Subject:</b> </span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=B4=F0=
=B8=B4</span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: Questions ab=
out
I.D. 'VPLS protection switching with ring access'<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;hel=
lo,peng</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;thank for your attention to my draft.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;</span><tt>1. page 3, bottom, you use the term 'VPLS CE' to
distinguish 'non-VPLS CE'?</tt> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; answer</span><span lang=3DZH-CN style=3D'font-s=
ize:
10.0pt;color:red'>=A3=BA</span><span style=3D'font-size:10.0pt;font-family:=
"Arial","sans-serif";
color:red'> &nbsp;yes, you are right</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp;</span><tt>2. page 4, middle, by 'PE-CE-CE-PE forms a non-clos=
e
ring', you mean 'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring sh=
ould
be ''PE1-CE1-CE2-PE2-PE1'?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; <span style=3D'color:red'>&nbsp;answer</span></span><span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> yes too.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><br>
<tt>&nbsp; &nbsp; &nbsp; 3. Both CE and PE can be a master node (there is o=
nly
one at a time)?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; answer:</span><tt><span style=3D'color:blue'> <=
/span><span
style=3D'color:red'>&nbsp;</span></tt><span style=3D'font-size:10.0pt;font-=
family:
"Arial","sans-serif";color:red'>a ring only can has one master node at the =
same
time .</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; </span><tt>&nbsp;4. What happens if a node, e.g., CE or PE, fails? W=
hat
happens if a link/node is recovered from a failure?</tt> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp;<span style=3D'color:red'> answer</span></span><span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> i am sorry that &nbsp;n=
ode
failure &nbsp;and failur recovery &nbsp;is my little concern in this
version0.thank you for your comment.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; but i think if you want the answer now ,i can
explain briefly now .</span> <br>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;in scenario 1 ,if NODE CE i=
s
down ,the flow will be halted without doubt</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; if NODE PE1 is &nbsp;down, CE can detect the faillure,=
so
do &nbsp;the same action as the PE-CE link down.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; if NODE PE2 is &nbsp;down ,the same way as that PE1 is
down</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; in &nbsp;scenario 2, CE1 is a
master,so &nbsp;if NODE CE1 is down ,the flow from CE1 will halt with no
doubt.but there is no </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; change for the flow from CE2</spa=
n> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; if NODE PE1 is down,CE can detect the faillure,so do &nbsp;th=
e
same action as the PE-CE</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; link down.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp;if NODE CE2 is down,CE can detect the faillure,the flow
from CE2 will hault with </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;no doubt. but there is no
change for the flow from CE1.</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp;IF NODE PE2 is down,CE2 will detect it and sent message=
 to
master node CE1,open </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;the CE1-CE2link. &nbsp; </span><br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'=
>&nbsp;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;as regards &nbsp; failure recovery, &nbsp=
;if
failure is detected disappear, master will block one link connected it agai=
n.</span>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp; <span style=3D'color:red'>&nbsp;so later i will add th=
ese
detail to my draft.thank you .</span></span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; i =
will
attend 74th IETF meeting</span><span lang=3DZH-CN style=3D'font-size:10.0pt=
'>=A3=AC</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>if you still ha=
ve
some intereste ,we can discuss there. &nbsp; &nbsp; &nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp;</span> <br>
<br>
<br>
<o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%'>
 <tr>
  <td width=3D"26%" valign=3Dtop style=3D'width:26.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <p class=3DMsoNormal><b><span style=3D'font-size:7.5pt;font-family:"Arial=
","sans-serif"'>Peng
  He &lt;[email-masked]&gt;</span></b><span style=3D'font-size:7=
.5pt;
  font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
  <p><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>2009-=
03-11
  09:49</span> <o:p></o:p></p>
  </td>
  <td width=3D"73%" valign=3Dtop style=3D'width:73.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
   style=3D'width:100.0%'>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=B3=AD=CB=CD</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=D6=F7=CC=E2</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>Questions
    about I.D. 'VPLS protection switching with ring access'</span><o:p></o:=
p></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
   </tr>
  </table>
  </td>
 </tr>
</table>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
<br>
<tt>Hello Xiaojun,</tt><br>
<br>
<tt>I have a few questions about your ID of 'VPLS protection switching with
ring access', which sounds like an interesting approach.</tt><br>
<br>
<tt>1. page 3, bottom, you use the term 'VPLS CE' to distinguish 'non-VPLS =
CE'?</tt><br>
<br>
<tt>2. page 4, middle, by 'PE-CE-CE-PE forms a non-close ring', you mean
'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring should be
''PE1-CE1-CE2-PE2-PE1'?</tt><br>
<br>
<tt>3. Both CE and PE can be a master node (there is only one at a time)?</=
tt><br>
<br>
<tt>4. What happens if a node, e.g., CE or PE, fails? What happens if a lin=
k/node
is recovered from a failure?</tt><br>
<br>
<tt>Seems to me that although there are many Ethernet ring protocols, but m=
ost
of the deployed ones are vendor-specified, expect G.8032, which does not
support overlapping rings yet. So it might be a little bit difficult for a =
VPLS
device vendor (L2.5/L3) to implement/emulate a L2 vendor's specific ring
protocol, unless everybody supports G.8032. &nbsp;</tt><br>
<br>
<br>
<tt>Regards,</tt><br>
<tt>Peng</tt> <o:p></o:p></p>

<pre><o:p>&nbsp;</o:p></pre><pre>------------------------------------------=
--------------<o:p></o:p></pre><pre>ZTE&nbsp;Information&nbsp;Security&nbsp=
;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;ma=
il&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;or=
ganization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidentia=
l.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nb=
sp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&=
nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&n=
bsp;to&nbsp;others.<o:p></o:p></pre><pre>This&nbsp;email&nbsp;and&nbsp;any&=
nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nb=
sp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;th=
e&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&=
nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;ema=
il&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp=
;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;=
this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp=
;sender.<o:p></o:p></pre><pre>This&nbsp;message&nbsp;has&nbsp;been&nbsp;sca=
nned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Sp=
am&nbsp;system.<o:p></o:p></pre></div>

</div>

</body>

</html>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7EDD0corpe2k7mbx01_--

From [email-masked]  Mon Mar 16 17:01:26 2009
To: [email-masked], [email-masked]
Subject: RFC 5501 on Requirements for Multicast Support in Virtual Private LAN Services
From: [email-masked]
Date: Mon, 16 Mar 2009 16:59:47 -0700 (PDT)
Cc: [email-masked], [email-masked]

A new Request for Comments is now available in online RFC libraries.

        RFC 5501

        Title:      Requirements for Multicast Support in 
                    Virtual Private LAN Services 
        Author:     Y. Kamite, Ed.,
                    Y. Wada, Y. Serbest,
                    T. Morin, L. Fang
        Status:     Informational
        Date:       March 2009
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],  
                    [email-masked], 
                    [email-masked]
        Pages:      31
        Characters: 71507
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-l2vpn-vpls-mcast-reqts-07.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5501.txt

This document provides functional requirements for network solutions
that support multicast over Virtual Private LAN Service (VPLS).  It
specifies requirements both from the end user and service provider
standpoints.  It is intended that potential solutions will use these
requirements as guidelines.  This memo provides information for the 
Internet community.

This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

From [email-masked]  Mon Mar 16 19:10:40 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: IETF 74: Draft Agenda Posted
Date: Mon, 16 Mar 2009 20:11:06 -0600

Hi Everyone,

The draft agenda for IETF 74 has been posted here:
http://www.ietf.org/proceedings/09mar/agenda/l2vpn.txt

Please let the chairs know if there are any changes.

-shane & Vach

From [email-masked]  Tue Mar 17 05:24:46 2009
From: Peng He <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 17 Mar 2009 08:25:06 -0400
Subject: RE: RE: Questions about I.D. 'VPLS protection switching with ring access'
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7F046corpe2k7mbx01_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7F046corpe2k7mbx01_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:D=3D"DAV:" xmln=
s:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2=3D=
"http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ois=3D"http://sc=
hemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://schemas.micro=
soft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3.org/2000/09/=
xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" xmlns:u=
dc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http://www.w3.org=
/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/=
2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" xmlns:sp=3D"=
http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.micro=
soft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-in=
stance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" xmlns:udc=
xf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p=3D"http:/=
/schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http://schemas.micr=
osoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://schemas.microsoft=
.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.microsoft.com/o=
ffice/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformats.org/package=
/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlformats.org/ma=
rkup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/200=
4/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/re=
lationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" xm=
lns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types" xml=
ns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messages" x=
mlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" x=
mlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Publis=
hedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:st=3D"&#1;" x=
mlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:SimSun;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:Consolas;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Thanks. Looking forward to seeing the next version of your
draft.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Peng<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in =
0in 0in'>

<p class=3DMsoNormal><b><span style=3D'font-size:10.0pt;font-family:"Tahoma=
","sans-serif"'>From:</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <br>
<b>Sent:</b> Tuesday, March 17, 2009 4:04 AM<br>
<b>To:</b> Peng He<br>
<b>Cc:</b> [email-masked]; [email-masked]; [email-masked]<br>
<b>Subject:</b> </span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=B4=F0=
=B8=B4</span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: RE: Question=
s
about I.D. 'VPLS protection switching with ring access'<o:p></o:p></span></=
p>

</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;<sp=
an
style=3D'color:#1F497D'>One more: how you implement the ring-link between P=
E1 and
PE2, PWE emulated, and can be used by non-user-related data also or not? Or=
 it
is an independent link only for ring usage?</span></span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp;
&nbsp;answer: we are preparing adding &nbsp;these part to my draft &nbsp;.<=
/span>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp; there is a PW link between PE1 and PE2, and the link
&nbsp;can connect with the access ring &nbsp;to form a close ring .</span> =
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp; this &nbsp;PW link &nbsp;is mostly used to transmit li=
nk
&quot;down&quot; message to master node in this situation.</span> <br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>&nbsp; &n=
bsp;
&nbsp; &nbsp; &nbsp; </span><br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>*********=
**********************<br>
</span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=D3=D0=CF=DF=D1=D0=BE=
=BF=D4=BA</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> CE&amp;PTN </s=
pan><span
lang=3DZH-CN style=3D'font-size:10.0pt'>=C4=CF=BE=A9=C8=ED=BC=FE=B6=FE=B2=
=BF</span><span style=3D'font-size:10.0pt;
font-family:"Arial","sans-serif"'><br>
</span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=B5=E7=BB=B0=A3=BA</sp=
an><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>80378<br>
EMAIL:[email-masked]<br>
*******************************</span> <br>
<br>
<o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%'>
 <tr>
  <td width=3D"26%" valign=3Dtop style=3D'width:26.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <p class=3DMsoNormal><b><span style=3D'font-size:7.5pt;font-family:"Arial=
","sans-serif"'>Peng
  He &lt;[email-masked]&gt;</span></b><span style=3D'font-size:7=
.5pt;
  font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
  <p><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>2009-=
03-13
  23:33</span> <o:p></o:p></p>
  </td>
  <td width=3D"73%" valign=3Dtop style=3D'width:73.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
   style=3D'width:100.0%'>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=B3=AD=CB=CD</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span> <o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=D6=F7=CC=E2</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>RE:
    Questions about I.D. 'VPLS protection switching with ring access'</span=
><o:p></o:p></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'></td>
   </tr>
  </table>
  </td>
 </tr>
</table>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><br>
<br>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>One
more: how you implement the ring-link between PE1 and PE2, PWE emulated, an=
d
can be used by non-user-related data also or not? Or it is an independent l=
ink
only for ring usage?</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>&nbsp;</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>&nbsp;</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>Regards,</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>Peng</span>
<br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F4=
97D'>&nbsp;</span>
<br>
<b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:=
</span></b><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
[email-masked] [mailto:[email-masked]] <b><br>
Sent:</b> Friday, March 13, 2009 5:03 AM<b><br>
To:</b> Peng He<b><br>
Cc:</b> [email-masked]; [email-masked]; [email-masked]<b><br>
Subject:</b> </span><span lang=3DZH-CN style=3D'font-size:10.0pt'>=B4=F0=B8=
=B4</span><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>: Questions ab=
out
I.D. 'VPLS protection switching with ring access'</span> <br>
<span style=3D'font-family:"Arial","sans-serif"'>&nbsp;</span> <br>
<span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
hello,peng</span><span style=3D'font-family:"Arial","sans-serif"'> </span><=
span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><br>
&nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; thank for your attention to my draft.</span><span
style=3D'font-family:"Arial","sans-serif"'> <br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp; &nbsp; &nbsp;<br>
&nbsp; &nbsp; &nbsp; </span><span style=3D'font-family:"Arial","sans-serif"=
'>1.
page 3, bottom, you use the term 'VPLS CE' to distinguish 'non-VPLS CE'? <b=
r>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;answer</span><span lang=3DZH-CN
style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=3D'font-size:=
10.0pt;
font-family:"Arial","sans-serif";color:red'> &nbsp;yes, you are right</span=
><span
style=3D'font-family:"Arial","sans-serif"'> <br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp; &nbsp; &nbsp; </span><span style=3D'font-family:"Arial","sans-serif"=
'>2.
page 4, middle, by 'PE-CE-CE-PE forms a non-close ring', you mean
'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring should be
''PE1-CE1-CE2-PE2-PE1'? </span><span style=3D'font-size:10.0pt;font-family:=
"Arial","sans-serif"'><br>
&nbsp; &nbsp; &nbsp; &nbsp;<span style=3D'color:red'> answer</span></span><=
span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> yes too.</span><span
style=3D'font-family:"Arial","sans-serif"'> <br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp; &nbsp; &nbsp;</span><span style=3D'font-family:"Arial","sans-serif"'=
><br>
&nbsp; &nbsp; &nbsp;3. Both CE and PE can be a master node (there is only o=
ne
at a time)? </span><span style=3D'font-size:10.0pt;font-family:"Arial","san=
s-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;answer:</span><span style=3D'font-family:=
"Arial","sans-serif";
color:blue'> </span><span style=3D'font-family:"Arial","sans-serif";color:r=
ed'>&nbsp;</span><span
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'>a rin=
g only
can has one master node at the same time .</span><span style=3D'font-family=
:"Arial","sans-serif"'>
<br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp; &nbsp; &nbsp;</span><span style=3D'font-family:"Arial","sans-serif"'=
> 4.
What happens if a node, e.g., CE or PE, fails? What happens if a link/node =
is
recovered from a failure? </span><span style=3D'font-size:10.0pt;font-famil=
y:
"Arial","sans-serif"'><br>
&nbsp; &nbsp; &nbsp; &nbsp; <span style=3D'color:red'>&nbsp;answer</span></=
span><span
lang=3DZH-CN style=3D'font-size:10.0pt;color:red'>=A3=BA</span><span style=
=3D'font-size:
10.0pt;font-family:"Arial","sans-serif";color:red'> i am sorry that &nbsp;n=
ode failure
&nbsp;and failur recovery &nbsp;is my little concern in this version0.thank=
 you
for your comment.</span><span style=3D'font-family:"Arial","sans-serif"'> <=
br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;but i think if you want the answer now ,i=
 can
explain briefly now .</span><span style=3D'font-family:"Arial","sans-serif"=
'> <br>
<br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; in scenario 1 ,if NODE CE =
is
down ,the flow will be halted without doubt</span><span style=3D'font-famil=
y:
"Arial","sans-serif"'> </span><span style=3D'font-size:10.0pt;font-family:"=
Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp;if NODE PE1 is &nbsp;down, CE can detect the
faillure,so do &nbsp;the same action as the PE-CE link down.</span><span
style=3D'font-family:"Arial","sans-serif"'> </span><span style=3D'font-size=
:10.0pt;
font-family:"Arial","sans-serif";color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp;if NODE PE2 is &nbsp;down ,the same way as that =
PE1
is down</span><span style=3D'font-family:"Arial","sans-serif"'> </span><spa=
n
style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;in &nbsp;scenario 2, CE1 is=
 a
master,so &nbsp;if NODE CE1 is down ,the flow from CE1 will halt with no
doubt.but there is no <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;change for the flow from CE=
2</span><span
style=3D'font-family:"Arial","sans-serif"'> </span><span style=3D'font-size=
:10.0pt;
font-family:"Arial","sans-serif";color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp;if NODE PE1 is down,CE can detect the faillure,so do
&nbsp;the same action as the PE-CE</span><span style=3D'font-family:"Arial"=
,"sans-serif"'>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;link down.</span><span
style=3D'font-family:"Arial","sans-serif"'> </span><span style=3D'font-size=
:10.0pt;
font-family:"Arial","sans-serif";color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; if NODE CE2 is down,CE can detect the faillure,the flo=
w
from CE2 will hault with <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; no doubt. but there is no
change for the flow from CE1.</span><span style=3D'font-family:"Arial","san=
s-serif"'>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D'font=
-family:
"Arial","sans-serif"'>&nbsp;</span><span style=3D'font-size:10.0pt;font-fam=
ily:
"Arial","sans-serif";color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; IF NODE PE2 is down,CE2 will detect it and sent messag=
e to
master node CE1,open <br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the CE1-CE2link. &nbsp; </span><span
style=3D'font-family:"Arial","sans-serif"'><br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";
color:red'><br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; as regards &nbsp; failure recovery, &nbs=
p;if
failure is detected disappear, master will block one link connected it agai=
n.</span><span
style=3D'font-family:"Arial","sans-serif"'> <br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<span style=3D'color:red'> so later i wil=
l add
these detail to my draft.thank you .</span></span><span style=3D'font-famil=
y:
"Arial","sans-serif"'> <br>
</span><span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'><b=
r>
&nbsp;i will attend 74th IETF meeting</span><span lang=3DZH-CN style=3D'fon=
t-size:
10.0pt'>=A3=AC</span><span style=3D'font-size:10.0pt;font-family:"Arial","s=
ans-serif"'>if
you still have some intereste ,we can discuss there. &nbsp; &nbsp; &nbsp; <=
br>
&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D'font-family:"Arial","sans=
-serif"'>&nbsp;</span><o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
 style=3D'width:100.0%'>
 <tr>
  <td width=3D"24%" valign=3Dtop style=3D'width:24.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <p class=3DMsoNormal><b><span style=3D'font-size:7.5pt;font-family:"Arial=
","sans-serif"'>Peng
  He &lt;[email-masked]&gt;</span></b><span style=3D'font-size:7=
.5pt;
  font-family:"Arial","sans-serif"'> </span><o:p></o:p></p>
  <p><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>2009-=
03-11
  09:49</span><span style=3D'font-family:"Arial","sans-serif"'> </span><o:p=
></o:p></p>
  </td>
  <td width=3D"75%" valign=3Dtop style=3D'width:75.0%;padding:.75pt .75pt .=
75pt .75pt'>
  <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
   style=3D'width:100.0%'>
   <tr>
    <td width=3D"4%" valign=3Dtop style=3D'width:4.0%;padding:.75pt .75pt .=
75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=CA=D5=BC=FE=C8=CB</span><o:p></o:p></p>
    </td>
    <td width=3D"95%" valign=3Dtop style=3D'width:95.0%;padding:.75pt .75pt=
 .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span><span style=3D'font-family:"Aria=
l","sans-serif"'>
    </span><o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=B3=AD=CB=CD</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>&quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;, &quot;[email-masked]&quot;
    &lt;[email-masked]&gt;</span><span style=3D'font-family:"Arial","sans-s=
erif"'>
    </span><o:p></o:p></p>
    </td>
   </tr>
   <tr>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><span lan=
g=3DZH-CN
    style=3D'font-size:7.5pt'>=D6=F7=CC=E2</span><o:p></o:p></p>
    </td>
    <td valign=3Dtop style=3D'padding:.75pt .75pt .75pt .75pt'>
    <p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial"=
,"sans-serif"'>Questions
    about I.D. 'VPLS protection switching with ring access'</span><o:p></o:=
p></p>
    </td>
   </tr>
  </table>
  <p class=3DMsoNormal><br>
  <span style=3D'font-family:"Arial","sans-serif"'>&nbsp;</span> <o:p></o:p=
></p>
  <p><o:p>&nbsp;</o:p></p>
  <table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"
   style=3D'width:100.0%'>
   <tr>
    <td width=3D"50%" valign=3Dtop style=3D'width:50.0%;padding:.75pt .75pt=
 .75pt .75pt'></td>
    <td width=3D"50%" valign=3Dtop style=3D'width:50.0%;padding:.75pt .75pt=
 .75pt .75pt'></td>
   </tr>
  </table>
  </td>
 </tr>
</table>

<p style=3D'margin-bottom:12.0pt'><br>
<span style=3D'font-family:"Arial","sans-serif"'><br>
<br>
<br>
Hello Xiaojun,<br>
<br>
I have a few questions about your ID of 'VPLS protection switching with rin=
g
access', which sounds like an interesting approach.<br>
<br>
1. page 3, bottom, you use the term 'VPLS CE' to distinguish 'non-VPLS CE'?=
<br>
<br>
2. page 4, middle, by 'PE-CE-CE-PE forms a non-close ring', you mean
'PE1-CE1-CE2-PE2' forms a non-close ring as a close ring should be
''PE1-CE1-CE2-PE2-PE1'?<br>
<br>
3. Both CE and PE can be a master node (there is only one at a time)?<br>
<br>
4. What happens if a node, e.g., CE or PE, fails? What happens if a link/no=
de
is recovered from a failure?<br>
<br>
Seems to me that although there are many Ethernet ring protocols, but most =
of
the deployed ones are vendor-specified, expect G.8032, which does not suppo=
rt
overlapping rings yet. So it might be a little bit difficult for a VPLS dev=
ice
vendor (L2.5/L3) to implement/emulate a L2 vendor's specific ring protocol,
unless everybody supports G.8032. &nbsp;<br>
<br>
<br>
Regards,<br>
Peng </span><br>
<span style=3D'font-family:"Arial","sans-serif"'>&nbsp;</span> <br>
<span style=3D'font-family:"Arial","sans-serif"'>--------------------------=
------------------------------</span>
<br>
<span style=3D'font-family:"Arial","sans-serif"'>ZTE Information Security N=
otice:
The information contained in this mail is solely property of the sender's
organization. This mail communication is confidential. Recipients named abo=
ve
are obligated to maintain secrecy and are not permitted to disclose the
contents of this communication to others.</span> <br>
<span style=3D'font-family:"Arial","sans-serif"'>This email and any files
transmitted with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have received this
email in error please notify the originator of the message. Any views expre=
ssed
in this message are those of the individual sender.</span> <br>
<span style=3D'font-family:"Arial","sans-serif"'>This message has been scan=
ned
for viruses and Spam by ZTE Anti-Spam system.</span> <o:p></o:p></p>

<pre><o:p>&nbsp;</o:p></pre><pre>------------------------------------------=
--------------<o:p></o:p></pre><pre>ZTE&nbsp;Information&nbsp;Security&nbsp=
;Notice:&nbsp;The&nbsp;information&nbsp;contained&nbsp;in&nbsp;this&nbsp;ma=
il&nbsp;is&nbsp;solely&nbsp;property&nbsp;of&nbsp;the&nbsp;sender's&nbsp;or=
ganization.&nbsp;This&nbsp;mail&nbsp;communication&nbsp;is&nbsp;confidentia=
l.&nbsp;Recipients&nbsp;named&nbsp;above&nbsp;are&nbsp;obligated&nbsp;to&nb=
sp;maintain&nbsp;secrecy&nbsp;and&nbsp;are&nbsp;not&nbsp;permitted&nbsp;to&=
nbsp;disclose&nbsp;the&nbsp;contents&nbsp;of&nbsp;this&nbsp;communication&n=
bsp;to&nbsp;others.<o:p></o:p></pre><pre>This&nbsp;email&nbsp;and&nbsp;any&=
nbsp;files&nbsp;transmitted&nbsp;with&nbsp;it&nbsp;are&nbsp;confidential&nb=
sp;and&nbsp;intended&nbsp;solely&nbsp;for&nbsp;the&nbsp;use&nbsp;of&nbsp;th=
e&nbsp;individual&nbsp;or&nbsp;entity&nbsp;to&nbsp;whom&nbsp;they&nbsp;are&=
nbsp;addressed.&nbsp;If&nbsp;you&nbsp;have&nbsp;received&nbsp;this&nbsp;ema=
il&nbsp;in&nbsp;error&nbsp;please&nbsp;notify&nbsp;the&nbsp;originator&nbsp=
;of&nbsp;the&nbsp;message.&nbsp;Any&nbsp;views&nbsp;expressed&nbsp;in&nbsp;=
this&nbsp;message&nbsp;are&nbsp;those&nbsp;of&nbsp;the&nbsp;individual&nbsp=
;sender.<o:p></o:p></pre><pre>This&nbsp;message&nbsp;has&nbsp;been&nbsp;sca=
nned&nbsp;for&nbsp;viruses&nbsp;and&nbsp;Spam&nbsp;by&nbsp;ZTE&nbsp;Anti-Sp=
am&nbsp;system.<o:p></o:p></pre></div>

</div>

</body>

</html>

--_000_E6D5CAC0ACC932498E6AC1A692E0CBA12297B7F046corpe2k7mbx01_--

From [email-masked]  Tue Mar 17 07:34:46 2009
Date: Tue, 17 Mar 2009 15:35:26 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: poll on making the draft-beller-mpls-tp-gach-dcn

All,

the authors/editors of draft-beller-mpls-tp-gach-dcn has
asked us to accept the document as an MPLS Working group
document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing
list before Wednesday March 25.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

From [email-masked]  Wed Mar 18 07:50:01 2009
Date: Wed, 18 Mar 2009 15:50:42 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: working groupm last call on draft-ietf-mpls-tp-gach-gal-02 has ended

  All,

  the working group last call on draft-ietf-mpls-tp-gach-gal-02
  has ended.

  1. we have received the information from ITU-T ad hoc team on mpls-tp
     that the comments they have is aligned with the last call comments
     received under point 5. below in the MPLS wg last call.

  2. We have received one comment that says that the associated channel
     should not be used for OAM. Since this is the entire purpose of the
     of the associated channel the authors/editors are instructed not
     consider this comment.
  3. We have received comments that would require us to revisit the
     results of the JWT investigtaion. We will not do so, since this is
     not within our charter.
  4. We have received one comment that we are allocating too many
     experimental code points, the editors/authors are instructed to solve
     this together with the current and future RTG AD and the MEAD team
     chair.

  5. We have received a set of comments, that should be considered as
     "friendly amendments" and that should be responded to by the
     authors-editors.

  Could the authors lease update the draft and republish.

  /Loa
-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

From [email-masked]  Wed Mar 18 14:39:40 2009
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: IETF Secretariat <[email-masked]>
Subject: Posting of IPR Disclosure related to Juniper's Statement of IPR related to draft-ietf-l2vpn-vpls-mcast-04
Date: Wed, 18 Mar 2009 14:39:40 -0700 (PDT)
Cc: [email-masked], , [email-masked], "[email-masked]"@ietf.org, [email-masked], [email-masked]

Dear Yakov Rekhter, Rahul Aggarwal, Yuji Kamite, Intellectual Property, Luyuan Fang:

An IPR disclosure that pertains to your Internet-Draft entitled "Multicast in
VPLS" (draft-ietf-l2vpn-vpls-mcast) was submitted to the IETF Secretariat on
2009-03-17 and has been posted on the "IETF Page of Intellectual Property Rights
Disclosures" (https://datatracker.ietf.org/ipr/1117/). The title of the IPR
disclosure is "Juniper's Statement of IPR related to
draft-ietf-l2vpn-vpls-mcast-04."

The IETF Secretariat

From [email-masked]  Thu Mar 19 05:47:27 2009
Date: Thu, 19 Mar 2009 13:48:04 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: poll to make draft-busi-mpls-tp-oam-framework an mpls working group document

Working Group,

the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
requested the document shall be accepted as a working group document.

This is a one week poll to see if there are support for making it a
working group document, please respond to the mpls-tp mailing list
before Wednesday March 26.

The document will be found at:

http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt

Disclaimer: I've decided to start this poll even though the draft is not
available from the IETF repository.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13 

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

From [email-masked]  Fri Mar 20 05:29:50 2009
Date: Fri, 20 Mar 2009 13:30:26 +0100
From: Martin Vigoureux <[email-masked]>
Organization: Alcatel-Lucent
To: [email-masked]
Subject: slides for joint mpls-tp session
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

all,

could you please start sending the slides you will use
for your presentation(s). Thanks.

The joint wg session on mpls-tp is on Wednesday, 9:00-11:30 am
http://www.ietf.org/proceedings/09mar/agenda/mpls.txt

martin

From [email-masked]  Sun Mar 22 18:37:45 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: IETF 74: Presentations Needed
Date: Sun, 22 Mar 2009 19:38:31 -0600

Hi Everyone,

Thus far, we've received one presentation for the L2VPN WG meeting on  
Tuesday morning.  For the rest of you holding a slot on Tuesday  
morning, can you please send your presentations to the chairs ASAP so  
they may be posted to the IETF Web site prior to the meeting?

The agenda for the meeting can be found here:
http://www.ietf.org/proceedings/09mar/agenda/l2vpn.txt

Thanks!

-shane & Vach

From [email-masked]  Sun Mar 22 18:44:54 2009
Content-class: urn:content-classes:message
Subject: clarification on draft-pkwok-l2vpn-vpls-macflush-ld-00.txt
Date: Sun, 22 Mar 2009 21:45:42 -0400
From: "Shah, Himanshu" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9AB59.13639F82
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Paul/Pranjal,

I read through this draft and would appreciate if you
could clarify following things -

1) It wasn't exactly clear how the MAC flush loop would
   occur. It would help if you could give an example with
   the misconfiguration that you refer in the draft.

2) In the event of such a misconfiguration was to exist,
   do you believe that it is possible that a broadcast
   loop could also occur at data plane. If true, how do you
   resolve that?

3) Is it possible to detect such mis-wired/misconfigured PW
   with a built-in control plane mechanism, rather than after
   the fact, through looped mac-flush messages?

thanks,
himanshu

------_=_NextPart_001_01C9AB59.13639F82
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7654.12">
<TITLE>clarification on =
draft-pkwok-l2vpn-vpls-macflush-ld-00.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Hi Paul/Pranjal,<BR>
<BR>
I read through this draft and would appreciate if you<BR>
could clarify following things -<BR>
<BR>
1) It wasn't exactly clear how the MAC flush loop would<BR>
&nbsp;&nbsp; occur. It would help if you could give an example with<BR>
&nbsp;&nbsp; the misconfiguration that you refer in the draft.<BR>
<BR>
2) In the event of such a misconfiguration was to exist,<BR>
&nbsp;&nbsp; do you believe that it is possible that a broadcast<BR>
&nbsp;&nbsp; loop could also occur at data plane. If true, how do =
you<BR>
&nbsp;&nbsp; resolve that?<BR>
<BR>
3) Is it possible to detect such mis-wired/misconfigured PW<BR>
&nbsp;&nbsp; with a built-in control plane mechanism, rather than =
after<BR>
&nbsp;&nbsp; the fact, through looped mac-flush messages?<BR>
<BR>
thanks,<BR>
himanshu<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C9AB59.13639F82--

From [email-masked]  Sun Mar 22 23:09:14 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 23 Mar 2009 11:35:53 +0530
Subject: RE: clarification on draft-pkwok-l2vpn-vpls-macflush-ld-00.txt
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Kwok, Paul \(Paul\)" <[email-masked]>

--_000_C584046466ED224CA92C1BC3313B963E0358DE54EFINBANSXCHMBSA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Himanshu,
                       Thanks for detailed review of the draft. Please refe=
r more inline.

Thanks,
Pranjal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hah, Himanshu
Sent: Sunday, March 22, 2009 6:46 PM
To: [email-masked]
Subject: clarification on draft-pkwok-l2vpn-vpls-macflush-ld-00.txt

Hi Paul/Pranjal,

I read through this draft and would appreciate if you
could clarify following things -

1) It wasn't exactly clear how the MAC flush loop would
   occur. It would help if you could give an example with
   the misconfiguration that you refer in the draft.

In general misconfiguration in the draft refers to break of VPLS split hori=
zon rule among VPLS PEs in the core
full mesh or loop resolution mechanism in dual-homing configuration in H-VP=
LS. The specific methods to ensure
split horizon or loop free connectivity in H-VPLS redundancy is kept out of=
 scope of the draft . Such methods
could be either manual configuration or automated mechanisms/protocols used=
 to create loop free path in redundant
topology.

2) In the event of such a misconfiguration was to exist,
   do you believe that it is possible that a broadcast
   loop could also occur at data plane. If true, how do you
   resolve that?

That's correct. Such misconfiguration may cause loops/broadcast storms in d=
atapath as well. However in this draft
we are not proposing any solution for datapath loops and assumption is that=
 implementations may have loop detection
methodologies based on the native service forwarding. Pls. note that loop d=
etection in forwarding would take place only
if there is data traffic flowing across.  Mac flush messages are not really=
 "forwarded" by VPLS PEs , rather "propagated"
by the PE's control plane, so we require a loop detection mechanism based o=
n the characteristics of the control plane
messaging.

3) Is it possible to detect such mis-wired/misconfigured PW
   with a built-in control plane mechanism, rather than after
   the fact, through looped mac-flush messages?

To have such built-in control mechanism a reference for "good config" is ne=
eded, which may not be possible locally
in a VPLS PE device. What has been administratively provisioned (or misconf=
igured) in a VPLS PE device is itself
the starting point of reference.

thanks,
himanshu

--_000_C584046466ED224CA92C1BC3313B963E0358DE54EFINBANSXCHMBSA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>clarification on draft-pkwok-l2vpn-vpls-macflush-ld-00.t=
xt</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.6000.16788" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D015391605-23032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Hi Himanshu,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D015391605-23032009><FONT face=3DA=
rial=20
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Thanks for detailed review of the draft. Please refer=20
more&nbsp;inline.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D015391605-23032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D015391605-23032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D015391605-23032009><FONT face=3DA=
rial=20
color=3D#0000ff size=3D2>Pranjal</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Shah,=20
Himanshu<BR><B>Sent:</B> Sunday, March 22, 2009 6:46 PM<BR><B>To:</B>=20
[email-masked]<BR><B>Subject:</B> clarification on=20
draft-pkwok-l2vpn-vpls-macflush-ld-00.txt<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=3D2>Hi Paul/Pranjal,<BR><BR>I read through this draft and wou=
ld=20
appreciate if you<BR>could clarify following things -<BR><BR>1) It wasn't=20
exactly clear how the MAC flush loop would<BR>&nbsp;&nbsp; occur. It would =
help=20
if you could give an example with<BR>&nbsp;&nbsp; the misconfiguration that=
 you=20
refer in the draft.<SPAN class=3D015391605-23032009><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
<P><FONT size=3D2><SPAN class=3D015391605-23032009><FONT face=3DArial color=
=3D#0000ff>In=20
general misconfiguration in the draft&nbsp;refers to b</FONT></SPAN></FONT>=
<SPAN=20
class=3D015391605-23032009><FONT face=3DArial color=3D#0000ff size=3D2>reak=
 of=20
</FONT></SPAN><SPAN class=3D015391605-23032009><FONT face=3DArial color=3D#=
0000ff=20
size=3D2>VPLS split horizon rule among VPLS PEs in the core <BR>full mesh o=
r loop=20
resolution mechanism in dual-homing </FONT></SPAN><SPAN=20
class=3D015391605-23032009><FONT face=3DArial color=3D#0000ff size=3D2>conf=
iguration in=20
</FONT></SPAN><FONT size=3D2><SPAN class=3D015391605-23032009><FONT face=3D=
Arial=20
color=3D#0000ff>H-VPLS. The specific methods to ensure <BR>split horizon or=
 loop=20
free connectivity in H-VPLS redundancy is kept out of scope of the=20
draft&nbsp;.&nbsp;Such methods</FONT></SPAN></FONT><FONT size=3D2><SPAN=20
class=3D015391605-23032009><FONT face=3DArial color=3D#0000ff>&nbsp;<BR>cou=
ld be=20
either manual configuration&nbsp;or automated mechanisms/protocols used&nbs=
p;to=20
create loop free&nbsp;path in&nbsp;redundant <BR></FONT></SPAN><SPAN=20
class=3D015391605-23032009><FONT face=3DArial=20
color=3D#0000ff>topology.&nbsp;</FONT>&nbsp;</SPAN><BR><BR>2) In the event =
of such=20
a misconfiguration was to exist,<BR>&nbsp;&nbsp; do you believe that it is=
=20
possible that a broadcast<BR>&nbsp;&nbsp; loop could also occur at data pla=
ne.=20
If true, how do you<BR>&nbsp;&nbsp; resolve that?</P></FONT><FONT size=3D2>=
<SPAN=20
class=3D015391605-23032009></SPAN></FONT>
<P><FONT size=3D2><SPAN class=3D015391605-23032009><FONT face=3DArial=20
color=3D#0000ff>That's correct. Such misconfiguration&nbsp;may cause=20
loops/broadcast storms&nbsp;in datapath as well. However in this draft<BR>w=
e are=20
not proposing any solution for datapath loops and assumption&nbsp;is that=20
implementations may have&nbsp;loop detection <BR>methodologies based=20
</FONT></SPAN></FONT><FONT size=3D2><SPAN class=3D015391605-23032009><FONT=
=20
face=3DArial color=3D#0000ff>on the native service forwarding. Pls. note th=
at loop=20
detection in&nbsp;forwarding would&nbsp;take place&nbsp;only <BR>if there i=
s=20
data traffic flowing across.&nbsp;&nbsp;Mac flush messages are not really=20
"forwarded" by VPLS PEs , rather "propagated"&nbsp;<BR>by the&nbsp;PE's con=
trol=20
plane, so we&nbsp;require a loop detection mechanism based on the=20
characteristics of the control plane <BR>messaging.</FONT></SPAN></FONT><FO=
NT=20
size=3D2><SPAN class=3D015391605-23032009>&nbsp;</SPAN></FONT></P>
<P><FONT size=3D2><SPAN class=3D015391605-23032009>&nbsp;</SPAN><BR>3) Is i=
t=20
possible to detect such mis-wired/misconfigured PW<BR>&nbsp;&nbsp; with a=20
built-in control plane mechanism, rather than after<BR>&nbsp;&nbsp; the fac=
t,=20
through looped mac-flush messages?<SPAN class=3D015391605-23032009><FONT=20
face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
<P><FONT size=3D2><SPAN class=3D015391605-23032009><FONT face=3DArial color=
=3D#0000ff>To=20
have such built-in control mechanism a&nbsp;reference for "good config" is=
=20
needed, which may not be possible locally<BR>in a VPLS PE device.=20
W</FONT></SPAN></FONT><FONT size=3D2><SPAN class=3D015391605-23032009><FONT=
=20
face=3DArial color=3D#0000ff>hat has been administratively provisioned (or=
=20
misconfigured) in a VPLS PE device</FONT></SPAN></FONT><FONT size=3D2><SPAN=
=20
class=3D015391605-23032009><FONT face=3DArial color=3D#0000ff>&nbsp;is=20
itself&nbsp;<BR>the starting point of reference. </FONT></SPAN></FONT></P>
<P><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D015391605-23032009></SPAN></FONT><FONT size=3D2><SPAN=20
class=3D015391605-23032009><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN><BR>thanks,<BR>himanshu<BR></P></FONT></BODY>=
</HTML>

--_000_C584046466ED224CA92C1BC3313B963E0358DE54EFINBANSXCHMBSA_--

From [email-masked]  Sun Mar 22 23:58:41 2009
Date: Mon, 23 Mar 2009 00:00:13 -0700
Subject: Re: [PWE3] poll to make draft-busi-mpls-tp-oam-framework an mpls working group document
From: Nitin Bahadur <[email-masked]>
To: Loa Andersson <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Support.

On 3/19/09 5:48 AM, "Loa Andersson" <[email-masked]> wrote:

> Working Group,
> 
> 
> the authors of draft-busi-mpls-tp-oam-framework-02-02-1.txt has
> requested the document shall be accepted as a working group document.
> 
> This is a one week poll to see if there are support for making it a
> working group document, please respond to the mpls-tp mailing list
> before Wednesday March 26.
> 
> The document will be found at:
> 
> http://www.tla-group.com/~loa/draft-busi-mpls-tp-oam-framework-02-02-1.txt
> 
> Disclaimer: I've decided to start this poll even though the draft is not
> available from the IETF repository.
> 
> 
> /Loa

From [email-masked]  Mon Mar 23 01:42:26 2009
To: [email-masked]
Subject: Comments to LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS 
Date: Mon, 23 Mar 2009 16:42:54 +0800 (SGT)
From: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]

Hi Pranjal,

Just want to highlight a deployment scenario that I forsee will have interop issues. Although you stated in your paper regarding General Applicability of PE-ID TLV, however there could be a case in the field when provisioning PE-ID across the same VPLS VSI but spanning multiple PEs/mtu-s, the PE-ID is different per site. This could be due to misconfigurations or because of interop limitation between vendors.

On the same figure 1 on your paper, if the same VPLS VSI is provisioned with same PE-ID between PE-4 and PE-2, but a different PE-ID between PE-2 and mtu-s. I forsee potential issue when Mtu-s switchover to PE-2, trigger a PE-ID but this is different between PE-2 and PE-4, which PE-2 will relay the PE-ID TLV.

So I suggest that either every PE will have to do a lookup to match the corresponding PE-ID before forwarding or you be specific in the paper that PE-ID of the same VPLS VSI is the same throughout the whole domain.

Generally, the draft has gone through 4 versions and has cover most scenarios. But just this above scenario that I've seen getting configured in the field that gets me worry.

regards,
Max

From [email-masked]  Tue Mar 24 11:23:38 2009
Content-class: urn:content-classes:message
Subject: RE: Vpls-MIB response to comments at IETF 73
Date: Tue, 24 Mar 2009 13:24:11 -0500
From: "MEDIRATTA Rohit" <[email-masked]>
To: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9ACAD.BAAE72A9
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Norival,
   Please find my answers inline to your questions inline.
=20
thanks,
Rohit=20

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Norival Figueira
Sent: Friday, December 05, 2008 2:26 PM
To: [email-masked]
Subject: RE: Vpls-MIB response to comments at IETF 73

Hi Rohit,

Thank you for addressing below the questions I asked at the 73rd IETF's
L2VPN WG meeting. I would like to take this opportunity to further
clarify those questions and answer your questions below.

> ???: I have a few questions for clarification.  When I read the MIB,
there's a few things that I couldn't find:

>  + VPLS Instance ID in the Configuration Table;

>  + A way to define the desired Class of Service to be used by the VPLS
instance to be used for tunnel selection;

>

> RM: Could we get some more information on the above two and why its a

> good idea to add them to the next revision.

VPLS Instance ID (VC ID):

In the context of LDP signaling for VPLS defined in RFC4762, LDP is used
for signaling a full mesh of pseudowires interconnecting VPLS instances.
LDP pseudowire id (PWid) Forwarding Equivalence Class (FEC) element 128
was originally used to carry pseudowire parameters. This is still used
and supported by most of the existing RFC4762 implementations in the
market. Please note that although RFC4762 defines the use of the
Generalized PWid FEC 129, it also describes the use of FEC 128 in
Appendix A ("VPLS Signaling using the PWid FEC Element"), which states
that "this section is being retained because live deployments use this
version of the signaling for VPLS". Therefore, in order to support these
existing implementations, one also needs to define a VPLS Instance Id
(or VC Id). In this case, in each PE containing a VPLS instance for a
given customer, the VPLS instance is configured with a same VPLS
Instance ID, which has global significance across all PEs involved in
the same VPLS instance. The VPLS instance ID is then used as the VC ID
in the FEC element 128. PEs then correlate pseudowires with
corresponding VPLS instances using the VC ID value contained in the FEC
element 128.
[rm] VC-ID is a per PW configuration, there is no requirement for this
to be globally unique. VC-ID per PW is captured in the PW MIB.
Bgp-Autodiscovery has a globally unique Vpls-Id which is captured in
this MIB.

The above reasoning also justifies Sanjay's question in your original
message.

VPLS Class of Service (CoS):

Some service providers use a specific CoS for particular VPLS instances.
In that case, the PE needs to choose an appropriate LSP such as an L-LSP
that best satisfies the desired VPLS CoS. A VPLS CoS could be defined as
a 3-bit value. How would a PE select appropriate LSPs in regards to CoS
for each VPLS instance without an explicit definition in the VPLS MIB?
[rm] Choosing a tunnel is a PW function. Still not convinced this belong
in Vpls-MIB.=20

> + There are pointers to the Bridge-MIB, but if would be useful if
there was

> a place in MIB to define the maximum # of MAC addresses that should be

> learned by a specific VPLS instance.

>

> RM: There was an object vplsPwBindMacAddressLimit in an earlier
revision.

> http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt

> <http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt>

> This was removed after suggestion from the group in Montreal-IETF,
refer

> to discussion in Montreal

VPLS Maximum Number of MAC addresses:

My understanding from the Montreal discussions is that the group was
concerned with the definition in the VPLS MIB of features that are
implementation specific. I also agree that implementation specific
definitions should not be part of a standard VPLS MIB. However, defining
the maximum number of MAC addressed for a VPLS instance is not an
implementation specific issue. A VPLS maximum number of MAC addresses is
needed to support service provider's L2VPN business models. Without this
feature, service providers will not able to properly deploy large scale
VPLS services.

Service providers deploying VPLS as an L2VPN service usually define
L2VPN business models with different service levels. For example
(completely hypothetical), a service provider may define a customer VPLS
service starting at a maximum of 40 MAC addresses and charge for
additional increments of 40 MAC addresses. This business model allows
the service provider to optimize MAC address table resources and to plan
the capacity of its network in terms of the number of VPLS instances
that can be supported by each PE (i.e., it allows the service provider
to define admission control policies that take PEs' MAC address tables'
capabilities into consideration). Defining a maximum number of MAC
addresses per VPLS instance is also necessary to protect the network
against customer (unintended or intended) MAC address storm attacks.
Without a per VPLS (i.e., customer) limit, a single VPLS could consume
the whole MAC address table available in a PE. This would cause service
disruption to other VPLS customers.

Please note that the maximum number of MAC addresses discussed here is a
VPLS instance property. The MAC address limits defined earlier in
vplsLdpPwBindMacAddressLimit (which was later removed) and in
vplsPwBindMacAddressLimit (which is still defined in the current VPLS
MIB draft), represent something else and are not appropriate to provide
an overall VPLS MAC address limit. An overall VPLS MAC address limit
does not care for how many MAC addresses were learned by specific PWs or
endpoint interfaces. An overall VPLS MAC address limit is what service
providers care about to implement their L2VPN business models and to
allow for the proper management and protection of individual VPLS
services.

Please note that with the advent of PBB-VPLS integration, customer MAC
addresses will no longer be learned by VPLS instances. This could be
used by someone as an argument against the inclusion of a VPLS MAC limit
in the VPLS MIB. However, the VPLS MIB must be applicable to existing
deployments where PBB-VPLS integration is not used. Please note that
customer MAC addresses will be learned by PEs that also provide PBB
Backbone Edge Bridge (BEB)functionality, but this is a subject for a
separate discussion on a PBB-VPLS thread.
[rm] Point well taken, we will certainly deliberate over this in the
next revision. It will be good to understand what is the level of
interest for this.

> + It would be useful if there was a way to allow someone to clear the
MAC

>  addresses in a VPLS instance.

>

> RM: Should this exist in the Vpls-MIB ? Why ?

VPLS Clear MAC Addresses:

The group has been discussing different ways to flush the learned MAC
address of a VPLS instance to support dual homing. In simple terms, with
dual homing a CPE (customer premises equipment) could be physically
attached to two PEs supporting a VPLS service for the customer. Only one
PE would initially forward the customer traffic. In the event that the
active PE lost connectivity to the CPE or the PE itself failed, the
other PE would take over the responsibility of forwarding the customer
traffic. Without further actions, this could create a "black hole"
effect where other PE's in the network would continue to send traffic to
the original PE until learned MAC entries aged out or were re-learned to
point to the new PE as the proper destination. To solve this problem,
one can use explicit MAC withdraw (or flush) messages or implicit
mechanisms to determined that a MAC flush is required. In both cases, a
MAC flush is only issued when there is a VPLS service switchover from on
PE to another PE in a dual homing scenario. The case exists for allowing
one to manually (administratively) flush the learned MAC addresses of a
VPLS instances (for dual homing and non-dual homing scenarios). This is
useful for debugging purposes (e.g., the service provider wants to
re-start MAC learning for a particular VPLS instance) and also for
allowing the manual switchover of service from one PE to another (e.g.,
in a non-dual homing scenario).
[rm] Do we have further interest in this being added to Vpls-MIB ?=20

> + You point to Bridge-MIB, but I don't see a clear identification of
the

>  interfaces that are bound to a VPLS instance.  I see that for the PW

> side, but I don't see that for the interfaces.

>

> RM: This is the issue where AC is a PW. We've raised this a few times

> and have not really

> been able to solicit a clear approach to tackling this.

VSIs are interconnected by a full mesh of network pseudowires. To
provide services to customers a VSI must also support port mode and
tagged mode (VLAN) attachments (or endpoints). My question regards these
two types. Analogous to the PW bind table defined in the VPLS MIB, one
could have an explicit attachment bind table (possibly indexed by
vplsConfigIndex and ifindex of endpoint).

There seems to be a lean towards SNMP Context Mapping MIB to represent
the endpoints. However, this seems to only apply in the context of SNMP
v3. For SNMPv2c and SNMPv1, each context will need to be mapped to a
community string, which will need to be configured on the management
station. This seems impractical, since any number of VPLS instances are
possible, with each one having its own unique endpoint attachments.

Regards,

Norival Figueira

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

Date: Tue, 2 Dec 2008 17:38:32 -0600

From: "MEDIRATTA Rohit" <[email-masked]>

Subject: Vpls-MIB response to comments at IETF 73

To: <[email-masked]>

Cc: Agrahara S Kiran Koushik <[email-masked]>

Message-ID:

=20
<[email-masked]
>

       =20

Content-Type: text/plain;       charset=3D"us-ascii"

Hi All,

   Please find the response to the questions raised w.r.t to VPLS-MIB at

IETF-73.

The response to the questions are preprended with RM:

Regards,

Rohit, Kiran & Tom.

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

 Questions:

- Kireeti Kompella: You say that VplsBgpRteTargetEntry allows H-VPLS

representation, but that seems pretty orthogonal.  Can you explain that?

RM: RT's can be used to filter which "l2vpn route" should be accepted by

each Node.

Consider the following setup

A-----B------C------D

      |      |

      |      |

      E      F

Assuming

Vpls/Bgp on A is setup to import RT from B only, export RT-A.

Vpls/Bgp on B is setup to import RT from A,C and E, export RT-B

Vpls/Bgp on C is setup to import RT from B,D and F, export RT-C

Vpls/Bgp on D is setup to import RT from C only, export RT-D.

Vpls/Bgp on E is setup to import RT from B only, export RT-E.

Vpls/Bgp on F is setup to import RT from C only, export RT-F.

This will lead to the following PW Setup.

A----B=3D=3D=3D=3D=3DC----D

     |     |

     |     |

     E     F

This gives Providers the flexibility to engineer the Auto-discovered

PW's.

To provide the ability to import/export multiple RT's per Vpls we needed

to break RT into a separate table.

- ???: I have a few questions for clarification.  When I read the MIB,

there's

a few things that I couldn't find:

  + VPLS Instance ID in the Configuration Table;

  + A way to define the desired Class of Service to be used by the VPLS

  instance to be used for tunnel selection;

RM: Could we get some more information on the above two and why its a

good idea to add them to the next revision.

+ There are pointers to the Bridge-MIB, but if would be useful if there

was

  a place in MIB to define the maximum # of MAC addresses that should be

  learned by a specific VPLS instance.

RM: There was an object vplsPwBindMacAddressLimit in an earlier

revision.

http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt

<http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt>

This was removed after suggestion from the group in Montreal-IETF, refer

to discussion in Montreal

+ It would be useful if there was a way to allow someone to clear the

MAC

  addresses in a VPLS instance.

RM: Should this exist in the Vpls-MIB ? Why ?

+ You point to Bridge-MIB, but I don't see a clear identification of the

  interfaces that are bound to a VPLS instance.  I see that for the PW

side,

  but I don't see that for the interfaces.

RM: This is the issue where AC is a PW. We've raised this a few times

and have not really

been able to solicit a clear approach to tackling this.

- Sanjay (?): MIB you're using for configuration doesn't support old FEC

Type

using VC ID.  There are a lot of existing installations today that are

using

FEC 128 and all of them depend on the VC ID for the identifier of the

VPLS

instance.  Would like you to consider in the VPLS instance, if you can

add the

VC ID as a field so that older installations can also be included.

RM: Vpls MIB is FEC Type agnostic. FEC 128 and FEC 129 are in the

PW-MIB.

    Also, VC Id is only an identifier for a PW. Not the Vpls.

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

_______________________________________________

L2vpn mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 55, Issue 2

************************************

------_=_NextPart_001_01C9ACAD.BAAE72A9
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Vpls-MIB response to comments at IETF 73</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D178402000-09122008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D939372218-24032009>Hi Norival,</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D939372218-24032009>&nbsp;&nbsp; Please find my answers inline to =
your=20
questions inline.</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D939372218-24032009></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D939372218-24032009>thanks,</SPAN></FONT></FONT></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial><FONT =
color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D939372218-24032009>Rohit&nbsp;</SPAN></FONT></FONT></FONT><BR></D=
IV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Norival=20
Figueira<BR><B>Sent:</B> Friday, December 05, 2008 2:26 PM<BR><B>To:</B> =

[email-masked]<BR><B>Subject:</B> RE: Vpls-MIB response to comments at =
IETF=20
73<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/rtf format -->
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>Hi =
Rohit,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Thank you for=20
addressing below the questions I asked at the 73rd IETF's L2VPN WG =
meeting. I=20
would like to take this opportunity to further clarify those questions =
and=20
answer your questions below.</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
???: I have a=20
few questions for clarification.&nbsp; When I read the MIB,=20
there</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&#8217;</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>s</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2> a few things=20
that I couldn't find:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&gt;&nbsp; + VPLS=20
Instance ID in the Configuration Table;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&gt;&nbsp; + A way=20
to define the desired Class of Service to be used by the VPLS instance =
to be=20
used for tunnel selection;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
RM: Could we=20
get some more information on the above two and why its =
a</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
good idea to=20
add them to the next revision.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>VPLS =
Instance ID (VC=20
ID):</FONT></SPAN></P>
<P dir=3Dltr><FONT size=3D2><SPAN lang=3Den-us><FONT face=3D"Courier =
New">In the context=20
of LDP signaling for VPLS defined in RFC4762, LDP is used for signaling =
a full=20
mesh of pseudowires interconnecting VPLS instances. LDP pseudowire id =
(PWid)=20
Forwarding Equivalence Class (FEC) element 128 was originally used to =
carry=20
pseudowire parameters. This is still used and supported by most of the =
existing=20
RFC4762 implementations in the market. Please note that although RFC4762 =
defines=20
the use of the Generalized PWid FEC 129, it also describes the use of =
FEC 128 in=20
Appendix A ("VPLS Signaling using the PWid FEC Element"), which states =
that=20
"</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN =

lang=3Den-us><FONT face=3D"Courier New">t</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></FONT><SPAN lang=3Den-us><FONT face=3D"Courier =
New"><FONT=20
size=3D2>his section is being retained because live deployments use this =
version=20
of the signaling for VPLS". Therefore, in order to support these =
existing=20
implementations, one also needs to define a VPLS Instance Id (or VC Id). =
In this=20
case, in each PE containing a VPLS instance for a given customer, the =
VPLS=20
instance is configured with a same VPLS Instance ID, which has global=20
significance across all PEs involved in the same VPLS instance. The VPLS =

instance ID is then used as the VC ID in the FEC element 128. PEs then =
correlate=20
pseudowires with corresponding VPLS instances using the VC ID value =
contained in=20
the FEC element 128.<BR><SPAN class=3D178402000-09122008><FONT =
face=3DArial=20
color=3D#0000ff>[rm]&nbsp;VC-ID is a per PW configuration, there is no =
requirement=20
for&nbsp;this&nbsp;to be globally unique.&nbsp;VC-ID per PW is captured =
in the=20
PW MIB. Bgp-Autodiscovery has a globally unique Vpls-Id which is =
captured in=20
this MIB.</FONT></SPAN></FONT></FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>The =
above reasoning=20
also justifies Sanjay's question</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>in your=20
original message</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>VPLS =
Class of=20
Service (CoS):</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>S</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>ome</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>service=20
providers</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>use a specific CoS for =
particular=20
VPLS</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2> =
instances</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>. In that case, the PE needs to=20
choose</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>an</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> appropriate LSP such as =
a</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>n</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2> L-LSP=20
that</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>best</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>satisfies the</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>desired</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>VPLS</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>CoS</FONT></SPAN><SPAN =

lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>.</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>A VPLS CoS=20
could be defined as a 3-bit value.</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>H</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>ow would a PE select =
appropriate LSPs=20
in regard</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>s</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> to CoS</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>for each=20
VPLS instance</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New"><FONT size=3D2>without an =
explicit definition=20
in the VPLS MIB?<BR><SPAN class=3D178402000-09122008><FONT face=3DArial=20
color=3D#0000ff>[rm]&nbsp;Choosing a tunnel is a PW function. Still not =
convinced=20
this belong&nbsp;in =
Vpls-MIB.&nbsp;</FONT></SPAN></FONT></FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
+ There are=20
pointers to the Bridge-MIB, but if would be useful if there=20
was</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
a place in MIB=20
to define the maximum # of MAC addresses that should =
be</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
learned by a=20
specific VPLS instance.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
RM: There was=20
an object vplsPwBindMacAddressLimit in an earlier =
revision.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
<A=20
href=3D"http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt">http=
://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt</A></FONT></SPAN>=
</P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
&lt;<A=20
href=3D"http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt">http=
://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt</A>&gt;</FONT></S=
PAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
This was=20
removed after suggestion from the group in Montreal-IETF,=20
refer</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
to discussion=20
in Montreal</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>VPLS =
Maximum Number=20
of MAC addresses:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>My =
understanding=20
from the Montreal discussions is that the group was concerned with the=20
definition in the VPLS MIB of features that are implementation specific. =
I also=20
agree that implementation specific definitions should not be part of a =
standard=20
VPLS MIB. However, defining the maximum number of MAC addressed for a =
VPLS=20
instance is not an implementation specific issue. A VPLS maximum number =
of MAC=20
addresses is needed to support service provider's L2VPN business models. =
Without=20
this feature, service providers will not able to properly deploy large =
scale=20
VPLS services.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Service providers=20
deploying VPLS as an L2VPN service usually define L2VPN business models =
with=20
different service levels. For example (completely hypothetical), a =
service=20
provider may define a customer VPLS service starting at a maximum of 40 =
MAC=20
addresses and charge for additional increments of 40 MAC addresses. This =

business model allows the service provider to optimize MAC address table =

resources and to plan the capacity of its network in terms of the number =
of VPLS=20
instances that can be supported by each PE (i.e., it allows the service =
provider=20
to define admission control policies that take PEs' MAC address tables'=20
capabilities into consideration). Defining a maximum number of MAC =
addresses per=20
VPLS instance is also necessary to protect the network against customer=20
(unintended or intended) MAC address storm attacks. Without a per VPLS =
(i.e.,=20
customer) limit, a single VPLS could consume the whole MAC address table =

available in a PE. This would cause service disruption to other VPLS=20
customers.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Please note that the=20
maximum number of MAC addresses discussed here is a VPLS instance =
property. The=20
MAC address limits defined earlier in vplsLdpPwBindMacAddressLimit =
(which was=20
later removed) and in vplsPwBindMacAddressLimit (which is still defined =
in the=20
current VPLS MIB draft), represent something else and are not =
appropriate to=20
provide an overall VPLS</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>MAC</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>address limit. An =
overall VPLS MAC=20
address limit does not care for how many MAC addresses were learned by =
specific=20
PWs or endpoint interfaces. An overall VPLS MAC address limit is what =
service=20
providers care about to implement their L2VPN business models and to =
allow for=20
the proper management and protection of individual VPLS=20
services.</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Please note that=20
with the advent of PBB</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>-VPLS=20
integration, customer MAC addresses</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>will</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2> no =
longer</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>be</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>learn</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>ed</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2></FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>by</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2> VPLS instances. This =
could be=20
used</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>by =
someone</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>as an argument against =
the</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> inclusion of a VPLS MAC limit in the VPLS =
MIB.=20
However, the VPLS MIB must be applicable to existing deployments where =
PBB-VPLS=20
integration is not used.</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>Please</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> note that customer MAC addresses will be =
learned by=20
PEs that also provide PBB Backbone Edge Bridge (BEB)functionality, but=20
th</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>is</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> is a subject for</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>a</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>separate</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>discussion</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>on=20
a</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us>=20
<FONT face=3D"Courier New" size=3D2>PBB-VPLS</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2></FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"><FONT =

size=3D2>thread.<BR><SPAN class=3D178402000-09122008><FONT face=3DArial=20
color=3D#0000ff>[rm]&nbsp;Point well taken, we will certainly deliberate =
over this=20
in the next revision. It will be good to understand what is the level of =

interest for this.</FONT></SPAN></FONT></FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
+ It would be=20
useful if there was a way to allow someone to clear the =
MAC</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&gt;&nbsp; addresses=20
in a VPLS instance.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
RM: Should this=20
exist in the Vpls-MIB ? Why ?</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>VPLS =
Clear MAC=20
Addresses:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>The =
group has been=20
discussing different ways to flush the learned MAC address of a VPLS =
instance to=20
support dual homing. In simple terms, with dual homing a CPE (customer=20
premises</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>equipment</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New"><FONT size=3D2>) could be physically attached to =
two PEs=20
supporting a VPLS service for the customer. Only one PE would initially =
forward=20
the customer traffic. In the event that the active PE lost connectivity =
to the=20
CPE or the PE itself failed, the other PE would take over the =
responsibility of=20
forwarding the customer traffic. Without further actions, this could =
create a=20
"black hole" effect where other PE's in the network would continue to =
send=20
traffic to the original PE until learned MAC entries aged out or were =
re-learned=20
to point to the new PE as the proper destination. To solve this problem, =
one can=20
use explicit MAC withdraw (or flush) messages or implicit mechanisms to=20
determined that a MAC flush is required. In both cases, a MAC flush is =
only=20
issued when there is a VPLS service switchover from on PE to another PE =
in a=20
dual homing scenario. The case exists for allowing one to manually=20
(administratively) flush the learned MAC addresses of a VPLS instances =
(for dual=20
homing and non-dual homing scenarios). This is useful for debugging =
purposes=20
(e.g., the service provider wants to re-start MAC learning for a =
particular VPLS=20
instance) and also for allowing the manual switchover of service from =
one PE to=20
another (e.g., in a non-dual homing scenario).<BR><SPAN=20
class=3D178402000-09122008><FONT face=3DArial =
color=3D#0000ff>[rm]&nbsp;Do we=20
have&nbsp;further interest in this being added to Vpls-MIB=20
?&nbsp;</FONT></SPAN></FONT></FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
+ You point to=20
Bridge-MIB, but I don't see a clear identification of =
the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&gt;&nbsp;=20
interfaces that are bound to a VPLS instance.&nbsp; I see that for the=20
PW</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
side, but I=20
don't see that for the interfaces.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
RM: This is the=20
issue where AC is a PW. We've raised this a few times</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
and have not=20
really</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>&gt; =
been able to=20
solicit a clear approach to tackling this.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>VSIs are interconnected =
by a full=20
mesh of network pseudowires. To provide services to customers a VSI must =
also=20
support port mode and tagged mode (VLAN) attachments (or endpoints). My =
question=20
regards these two types. Analogous to the PW bind table defined in the =
VPLS MIB,=20
one could have an explicit attachment bind table (possibly indexed by=20
vplsConfigIndex and ifindex of endpoint).</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>There seems to be a =
lean towards SNMP=20
Context Mapping MIB to represent the endpoints.</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2></FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New" =
size=3D2>However,=20
this seems to only apply in the context of SNMP v3. For SNMPv2c and =
SNMPv1, each=20
context will need to be mapped to</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>a</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>community string, =
which will need to=20
be configured on the management station. This</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT=20
face=3D"Courier New" size=3D2>seems</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>=20
impractical</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>,</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> since</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>any</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2> number of VPLS =
instances are=20
possible</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>, =
with</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2> each</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us> <FONT face=3D"Courier New"=20
size=3D2>one</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us> <FONT face=3D"Courier New" size=3D2>having its own unique =
endpoint=20
attachment</FONT></SPAN><SPAN lang=3Den-us></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us><FONT face=3D"Courier New" size=3D2>s</FONT></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us><FONT=20
face=3D"Courier New" size=3D2>.</FONT></SPAN><SPAN =
lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us></SPAN><SPAN lang=3Den-us></SPAN><SPAN=20
lang=3Den-us></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>Regards,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Norival=20
Figueira</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>----------------------------------------------------------------=
------</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Date: Tue, 2 Dec=20
2008 17:38:32 -0600</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>From: "MEDIRATTA=20
Rohit" &lt;[email-masked]&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Subject: Vpls-MIB=20
response to comments at IETF 73</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>To:=20
&lt;[email-masked]&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>Cc: =
Agrahara S Kiran=20
Koushik &lt;[email-masked]&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>Message-ID:</FONT></SPAN></P>
<P dir=3Dltr><SPAN =
lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT=20
face=3D"Courier New"=20
size=3D2>&lt;[email-masked].=
alcatel.com&gt;</FONT></SPAN></P>
<P dir=3Dltr><SPAN =
lang=3Den-us>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Content-Type:=20
text/plain;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
charset=3D"us-ascii"</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>Hi=20
All,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp; Please=20
find the response to the questions raised w.r.t to VPLS-MIB =
at</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>IETF-73.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>The =
response to the=20
questions are preprended with RM:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>Regards,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Rohit, Kiran &amp;=20
Tom.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>-----------------------------</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;Questions:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>- =
Kireeti Kompella:=20
You say that VplsBgpRteTargetEntry allows H-VPLS</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>representation, but=20
that seems pretty orthogonal.&nbsp; Can you explain =
that?</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
RT's can be used=20
to filter which "l2vpn route" should be accepted by</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>each =

Node.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Consider the=20
following setup</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>A-----B------C------D</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
|</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; E&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
F</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>Assuming</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on A is=20
setup to import RT from B only, export RT-A.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on B is=20
setup to import RT from A,C and E, export RT-B</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on C is=20
setup to import RT from B,D and F, export RT-C</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on D is=20
setup to import RT from C only, export RT-D.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on E is=20
setup to import RT from B only, export RT-E.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>Vpls/Bgp on F is=20
setup to import RT from C only, export RT-F.</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>This =
will lead to=20
the following PW Setup.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>A----B=3D=3D=3D=3D=3DC----D</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; E&nbsp;&nbsp;&nbsp;&nbsp; =
F</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>This =
gives Providers=20
the flexibility to engineer the Auto-discovered</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>PW's.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>To =
provide the=20
ability to import/export multiple RT's per Vpls we =
needed</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>to =
break RT into a=20
separate table.</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>- =
???: I have a few=20
questions for clarification.&nbsp; When I read the =
MIB,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>there's</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>a =
few things that I=20
couldn't find:</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; + VPLS=20
Instance ID in the Configuration Table;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; + A way to=20
define the desired Class of Service to be used by the =
VPLS</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; instance to=20
be used for tunnel selection;</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
Could we get=20
some more information on the above two and why its a</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>good =
idea to add=20
them to the next revision.</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>+ =
There are pointers=20
to the Bridge-MIB, but if would be useful if there</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>was</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; a place in=20
MIB to define the maximum # of MAC addresses that should =
be</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; learned by a=20
specific VPLS instance.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
There was an=20
object vplsPwBindMacAddressLimit in an earlier</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>revision.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2><A=20
href=3D"http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt">http=
://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt</A></FONT></SPAN>=
</P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&lt;<A=20
href=3D"http://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt">http=
://tools.ietf.org/id/draft-nadeau-l2vpn-vpls-mib-00.txt</A>&gt;</FONT></S=
PAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>This =
was removed=20
after suggestion from the group in Montreal-IETF, =
refer</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>to =
discussion in=20
Montreal</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>+ It =
would be useful=20
if there was a way to allow someone to clear the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>MAC</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; addresses in=20
a VPLS instance.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
Should this=20
exist in the Vpls-MIB ? Why ?</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>+ =
You point to=20
Bridge-MIB, but I don't see a clear identification of =
the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; interfaces=20
that are bound to a VPLS instance.&nbsp; I see that for the =
PW</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>side,</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp; but I don't=20
see that for the interfaces.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
This is the=20
issue where AC is a PW. We've raised this a few times</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>and =
have not=20
really</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>been =
able to solicit=20
a clear approach to tackling this.</FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>- =
Sanjay (?): MIB=20
you're using for configuration doesn't support old FEC</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>Type</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>using VC ID.&nbsp;=20
There are a lot of existing installations today that =
are</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>using</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>FEC =
128 and all of=20
them depend on the VC ID for the identifier of the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>VPLS</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>instance.&nbsp;=20
Would like you to consider in the VPLS instance, if you =
can</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>add=20
the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>VC =
ID as a field so=20
that older installations can also be included.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>RM: =
Vpls MIB is FEC=20
Type agnostic. FEC 128 and FEC 129 are in the</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>PW-MIB.</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp;&nbsp;=20
Also, VC Id is only an identifier for a PW. Not the=20
Vpls.</FONT></SPAN></P><BR><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>------------------------------</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>_______________________________________________</FONT></SPAN></P=
>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" =
size=3D2>L2vpn mailing=20
list</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>[email-masked]</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2><A=20
href=3D"https://www.ietf.org/mailman/listinfo/l2vpn">https://www.ietf.org=
/mailman/listinfo/l2vpn</A></FONT></SPAN></P><BR>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New" size=3D2>End =
of L2vpn Digest,=20
Vol 55, Issue 2</FONT></SPAN></P>
<P dir=3Dltr><SPAN lang=3Den-us><FONT face=3D"Courier New"=20
size=3D2>************************************</FONT></SPAN></P></BODY></H=
TML>

------_=_NextPart_001_01C9ACAD.BAAE72A9--

From [email-masked]  Tue Mar 24 20:05:23 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 25 Mar 2009 08:35:41 +0530
Subject: RE: Comments to LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS 
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>

Hi Max,
       =20
        Please refer inline.=20

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]=20
Sent: Monday, March 23, 2009 1:43 AM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]
Subject: Comments to LDP Extensions for Optimized MAC Address Withdrawal in=
 H-VPLS=20

Hi Pranjal,

Just want to highlight a deployment scenario that I forsee will have intero=
p issues. Although you stated in your paper regarding General Applicability=
 of PE-ID TLV, however there could be a case in the field when provisioning=
 PE-ID across the same VPLS VSI but spanning multiple PEs/mtu-s, the PE-ID =
is different per site. This could be due to misconfigurations or because of=
 interop limitation between vendors.

<=20
  The PE-ID is not provisioned and is derived from the VSI-ID of a VPLS ins=
tance in the n-PE that hosts the dual homes u-PEs. This would be=20
  always unique across a VPLS instance.
>

On the same figure 1 on your paper, if the same VPLS VSI is provisioned wit=
h same PE-ID between PE-4 and PE-2, but a different PE-ID between PE-2 and =
mtu-s. I forsee potential issue when Mtu-s switchover to PE-2, trigger a PE=
-ID but this is different between PE-2 and PE-4, which PE-2 will relay the =
PE-ID TLV.

<
  Didn't get exactly. Did you mean that PE-4 and PE-2 are configured with s=
ame VSI-ID in the vpls instance. Let's say in FEC128
  case, the PE-ID is (vc-id + 4 byte ldp lsr-id) on PE. Did you mean miscon=
figuration of LDP with same lsr-id in PE4 and PE-2?
  In FEC129 case, PE-ID is (AGI + AII) on PE. Did you mean misconfiguration=
 that would cause PE-4 and PE-2 to have same AII?

  In Figure 1, if MTU-s switches over to PE-2 from PE-1, then MTU-s would i=
nitiate flush with PE-ID to indicate=20
  the VSI in PE-1. PE-2 would relay the mac flush to all n-Pes in mesh with=
 same PE-ID (of PE-1).
>

So I suggest that either every PE will have to do a lookup to match the cor=
responding PE-ID before forwarding or you be specific in the paper that PE-=
ID of the same VPLS VSI is the same throughout the whole domain.

<
 Yes, PE-ID of the same VPLS VSI is same throughout the whole domain, since=
 PE-ID is derived from VSI-ID in a VPLS and VSI-ID has to be=20
 unique across all participating PE devices in a VPLS instance (unless misc=
onfigured). If it's not explicit in the draft, definitely we=20
 would address it in detail.
>

Generally, the draft has gone through 4 versions and has cover most scenari=
os. But just this above scenario that I've seen getting configured in the f=
ield that gets me worry.

regards,
Max

From [email-masked]  Sun Mar 29 19:01:23 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: IETF 74: DRAFT l2vpn WG Meeting Minute
Date: Sun, 29 Mar 2009 20:02:05 -0600

Hi All,

The WG meeting minutes have been posted to the IETF Web Site:
http://www.ietf.org/proceedings/09mar/minutes/l2vpn.txt

Please review them and if you have any comments or corrections, please  
e-mail the chairs.  The deadline for corrections is Friday, April 17.

Finally, we would like to thank Laurent Ciavaglia for taking the  
minutes.

-shane & Vach

From [email-masked]  Sun Mar 29 19:39:12 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Date: Sun, 29 Mar 2009 20:39:53 -0600

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a  
request by the authors to make this a WG draft.  Please indicate to  
the list if you do or don't support making this draft a WG document.   
The following is a URL for this draft:
http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence  
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 19:42:07 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Sun, 29 Mar 2009 20:42:49 -0600

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a  
request by the authors to make this a WG draft. Please indicate to the  
list if you do or don't support making this draft a WG document.  The  
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence  
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 19:48:57 2009
From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Sun, 29 Mar 2009 20:49:39 -0600

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a  
request by the authors to make this a WG draft. Please indicate to the  
list if you do or don't support making this draft a WG document.  The  
following is a URL for this draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence  
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous  
version of this draft (-03).  Please follow the procedures outlined in  
RFC 3979 and consult your own legal counsel in your decision-making  
process.

-shane

From [email-masked]  Sun Mar 29 21:07:58 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Sun, 29 Mar 2009 23:08:39 -0500
From: "BALUS Florin" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:50 PM
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:http://tools.ietf.org/html/draft-
> sajassi-l2vpn-vpls-pbb-interop-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> Finally, please note that there is IPR filed against a previous
> version of this draft (-03).  Please follow the procedures outlined in
> RFC 3979 and consult your own legal counsel in your decision-making
> process.
>=20
> -shane

From [email-masked]  Sun Mar 29 21:08:11 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Sun, 29 Mar 2009 23:08:52 -0500
From: "BALUS Florin" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Sun Mar 29 21:28:19 2009
Content-class: urn:content-classes:message
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Date: Sun, 29 Mar 2009 23:28:58 -0500
From: "BALUS Florin" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:40 PM
> To: [email-masked]
> Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft.  Please indicate to
> the list if you do or don't support making this draft a WG document.
> The following is a URL for this draft:
> http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Sun Mar 29 21:52:23 2009
Content-class: urn:content-classes:message
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Date: Mon, 30 Mar 2009 06:52:56 +0200
From: "HENDERICKX Wim" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: maandag 30 maart 2009 4:40
To: [email-masked]
Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft.  Please indicate to =20
the list if you do or don't support making this draft a WG document.  =20
The following is a URL for this draft:
http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 21:52:30 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 06:53:05 +0200
From: "HENDERICKX Wim" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: maandag 30 maart 2009 4:43
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 21:52:40 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 06:53:13 +0200
From: "HENDERICKX Wim" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: maandag 30 maart 2009 4:50
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this
draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous =20
version of this draft (-03).  Please follow the procedures outlined in =20
RFC 3979 and consult your own legal counsel in your decision-making =20
process.

-shane

From [email-masked]  Sun Mar 29 22:20:47 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 07:21:29 +0200
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Shane Amante" <[email-masked]>, <[email-masked]>

Hi,
I'll go over the draft again. In the meantime I'll appreciate if the
authors can clarify and help me resolve my confusion about this draft.=20
Apparently I thought the intention of the draft is to enhance
scalability, and to avoid the learning of all customers' MAC addresses.
In the last meeting there was a comment indicating that all I-SIDs are
handled in the E-NNI and that scalability is not really solved in this
case. It looks as the intention is to make more efficient replication at
the E-NNI.=20
Would the authors be so kind and clarify this to me.
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Shane Amante
Sent: Monday, March 30, 2009 04:50
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this
draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous =20
version of this draft (-03).  Please follow the procedures outlined in =20
RFC 3979 and consult your own legal counsel in your decision-making =20
process.

-shane

From [email-masked]  Sun Mar 29 22:53:42 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 11:23:29 +0530
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 7:43 PM
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 22:55:06 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 11:24:43 +0530
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 7:40 PM
To: [email-masked]
Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft.  Please indicate to =20
the list if you do or don't support making this draft a WG document.  =20
The following is a URL for this draft:
http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

-shane

From [email-masked]  Sun Mar 29 22:55:54 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 11:24:00 +0530
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 7:50 PM
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this draft:http://tools.ietf.org/html/draft-sajassi-=
l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous =20
version of this draft (-03).  Please follow the procedures outlined in =20
RFC 3979 and consult your own legal counsel in your decision-making =20
process.

-shane

From [email-masked]  Sun Mar 29 23:11:19 2009
From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 11:41:01 +0530
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 7:50 PM
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this draft:http://tools.ietf.org/html/draft-sajassi-=
l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous =20
version of this draft (-03).  Please follow the procedures outlined in =20
RFC 3979 and consult your own legal counsel in your decision-making =20
process.

-shane

From [email-masked]  Mon Mar 30 00:42:57 2009
From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 09:43:26 +0200
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.
./
Lieven

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:40 PM
> To: [email-masked]
> Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft.  Please indicate to
> the list if you do or don't support making this draft a WG document.
> The following is a URL for this draft:
> http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Mon Mar 30 00:43:18 2009
From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
To: Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 09:43:50 +0200
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.
./
Lieven
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Mon Mar 30 00:43:51 2009
From: "LEVRAU, LIEVEN (LIEVEN)" <[email-masked]>
To: "Balus, Florin Stelian (Florin)" <[email-masked]>, Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 30 Mar 2009 09:44:22 +0200
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.
./
Lieven

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shane Amante
> Sent: Sunday, March 29, 2009 7:50 PM
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:http://tools.ietf.org/html/draft-
> sajassi-l2vpn-vpls-pbb-interop-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> Finally, please note that there is IPR filed against a previous
> version of this draft (-03).  Please follow the procedures outlined in
> RFC 3979 and consult your own legal counsel in your decision-making
> process.
>=20
> -shane

From [email-masked]  Mon Mar 30 01:14:53 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 10:15:29 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Support.=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part =
de Shane Amante
Envoy=E9 : lundi 30 mars 2009 04:50
=C0 : [email-masked]
Objet : draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request =
by the authors to make this a WG draft. Please indicate to the list if =
you do or don't support making this draft a WG document.  The following =
is a URL for this =
draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous version =
of this draft (-03).  Please follow the procedures outlined in RFC 3979 =
and consult your own legal counsel in your decision-making process.

-shane

From [email-masked]  Mon Mar 30 01:14:53 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 10:15:25 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Support.=20

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part =
de Shane Amante
Envoy=E9 : lundi 30 mars 2009 04:43
=C0 : [email-masked]
Objet : draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request =
by the authors to make this a WG draft. Please indicate to the list if =
you do or don't support making this draft a WG document.  The following =
is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =
will not be counted as acceptance.

-shane

From [email-masked]  Mon Mar 30 10:28:34 2009
Content-class: urn:content-classes:message
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Date: Mon, 30 Mar 2009 12:29:24 -0500
From: "AISSAOUI Mustapha" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

Mustapha.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shane Amante
> Sent: Sunday, March 29, 2009 10:40 PM
> To: [email-masked]
> Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft.  Please=20
> indicate to =20
> the list if you do or don't support making this draft a WG=20
> document.  =20
> The following is a URL for this draft:
> http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 10:31:57 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 12:32:40 -0500
From: "AISSAOUI Mustapha" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

Mustapha.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shane Amante
> Sent: Sunday, March 29, 2009 10:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft. Please=20
> indicate to the list if you do or don't support making this=20
> draft a WG document.  The following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 10:36:36 2009
Content-class: urn:content-classes:message
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Date: Mon, 30 Mar 2009 12:37:26 -0500
From: "MEDIRATTA Rohit" <[email-masked]>
To: <[email-masked]>

Support.

-Rohit =20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: Sunday, March 29, 2009 6:40 PM
To: [email-masked]
Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request
by the authors to make this a WG draft.  Please indicate to =20
the list if you do or don't support making this draft a WG document.  =20
The following is a URL for this draft:
http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence
will not be counted as acceptance.

-shane

From [email-masked]  Mon Mar 30 10:37:01 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 12:37:50 -0500
From: "MEDIRATTA Rohit" <[email-masked]>
To: <[email-masked]>

Support,

-Rohit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: Sunday, March 29, 2009 6:43 PM
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request
by the authors to make this a WG draft. Please indicate to the list if
you do or don't support making this draft a WG document.  The following
is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence
will not be counted as acceptance.

-shane

From [email-masked]  Mon Mar 30 10:39:18 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 12:39:55 -0500
From: "AISSAOUI Mustapha" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.

Mustapha.=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shane Amante
> Sent: Sunday, March 29, 2009 10:50 PM
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft. Please=20
> indicate to the list if you do or don't support making this=20
> draft a WG document.  The following is a URL for this=20
> draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> interop-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> Finally, please note that there is IPR filed against a=20
> previous version of this draft (-03).  Please follow the=20
> procedures outlined in RFC 3979 and consult your own legal=20
> counsel in your decision-making process.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 12:12:30 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 12:13:19 -0700
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "ext Shane Amante" <[email-masked]>, <[email-masked]>

Hi Nurit,=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> Sent: Sunday, March 29, 2009 10:21 PM
> To: ext Shane Amante; [email-masked]
> Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi,
> I'll go over the draft again. In the meantime I'll appreciate=20
> if the authors can clarify and help me resolve my confusion=20
> about this draft.=20
> Apparently I thought the intention of the draft is to enhance=20
> scalability, and to avoid the learning of all customers' MAC=20
> addresses.

The purpose of PBB encap is two fold: a) for C-MAC scalability and b)
for PW scalability
=20
> In the last meeting there was a comment indicating that all=20
> I-SIDs are handled in the E-NNI and that scalability is not=20
> really solved in this case. It looks as the intention is to=20
> make more efficient replication at the E-NNI.

It is not clear to me what scenario you are referring to but there is no
C-MAC learning & forwarding at E-NNI between PBB network and VPLS core
network. In case of loosely-coupled I-SID domains, no I-SID translation
is required at E-NNI. And in case of independent I-SID domains, I-SID
translation may be required at E-NNI. However, no C-MAC address lookup
is required at E-NNI for both of these cases.

Cheers,
Ali
=20
> Would the authors be so kind and clarify this to me.
> Best regards,
> Nurit
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of ext Shane Amante
> Sent: Monday, March 30, 2009 04:50
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft. Please=20
> indicate to the list if you do or don't support making this=20
> draft a WG document.  The following is a URL for this
> draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> interop-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> Finally, please note that there is IPR filed against a=20
> previous version of this draft (-03).  Please follow the=20
> procedures outlined in RFC 3979 and consult your own legal=20
> counsel in your decision-making process.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 12:12:30 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 12:13:20 -0700
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shane Amante
> Sent: Sunday, March 29, 2009 7:50 PM
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft. Please=20
> indicate to the list if you do or don't support making this=20
> draft a WG document.  The following is a URL for this=20
> draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> interop-04
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> Finally, please note that there is IPR filed against a=20
> previous version of this draft (-03).  Please follow the=20
> procedures outlined in RFC 3979 and consult your own legal=20
> counsel in your decision-making process.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 12:14:31 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 12:13:20 -0700
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shane Amante
> Sent: Sunday, March 29, 2009 7:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there=20
> was a request by the authors to make this a WG draft. Please=20
> indicate to the list if you do or don't support making this=20
> draft a WG document.  The following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17. =20
> Silence will not be counted as acceptance.
>=20
> -shane
>=20

From [email-masked]  Mon Mar 30 12:27:41 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Mon, 30 Mar 2009 12:28:36 -0700
From: "Samer Salam (ssalam)" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf Of Shane Amante
>Sent: Sunday, March 29, 2009 7:43 PM
>To: [email-masked]
>Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>
>Hi All,
>
>At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
>request by the authors to make this a WG draft. Please=20
>indicate to the =20
>list if you do or don't support making this draft a WG document.  The =20
>following is a URL for this draft:
>http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>
>The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
>will not be counted as acceptance.
>
>-shane
>

From [email-masked]  Mon Mar 30 12:28:12 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Mon, 30 Mar 2009 12:28:52 -0700
From: "Samer Salam (ssalam)" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Support.=20

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]=20
>On Behalf Of Shane Amante
>Sent: Sunday, March 29, 2009 7:50 PM
>To: [email-masked]
>Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>
>Hi All,
>
>At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
>request by the authors to make this a WG draft. Please=20
>indicate to the =20
>list if you do or don't support making this draft a WG document.  The =20
>following is a URL for this=20
>draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-i
>nterop-04
>
>The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
>will not be counted as acceptance.
>
>Finally, please note that there is IPR filed against a previous =20
>version of this draft (-03).  Please follow the procedures=20
>outlined in =20
>RFC 3979 and consult your own legal counsel in your decision-making =20
>process.
>
>-shane
>

From [email-masked]  Tue Mar 31 00:16:59 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Tue, 31 Mar 2009 09:17:44 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Support

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf=20
>Of Shane Amante
>Sent: Sunday, March 29, 2009 7:50 PM
>To: [email-masked]
>Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>
>Hi All,
>
>At the L2VPN WG meeting at IETF 74 in San Francisco, there was a=20
>request by the authors to make this a WG draft. Please indicate to the=20
>list if you do or don't support making this draft a WG document.  The=20
>following is a URL for this=20
>draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-i
>nterop-04
>
>The deadline for comments will be 3 weeks: Friday, April 17.  Silence=20
>will not be counted as acceptance.
>
>Finally, please note that there is IPR filed against a previous version

>of this draft (-03).  Please follow the procedures outlined in RFC 3979

>and consult your own legal counsel in your decision-making process.
>
>-shane
>

From [email-masked]  Tue Mar 31 05:52:15 2009
From: Olen Stokes <[email-masked]>
To: 'Shane Amante' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Mar 2009 05:53:13 -0700
Subject: RE: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Cheers,
Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 10:40 PM
To: [email-masked]
Subject: draft-pdutta-l2vpn-vpls-ldp-mac-opt-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
request by the authors to make this a WG draft.  Please indicate to
the list if you do or don't support making this draft a WG document.
The following is a URL for this draft:
http://tools.ietf.org/html/draft-pdutta-l2vpn-vpls-ldp-mac-opt-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence
will not be counted as acceptance.

-shane

From [email-masked]  Tue Mar 31 05:53:15 2009
From: Olen Stokes <[email-masked]>
To: 'Shane Amante' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Mar 2009 05:53:54 -0700
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Support.

Cheers,
Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S=
hane Amante
Sent: Sunday, March 29, 2009 10:43 PM
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
request by the authors to make this a WG draft. Please indicate to the
list if you do or don't support making this draft a WG document.  The
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence
will not be counted as acceptance.

-shane

From [email-masked]  Tue Mar 31 06:34:59 2009
From: "Shahram Davari" <[email-masked]>
To: "'Shane Amante'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 09:35:56 -0400
Reply-To: [email-masked]

Hi,

I also support. However, text needs to be added to the Introduction to make
it clear that similar to H-VPLS, the PBB over VPLS method (this draft) is
another method to overcome the scalability issue of VPLS that exist due to
the large number of required PWs. The PBB over VPLS reduces the number of
required PWs and therefore improves VPLS scalability..

Best regards,
Shahram 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shane Amante
Sent: Sunday, March 29, 2009 10:43 PM
To: [email-masked]
Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
request by the authors to make this a WG draft. Please indicate to the
list if you do or don't support making this draft a WG document.  The
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence
will not be counted as acceptance.

-shane

From [email-masked]  Tue Mar 31 07:02:19 2009
Content-class: urn:content-classes:message
Subject: AW: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 16:02:56 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Support.=20

Best Regards
Manuel

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag =
von Shane Amante
Gesendet: Montag, 30. M=E4rz 2009 04:43
An: [email-masked]
Betreff: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

-shane

From [email-masked]  Tue Mar 31 07:31:02 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 16:31:59 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Support.

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag =
von Shane Amante
Gesendet: Montag, 30. M=E4rz 2009 04:43
An: [email-masked]
Betreff: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request =
by the authors to make this a WG draft. Please indicate to the list if =
you do or don't support making this draft a WG document.  The following =
is a URL for this draft:
http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =
will not be counted as acceptance.

-shane

From [email-masked]  Tue Mar 31 07:43:45 2009
Date: Tue, 31 Mar 2009 10:44:28 -0400
Subject: Re: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
From: "Andrew G. Malis" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]

Support.

On Tue, Mar 31, 2009 at 3:17 AM,  <[email-masked]> wrot=
e:
> Support
>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf
>>Of Shane Amante
>>Sent: Sunday, March 29, 2009 7:50 PM
>>To: [email-masked]
>>Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>>
>>Hi All,
>>
>>At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
>>request by the authors to make this a WG draft. Please indicate to the
>>list if you do or don't support making this draft a WG document. =A0The
>>following is a URL for this
>>draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-i
>>nterop-04
>>
>>The deadline for comments will be 3 weeks: Friday, April 17. =A0Silence
>>will not be counted as acceptance.
>>
>>Finally, please note that there is IPR filed against a previous version
>
>>of this draft (-03). =A0Please follow the procedures outlined in RFC 3979
>
>>and consult your own legal counsel in your decision-making process.
>>
>>-shane
>>
>

From [email-masked]  Tue Mar 31 07:46:33 2009
Date: Tue, 31 Mar 2009 10:47:16 -0400
Subject: Re: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
From: "Andrew G. Malis" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]

Support.

On Tue, Mar 31, 2009 at 10:31 AM,  <[email-masked]> wro=
te:
> Support.
>
> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag vo=
n Shane Amante
> Gesendet: Montag, 30. M=E4rz 2009 04:43
> An: [email-masked]
> Betreff: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>
> Hi All,
>
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a request =
by the authors to make this a WG draft. Please indicate to the list if you =
do or don't support making this draft a WG document. =A0The following is a =
URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>
> The deadline for comments will be 3 weeks: Friday, April 17. =A0Silence w=
ill not be counted as acceptance.
>
> -shane
>

From [email-masked]  Tue Mar 31 08:53:36 2009
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Date: Tue, 31 Mar 2009 11:54:18 -0400
Subject: 
Accept-Language: en-US
acceptlanguage: en-US

--_000_EFAB6F21C0EA5D4A8AD8E43E7587C1290101F2D9C4MBX08bellcorp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

 Support.

Ketan Paralkar MIET , CCIE 12179, JNCIS
Sr. Network Architect
BELL SYSTEMS & TECHNOLOGY
Technology Development
Bell Canada
76 Adelaide Street West, 15th Floor
Toronto, Ontario
M5H 1P6
Office  (416)-353-3227
e-mail : [email-masked]<mailto:[email-masked]>

The information contained herein is proprietary to BCE/Bell Canada and may =
not be used, reproduced or disclosed to others except as specifically permi=
tted in writing by the originator of the information.  The recipient of thi=
s information, by its retention and use, agrees to protect it from any loss=
, theft or compromise.

> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Shane Amante

> Sent: Sunday, March 29, 2009 7:43 PM

> To: [email-masked]

> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

>

> Hi All,

>

> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a

> request by the authors to make this a WG draft. Please indicate to the

> list if you do or don't support making this draft a WG document.  The

> following is a URL for this draft:

> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01

>

> The deadline for comments will be 3 weeks: Friday, April 17.

> Silence will not be counted as acceptance.

>

> -shane

>

--_000_EFAB6F21C0EA5D4A8AD8E43E7587C1290101F2D9C4MBX08bellcorp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"Book Antiqua";
	panose-1:2 4 6 2 5 3 5 3 3 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:Georgia;
	panose-1:2 4 5 2 5 4 5 2 3 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.5pt;
	font-family:Consolas;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:Consolas;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1033" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-CA link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span lang=3DFR-CA style=3D'font-size:12.0pt;font-fami=
ly:"Times New Roman","serif"'>&nbsp;Support.<o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span lang=3DFR-CA
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p>&nbsp=
;</o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span lang=3DFR-CA
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p>&nbsp=
;</o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span lang=3DFR-CA
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:blue'=
>Ketan
Paralkar MIET , CCIE 12179,&nbsp;JNCIS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
12.0pt;font-family:"Times New Roman","serif";color:blue'>Sr. Network Archit=
ect<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
10.0pt;font-family:"Times New Roman","serif";color:blue'>BELL SYSTEMS &amp;
TECHNOLOGY<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
7.5pt;font-family:"Book Antiqua","serif";color:blue'>Technology Development=
</span></i></b><b><i><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:blue'><br>
</span></i></b><b><i><span style=3D'font-size:7.5pt;font-family:"Book Antiq=
ua","serif";
color:blue'>Bell</span></i></b><b><i><span style=3D'font-size:8.0pt;font-fa=
mily:
"Arial","sans-serif";color:blue'> </span></i></b><b><i><span style=3D'font-=
size:
7.5pt;font-family:"Book Antiqua","serif";color:blue'>Canada</span></i></b><=
b><i><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:blue'><br>
</span></i></b><b><i><span style=3D'font-size:7.5pt;font-family:"Book Antiq=
ua","serif";
color:blue'>76 Adelaide Street West, 15th Floor</span></i></b><b><i><span
style=3D'font-size:8.0pt;font-family:"Arial","sans-serif";color:blue'><br>
</span></i></b><b><i><span style=3D'font-size:7.5pt;font-family:"Book Antiq=
ua","serif";
color:blue'>Toronto</span></i></b><b><i><span style=3D'font-size:8.0pt;
font-family:"Arial","sans-serif";color:blue'>, </span></i></b><b><i><span
style=3D'font-size:7.5pt;font-family:"Book Antiqua","serif";color:blue'>Ont=
ario</span></i></b><b><i><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:blue'=
><o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
7.5pt;font-family:"Book Antiqua","serif";color:blue'>M5H 1P6</span></i></b>=
<b><i><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:blue'=
><o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
7.5pt;font-family:"Book Antiqua","serif";color:blue'>Office&nbsp;
(416)-353-3227<br>
</span></i></b><b><i><span style=3D'font-size:12.0pt;font-family:"Times New=
 Roman","serif";
color:blue'>e-mail : </span></i></b><b><i><span lang=3DPT-BR style=3D'font-=
size:
12.0pt;font-family:"Times New Roman","serif";color:blue'><a
href=3D"mailto:[email-masked]"><span lang=3DEN-CA style=3D'color:bl=
ue'>[email-masked]</span></a></span></i></b><b><i><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif";color:#3366=
FF'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <o:p></o:p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><b><i><span style=3D'font=
-size:
12.0pt;font-family:"Times New Roman","serif";color:#3366FF'><o:p>&nbsp;</o:=
p></span></i></b></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span style=3D'font-size:=
12.0pt;
font-family:"Times New Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span style=3D'font-size:=
12.0pt;
font-family:"Times New Roman","serif"'>&nbsp;<b><i><span style=3D'color:#33=
66FF'><o:p></o:p></span></i></b></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span style=3D'font-size:=
10.0pt;
font-family:"Georgia","serif";color:navy'>The information contained herein =
is
proprietary to BCE/Bell Canada and may not be used, reproduced or disclosed=
 to
others except as specifically permitted in writing by the originator of the
information.&nbsp; The recipient of this information, by its retention and =
use,
agrees to protect it from any loss, theft or compromise.</span><span
style=3D'font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p></o:p=
></span></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><span style=3D'font-size:=
12.0pt;
font-family:"Times New Roman","serif"'>&nbsp;<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:12.0pt;font-family:"Times New=
 Roman","serif"'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoPlainText>&gt; From: [email-masked]
[mailto:[email-masked]] On Behalf <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; Of Shane Amante<o:p></o:p></p>

<p class=3DMsoPlainText>&gt; Sent: Sunday, March 29, 2009 7:43 PM<o:p></o:p=
></p>

<p class=3DMsoPlainText>&gt; To: [email-masked]<o:p></o:p></p>

<p class=3DMsoPlainText>&gt; Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01=
 WG
draft?<o:p></o:p></p>

<p class=3DMsoPlainText>&gt; <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; Hi All,<o:p></o:p></p>

<p class=3DMsoPlainText>&gt; <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; At the L2VPN WG meeting at IETF 74 in San Fran=
cisco,
there was a <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; request by the authors to make this a WG draft=
.
Please indicate to the <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; list if you do or don't support making this dr=
aft a
WG document.&nbsp; The <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; following is a URL for this draft:<o:p></o:p><=
/p>

<p class=3DMsoPlainText>&gt; <a
href=3D"http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01">h=
ttp://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01</a><o:p></o=
:p></p>

<p class=3DMsoPlainText>&gt; <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; The deadline for comments will be 3 weeks: Fri=
day,
April 17.&nbsp; <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; Silence will not be counted as acceptance.<o:p=
></o:p></p>

<p class=3DMsoPlainText>&gt; <o:p></o:p></p>

<p class=3DMsoPlainText>&gt; -shane<o:p></o:p></p>

<p class=3DMsoPlainText>&gt; <o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_EFAB6F21C0EA5D4A8AD8E43E7587C1290101F2D9C4MBX08bellcorp_--

From [email-masked]  Tue Mar 31 11:26:21 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 13:27:05 -0500
From: "BALUS Florin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Shahram,

I thought we discussed this aspect in Introduction (section 1, see 3rd
paragraph starting at "A hierarchical solution for VPLS ..."). The PW
scaling is achieved because in the core infrastructure one needs to
maintain just one PW set for a B-component instead of M PW sets for M
I-components.

We did not get in the details of how PBB provides multiplexing of M
I-components into one B-component as this is described in detail in the
IEEE 802.1ah specification. And the L2VPN WG asked us to just reference
the IEEE spec for the details to make it easier to keep synchronization
between the two documents.

Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shahram Davari
> Sent: Tuesday, March 31, 2009 6:36 AM
> To: 'Shane Amante'; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi,
>=20
> I also support. However, text needs to be added to the Introduction to
> make
> it clear that similar to H-VPLS, the PBB over VPLS method (this draft)
> is
> another method to overcome the scalability issue of VPLS that exist
due
> to
> the large number of required PWs. The PBB over VPLS reduces the number
> of
> required PWs and therefore improves VPLS scalability..
>=20
> Best regards,
> Shahram
>=20
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> Shane Amante
> Sent: Sunday, March 29, 2009 10:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Tue Mar 31 11:49:30 2009
From: Peng He <[email-masked]>
To: "Ali Sajassi (sajassi)" <[email-masked]>, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, ext Shane Amante <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 31 Mar 2009 14:49:53 -0400
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Accept-Language: en-US
acceptlanguage: en-US

Hello Ali,

The titles of Fig 5 and Fig. 6 might be read as " H-VPLS with Mixed PBN and=
 PBBN Access: xxxx" instead of " H-VPLS with Mixed PBB and PBBN Access: xxx=
x".

Regards,
Peng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ali Sajassi (sajassi)
> Sent: Monday, March 30, 2009 3:13 PM
> To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Shane Amante;
> [email-masked]
> Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
>=20
> Hi Nurit,
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> > Sent: Sunday, March 29, 2009 10:21 PM
> > To: ext Shane Amante; [email-masked]
> > Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> >
> > Hi,
> > I'll go over the draft again. In the meantime I'll appreciate
> > if the authors can clarify and help me resolve my confusion
> > about this draft.
> > Apparently I thought the intention of the draft is to enhance
> > scalability, and to avoid the learning of all customers' MAC
> > addresses.
>=20
> The purpose of PBB encap is two fold: a) for C-MAC scalability and b)
> for PW scalability
>=20
> > In the last meeting there was a comment indicating that all
> > I-SIDs are handled in the E-NNI and that scalability is not
> > really solved in this case. It looks as the intention is to
> > make more efficient replication at the E-NNI.
>=20
> It is not clear to me what scenario you are referring to but there is
> no
> C-MAC learning & forwarding at E-NNI between PBB network and VPLS core
> network. In case of loosely-coupled I-SID domains, no I-SID translation
> is required at E-NNI. And in case of independent I-SID domains, I-SID
> translation may be required at E-NNI. However, no C-MAC address lookup
> is required at E-NNI for both of these cases.
>=20
> Cheers,
> Ali
>=20
> > Would the authors be so kind and clarify this to me.
> > Best regards,
> > Nurit
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > On Behalf Of ext Shane Amante
> > Sent: Monday, March 30, 2009 04:50
> > To: [email-masked]
> > Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> >
> > Hi All,
> >
> > At the L2VPN WG meeting at IETF 74 in San Francisco, there
> > was a request by the authors to make this a WG draft. Please
> > indicate to the list if you do or don't support making this
> > draft a WG document.  The following is a URL for this
> > draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> > interop-04
> >
> > The deadline for comments will be 3 weeks: Friday, April 17.
> > Silence will not be counted as acceptance.
> >
> > Finally, please note that there is IPR filed against a
> > previous version of this draft (-03).  Please follow the
> > procedures outlined in RFC 3979 and consult your own legal
> > counsel in your decision-making process.
> >
> > -shane
> >

From [email-masked]  Tue Mar 31 11:52:46 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 14:53:25 -0400
From: "David Allan" <[email-masked]>
To: <[email-masked]>

I agree with the single PW mesh for B-component aspect (vs. many
I-component meshes) and the mention of IEEE protocol snooping for
multicast containment...but I'd like to see 802.1aq also mentioned in
section 6 as a means of controlling filtering of multicast...

Cheers
Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf

> Of Shane Amante
> Sent: Sunday, March 29, 2009 10:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi All,
>=20
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a=20
> request by the authors to make this a WG draft. Please indicate to the

> list if you do or don't support making this draft a WG document.  The=20
> following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
>=20
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence=20
> will not be counted as acceptance.
>=20
> -shane

From [email-masked]  Tue Mar 31 12:15:37 2009
From: "Shahram Davari" <[email-masked]>
To: "'BALUS Florin'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 15:16:34 -0400
Reply-To: [email-masked]

Hi Florin,

It does to some extent. But I think it Introduction text needs to better
reflect what you described below. Since it is not very clear what the
objective of this draft is and how it achieves such objectives.

Best regards,
Shahram

-----Original Message-----
From: BALUS Florin [mailto:[email-masked]] 
Sent: March-31-09 2:27 PM
To: [email-masked]; [email-masked]
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?

Hi Shahram,

I thought we discussed this aspect in Introduction (section 1, see 3rd
paragraph starting at "A hierarchical solution for VPLS ..."). The PW
scaling is achieved because in the core infrastructure one needs to
maintain just one PW set for a B-component instead of M PW sets for M
I-components.

We did not get in the details of how PBB provides multiplexing of M
I-components into one B-component as this is described in detail in the
IEEE 802.1ah specification. And the L2VPN WG asked us to just reference
the IEEE spec for the details to make it easier to keep synchronization
between the two documents.

Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Shahram Davari
> Sent: Tuesday, March 31, 2009 6:36 AM
> To: 'Shane Amante'; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> 
> Hi,
> 
> I also support. However, text needs to be added to the Introduction to
> make
> it clear that similar to H-VPLS, the PBB over VPLS method (this draft)
> is
> another method to overcome the scalability issue of VPLS that exist
due
> to
> the large number of required PWs. The PBB over VPLS reduces the number
> of
> required PWs and therefore improves VPLS scalability..
> 
> Best regards,
> Shahram
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> Shane Amante
> Sent: Sunday, March 29, 2009 10:43 PM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> 
> Hi All,
> 
> At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> request by the authors to make this a WG draft. Please indicate to the
> list if you do or don't support making this draft a WG document.  The
> following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
> 
> The deadline for comments will be 3 weeks: Friday, April 17.  Silence
> will not be counted as acceptance.
> 
> -shane

From [email-masked]  Tue Mar 31 12:18:10 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Tue, 31 Mar 2009 12:19:07 -0700
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: "Peng He" <[email-masked]>, "Sprecher, Nurit (NSN -IL/Hod HaSharon)" <[email-masked]>, "ext Shane Amante" <[email-masked]>, <[email-masked]>

You're correct. It should be "PBN" in both fig 5 & 6. I will update it
for the next rev.

Thanks,
Ali=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Peng He
> Sent: Tuesday, March 31, 2009 11:50 AM
> To: Ali Sajassi (sajassi); Sprecher, Nurit (NSN -IL/Hod=20
> HaSharon); ext Shane Amante; [email-masked]
> Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
>=20
> Hello Ali,
>=20
> The titles of Fig 5 and Fig. 6 might be read as " H-VPLS with=20
> Mixed PBN and PBBN Access: xxxx" instead of " H-VPLS with=20
> Mixed PBB and PBBN Access: xxxx".
>=20
>=20
> Regards,
> Peng
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> [mailto:[email-masked]] On Behalf=20
> > Of Ali Sajassi (sajassi)
> > Sent: Monday, March 30, 2009 3:13 PM
> > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Shane Amante;=20
> > [email-masked]
> > Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> >=20
> >=20
> > Hi Nurit,
> >=20
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On=20
> > > Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> > > Sent: Sunday, March 29, 2009 10:21 PM
> > > To: ext Shane Amante; [email-masked]
> > > Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> > >
> > > Hi,
> > > I'll go over the draft again. In the meantime I'll=20
> appreciate if the=20
> > > authors can clarify and help me resolve my confusion about this=20
> > > draft.
> > > Apparently I thought the intention of the draft is to enhance=20
> > > scalability, and to avoid the learning of all customers' MAC=20
> > > addresses.
> >=20
> > The purpose of PBB encap is two fold: a) for C-MAC=20
> scalability and b)=20
> > for PW scalability
> >=20
> > > In the last meeting there was a comment indicating that=20
> all I-SIDs=20
> > > are handled in the E-NNI and that scalability is not=20
> really solved=20
> > > in this case. It looks as the intention is to make more efficient=20
> > > replication at the E-NNI.
> >=20
> > It is not clear to me what scenario you are referring to=20
> but there is=20
> > no C-MAC learning & forwarding at E-NNI between PBB network=20
> and VPLS=20
> > core network. In case of loosely-coupled I-SID domains, no I-SID=20
> > translation is required at E-NNI. And in case of independent I-SID=20
> > domains, I-SID translation may be required at E-NNI.=20
> However, no C-MAC=20
> > address lookup is required at E-NNI for both of these cases.
> >=20
> > Cheers,
> > Ali
> >=20
> > > Would the authors be so kind and clarify this to me.
> > > Best regards,
> > > Nurit
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]] On=20
> > > Behalf Of ext Shane Amante
> > > Sent: Monday, March 30, 2009 04:50
> > > To: [email-masked]
> > > Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> > >
> > > Hi All,
> > >
> > > At the L2VPN WG meeting at IETF 74 in San Francisco, there was a=20
> > > request by the authors to make this a WG draft. Please=20
> indicate to=20
> > > the list if you do or don't support making this draft a=20
> WG document. =20
> > > The following is a URL for this
> > > draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> > > interop-04
> > >
> > > The deadline for comments will be 3 weeks: Friday, April 17.
> > > Silence will not be counted as acceptance.
> > >
> > > Finally, please note that there is IPR filed against a previous=20
> > > version of this draft (-03).  Please follow the=20
> procedures outlined=20
> > > in RFC 3979 and consult your own legal counsel in your=20
> > > decision-making process.
> > >
> > > -shane
> > >
>=20

From [email-masked]  Tue Mar 31 12:31:43 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 12:32:41 -0700
From: "Ali Sajassi (sajassi)" <[email-masked]>
To: <[email-masked]>, "BALUS Florin" <[email-masked]>, <[email-masked]>

Hi Shahram,

The bottom of the 3rd paragraph (intro sec.) describes how we get PW
scalability with PBB-VPLS versus VPLS. If the description is not clear,
let us know how we can improve the text and we'll consider it in the
next rev.

Cheers,
Ali=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]=20
> On Behalf Of Shahram Davari
> Sent: Tuesday, March 31, 2009 12:17 PM
> To: 'BALUS Florin'; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi Florin,
>=20
> It does to some extent. But I think it Introduction text=20
> needs to better reflect what you described below. Since it is=20
> not very clear what the objective of this draft is and how it=20
> achieves such objectives.
>=20
> Best regards,
> Shahram
>=20
> -----Original Message-----
> From: BALUS Florin [mailto:[email-masked]]
> Sent: March-31-09 2:27 PM
> To: [email-masked]; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi Shahram,
>=20
> I thought we discussed this aspect in Introduction (section=20
> 1, see 3rd paragraph starting at "A hierarchical solution for=20
> VPLS ..."). The PW scaling is achieved because in the core=20
> infrastructure one needs to maintain just one PW set for a=20
> B-component instead of M PW sets for M I-components.
>=20
> We did not get in the details of how PBB provides=20
> multiplexing of M I-components into one B-component as this=20
> is described in detail in the IEEE 802.1ah specification. And=20
> the L2VPN WG asked us to just reference the IEEE spec for the=20
> details to make it easier to keep synchronization between the=20
> two documents.
>=20
> Florin
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> [mailto:[email-masked]] On Behalf=20
> > Of Shahram Davari
> > Sent: Tuesday, March 31, 2009 6:36 AM
> > To: 'Shane Amante'; [email-masked]
> > Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> >=20
> > Hi,
> >=20
> > I also support. However, text needs to be added to the=20
> Introduction to=20
> > make it clear that similar to H-VPLS, the PBB over VPLS=20
> method (this=20
> > draft) is another method to overcome the scalability issue of VPLS=20
> > that exist
> due
> > to
> > the large number of required PWs. The PBB over VPLS reduces=20
> the number=20
> > of required PWs and therefore improves VPLS scalability..
> >=20
> > Best regards,
> > Shahram
> >=20
> > -----Original Message-----
> > From: [email-masked]=20
> [mailto:[email-masked]] On Behalf=20
> > Of Shane Amante
> > Sent: Sunday, March 29, 2009 10:43 PM
> > To: [email-masked]
> > Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> >=20
> > Hi All,
> >=20
> > At the L2VPN WG meeting at IETF 74 in San Francisco, there was a=20
> > request by the authors to make this a WG draft. Please=20
> indicate to the=20
> > list if you do or don't support making this draft a WG=20
> document.  The=20
> > following is a URL for this draft:
> > http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
> >=20
> > The deadline for comments will be 3 weeks: Friday, April=20
> 17.  Silence=20
> > will not be counted as acceptance.
> >=20
> > -shane
>=20
>=20

From [email-masked]  Tue Mar 31 12:40:01 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 14:40:41 -0500
From: "BALUS Florin" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Shahram,
The paragraph I mentioned below highlights we believe the problem space:
scalability of MAC table and service instances (including PW set). But
we will definitely take another shot at the Introduction in the next
revision of the draft to improve readability and address your comment.=20
Florin

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Tuesday, March 31, 2009 12:17 PM
> To: BALUS Florin; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi Florin,
>=20
> It does to some extent. But I think it Introduction text needs to
> better
> reflect what you described below. Since it is not very clear what the
> objective of this draft is and how it achieves such objectives.
>=20
> Best regards,
> Shahram
>=20
> -----Original Message-----
> From: BALUS Florin [mailto:[email-masked]]
> Sent: March-31-09 2:27 PM
> To: [email-masked]; [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> Hi Shahram,
>=20
> I thought we discussed this aspect in Introduction (section 1, see 3rd
> paragraph starting at "A hierarchical solution for VPLS ..."). The PW
> scaling is achieved because in the core infrastructure one needs to
> maintain just one PW set for a B-component instead of M PW sets for M
> I-components.
>=20
> We did not get in the details of how PBB provides multiplexing of M
> I-components into one B-component as this is described in detail in
the
> IEEE 802.1ah specification. And the L2VPN WG asked us to just
reference
> the IEEE spec for the details to make it easier to keep
synchronization
> between the two documents.
>=20
> Florin
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Shahram Davari
> > Sent: Tuesday, March 31, 2009 6:36 AM
> > To: 'Shane Amante'; [email-masked]
> > Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> >
> > Hi,
> >
> > I also support. However, text needs to be added to the Introduction
> to
> > make
> > it clear that similar to H-VPLS, the PBB over VPLS method (this
> draft)
> > is
> > another method to overcome the scalability issue of VPLS that exist
> due
> > to
> > the large number of required PWs. The PBB over VPLS reduces the
> number
> > of
> > required PWs and therefore improves VPLS scalability..
> >
> > Best regards,
> > Shahram
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of
> > Shane Amante
> > Sent: Sunday, March 29, 2009 10:43 PM
> > To: [email-masked]
> > Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> >
> > Hi All,
> >
> > At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> > request by the authors to make this a WG draft. Please indicate to
> the
> > list if you do or don't support making this draft a WG document.
The
> > following is a URL for this draft:
> > http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
> >
> > The deadline for comments will be 3 weeks: Friday, April 17.
Silence
> > will not be counted as acceptance.
> >
> > -shane

From [email-masked]  Tue Mar 31 12:45:28 2009
Content-class: urn:content-classes:message
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
Date: Tue, 31 Mar 2009 14:46:14 -0500
From: "BALUS Florin" <[email-masked]>
To: "David Allan" <[email-masked]>, <[email-masked]>

Dave,
I am ok to add 802.1aq reference to section 6 in the next revision.
Florin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of David Allan
> Sent: Tuesday, March 31, 2009 11:53 AM
> To: [email-masked]
> Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
>=20
> I agree with the single PW mesh for B-component aspect (vs. many
> I-component meshes) and the mention of IEEE protocol snooping for
> multicast containment...but I'd like to see 802.1aq also mentioned in
> section 6 as a means of controlling filtering of multicast...
>=20
> Cheers
> Dave
>=20
>=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
>=20
> > Of Shane Amante
> > Sent: Sunday, March 29, 2009 10:43 PM
> > To: [email-masked]
> > Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> >
> > Hi All,
> >
> > At the L2VPN WG meeting at IETF 74 in San Francisco, there was a
> > request by the authors to make this a WG draft. Please indicate to
> the
>=20
> > list if you do or don't support making this draft a WG document.
The
> > following is a URL for this draft:
> > http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
> >
> > The deadline for comments will be 3 weeks: Friday, April 17.
Silence
> > will not be counted as acceptance.
> >
> > -shane

From [email-masked]  Tue Mar 31 14:21:21 2009
Content-class: urn:content-classes:message
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
Date: Tue, 31 Mar 2009 14:22:16 -0700
From: "Shafir, Alexander" <[email-masked]>
To: "Shane Amante" <[email-masked]>, <[email-masked]>

Hello Ali,

In my further review of the draft the following question came up:
In paragraphs 4.1 and 4.2 the assumption is made that CE is directly
connected to PBBN via C-Tagged interface. I might be mistaken, but is
there C-Tagged interface defined for PBBN in 802.1ah?=20

Sincerely,
  Alex.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Shane Amante
Sent: Sunday, March 29, 2009 7:50 PM
To: [email-masked]
Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?

Hi All,

At the L2VPN WG meeting at IETF 74 in San Francisco, there was a =20
request by the authors to make this a WG draft. Please indicate to the =20
list if you do or don't support making this draft a WG document.  The =20
following is a URL for this
draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-interop-04

The deadline for comments will be 3 weeks: Friday, April 17.  Silence =20
will not be counted as acceptance.

Finally, please note that there is IPR filed against a previous =20
version of this draft (-03).  Please follow the procedures outlined in =20
RFC 3979 and consult your own legal counsel in your decision-making =20
process.

-shane
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From [email-masked]  Tue Mar 31 19:18:36 2009
Date: Wed, 01 Apr 2009 11:14:33 +0900
From: "Yuji KAMITE" <[email-masked]>
Subject: RE: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
To: [email-masked]

Suport.

-Yuji

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Monday, March 30, 2009 11:43 AM
> To: [email-masked]
> Subject: draft-balus-sajassi-l2vpn-pbb-vpls-01 WG draft?
> 
> Hi All,
> 
> At the L2VPN WG meeting at IETF 74 in San Francisco, there 
> was a request by the authors to make this a WG draft. Please 
> indicate to the list if you do or don't support making this 
> draft a WG document.  The following is a URL for this draft:
> http://tools.ietf.org/html/draft-balus-sajassi-l2vpn-pbb-vpls-01
> 
> The deadline for comments will be 3 weeks: Friday, April 17.  
> Silence will not be counted as acceptance.
> 
> -shane

From [email-masked]  Tue Mar 31 19:18:43 2009
Date: Wed, 01 Apr 2009 11:14:33 +0900
From: "Yuji KAMITE" <[email-masked]>
Subject: RE: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
To: [email-masked]

Support

-Yuji

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Shane Amante
> Sent: Monday, March 30, 2009 11:50 AM
> To: [email-masked]
> Subject: draft-sajassi-l2vpn-vpls-pbb-interop-04 WG draft?
> 
> Hi All,
> 
> At the L2VPN WG meeting at IETF 74 in San Francisco, there 
> was a request by the authors to make this a WG draft. Please 
> indicate to the list if you do or don't support making this 
> draft a WG document.  The following is a URL for this 
> draft:http://tools.ietf.org/html/draft-sajassi-l2vpn-vpls-pbb-
> interop-04
> 
> The deadline for comments will be 3 weeks: Friday, April 17.  
> Silence will not be counted as acceptance.
> 
> Finally, please note that there is IPR filed against a 
> previous version of this draft (-03).  Please follow the 
> procedures outlined in RFC 3979 and consult your own legal 
> counsel in your decision-making process.
> 
> -shane