Subject: RE: Further Requirements Proposed for E-Tree

From: Raymond Key <[email-masked]>
Date: Tue, 27 Sep 2011 09:24:22 +1030

Hi L2VPN working group,
 
I have a slightly different opinion.  I don't think we need to add more text about service frame description in this requirement document.
 
My understanding is that in MEF specifications the service frame description is applicable to all MEF defined service types, not particular for E-Tree.  Many operators has been using VPLS to provide E-LAN services, and able to support the service frame description in the MEF specificaitons.  Now what we need to add is only the Leaf-to-Leaf restriction.  It would be good to focus on this only difference between E-LAN and E-Tree, keep the requirement document simple (actully the draft has already included pointers to the MEF specifications).  Besides, it seems to me this have no impact on various solution approaches currently proposed.

Best regards,
Raymond Key 

> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> CC: [email-masked]
> Date: Wed, 3 Aug 2011 16:49:34 +0200
> Subject: RE: Further Requirements Proposed for E-Tree
> 
> Hi,
> 
> As this work is for the support of a service defined by the MEF, I would prefer to keep alignment with MEF service specs as much as possible.
> 
> I believe the additions re service transparency proposed by Yuanlong, as written below, would sufficiently cover it and I support them as is.
> 
> Please see one more comment inline below.
> 
> Thanks,
> Manuel
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Jiangyuanlong
> > Sent: Wednesday, August 03, 2011 4:06 AM
> > To: Rogers, Josh; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: Further Requirements Proposed for E-Tree
> >
> > Hi Josh,
> >
> > I also prefer to preserve the service transparency, though the statement
> > seems more restrictive than MEF 10.2 (where the preservation of C-VLAN ID
> > and CoS are configurable parameters rather than mandating).
> > Can more service providers clarify their requirements on the service
> > transparency?
> >
> > Thanks
> > Yuanlong
> >
> > -----Original Message-----
> > From: Rogers, Josh [mailto:[email-masked]]
> > Sent: Tuesday, August 02, 2011 10:30 PM
> > To: Jiangyuanlong; [email-masked]
> > Cc: [email-masked]
> > Subject: Re: Further Requirements Proposed for E-Tree
> >
> > Would it be to restrictive to change #2 to:
> >
> > 2) Solution must maintain E-Tree Service frame transparently, if
> > containing a IEEE 802.1Q Customer VLAN Tag, the solution MUST be able to
> > preserve the VLAN ID in the Customer VLAN Tag, and if not containing a
> > IEEE 802.1Q Customer VLAN Tag, lack of Customer VLAN tag must be preserved
> > as well.
> >
> > I imagine that could be worded slightly better, but the notion of
> > preserving the frame's Customer tag (or lack of) is something I'd like to
> > see captured. I've seen so many implementations called 'ETREE' that
> > disagree with this, however I'd like to hear from others whether this is
> > agreeable or not, and if not, why?
> [MP:] While customer service VLAN preservation is a feature requiring implementation support, isn't the other case rather a (pre-)configuration issue?
> >
> >
> > From: Jiangyuanlong
> > <[email-masked]<mailto:[email-masked]>>
> > Date: Tue, 2 Aug 2011 02:13:41 -0400
> > To: "[email-masked]<mailto:draft-key-
> > [email-masked]>" <draft-key-l2vpn-vpls-etree-
> > [email-masked]<mailto:draft-key-l2vpn-vpls-etree-
> > [email-masked]>>
> > Cc: "[email-masked]<mailto:[email-masked]>"
> > <[email-masked]<mailto:[email-masked]>>
> > Subject: Further Requirements Proposed for E-Tree
> >
> >
> > Hello authors,
> >
> >
> >
> > During the 81th IETF meeting, it seemed there are ambiguities with regard
> > to the supported types of E-Tree service frames
> >
> > in the E-Tree requirements. To align with the MEF standard (i.e., the
> > specifications in Section 6.5.3 and 6.6 of MEF 10.2),
> >
> > I suggest the following E-Tree requirements should be added:
> > 1) E-Tree Service Frame MAY be untagged, priority tagged, or contain an
> > IEEE 802.1Q Customer VLAN Tag.
> > 2) If the E-Tree Service Frame contains an IEEE 802.1Q Customer VLAN Tag,
> > the solution MUST be able to preserve
> >
> > VLAN ID in this Customer VLAN Tag.
> > 3) If the E-Tree Service Frame is priority tagged or contains an IEEE
> > 802.1Q Customer VLAN Tag, the solution MUST
> >
> > be able to preserve the CoS (Class of Service).
> >
> >
> >
> > Best regards
> > Yuanlong
> >
> >
> >
> > ________________________________
> > This E-mail and any of its attachments may contain Time Warner Cable
> > proprietary information, which is privileged, confidential, or subject to
> > copyright belonging to Time Warner Cable. This E-mail is intended solely
> > for the use of the individual or entity to which it is addressed. If you
> > are not the intended recipient of this E-mail, you are hereby notified
> > that any dissemination, distribution, copying, or action taken in relation
> > to the contents of and attachments to this E-mail is strictly prohibited
> > and may be unlawful. If you have received this E-mail in error, please
> > notify the sender immediately and permanently delete the original and any
> > copy of this E-mail and any printout.