Subject: WG Last Call: draft-ietf-l2vpn-vpls-mcast-reqts-03

From: Shane Amante <[email-masked]>
Date: Sun, 14 Jan 2007 21:44:52 -0700

Hi Folks,

This is the start of a WG Last Call for:
http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-reqts-03

Please e-mail the list with any comments, concerns or corrections, in  
addition to whether or not you support forwarding this I-D on to the  
IESG.  Last Call on this draft will end in two weeks, on Friday,  
January 26, 2007, at 17:00 MST (UTC -7).

Thanks!

-shane & Vach

---

From: "William Zayas" <[email-masked]>
Date: Mon, 15 Jan 2007 11:47:46 -0400

Shane,

On the Intruduction part of the Definition of VPLS goes as follow: VPLS
(Virtual Private LAN Service) is a provider service that

   emulates the full functionality of a traditional Local Area Network

   (LAN).  VPLS interconnects several customer LAN segments over a

   packet switched network (PSN) backbone, creating a multipoint-to-

   multipoint Ethernet VPN.  For customers, their remote LAN segments

   behave as one single LAN.

My concern is the term emulates on a PSN Backbone. What about of all new
IP-MPLS backbones?

Regards,

William Zayas

Fiber Crossing Corp.

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 12:45 AM
To: [email-masked]
Subject: WG Last Call: draft-ietf-l2vpn-vpls-mcast-reqts-03

Hi Folks,

Thanks!

-shane & Vach

---

From: "HEMIGE Venu" <[email-masked]>
Date: Fri, 26 Jan 2007 17:41:46 -0600

Hi Shane,

I just have a couple of minor comments. Otherwise, I think it is a very
well written draft.

In section 5.1.1, it says that a layer 2 frame (whether data or control)
SHOULD NOT be altered for transparency. If the frame happens to be a L3
control frame (IGMP/PIM), then it may be completely consumed by a switch
and an entirely new packet generated by the switch. So the switch may be
injecting frames with its own mac as source address for the packets it
generates. It would be better to clarify that this is allowed.

Section 5.9: It says a solution SHOULD prevent frame reordering.
Delivery of out-of-order frames is not avoidable in certain cases (when
switching from one aggregate tree to another). The draft also talks
about use of trees as one of the options to optimize data delivery in
the core.

Section 6.5.1: It appears that multicast service activation at a MAC
address granularity is preferred over activation at a customer multicast
IP address granularity. Is that what was intended? Clearly, activation
at MAC address granularity is not very optimal.

Regards,
-Venu

> Sent: Sunday, January 14, 2007 8:45 PM
> To: [email-masked]