Subject: Further Requirements Proposed for E-Tree

From: Jiangyuanlong <[email-masked]>
Date: Tue, 02 Aug 2011 06:13:41 +0000

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

---

From: "Rogers, Josh" <[email-masked]>
Date: Tue, 2 Aug 2011 10:29:55 -0400

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?

From: Jiangyuanlong <[email-masked]<mailto:[email-masked]>>
Date: Tue, 2 Aug 2011 02:13:41 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Further Requirements Proposed for E-Tree

Hello authors,

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.

---

From: Jiangyuanlong <[email-masked]>
Date: Wed, 03 Aug 2011 02:06:11 +0000

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

Hello authors,

Best regards
Yuanlong

---

From: <[email-masked]>
Date: Wed, 3 Aug 2011 16:49:34 +0200

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

> 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).
> 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]>>
> To: "[email-masked]<mailto:draft-key-
> [email-masked]>" <draft-key-l2vpn-vpls-etree-
> [email-masked]<mailto:draft-key-l2vpn-vpls-etree-
> [email-masked]>>
> 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),
>
> 3) If the E-Tree Service Frame is priority tagged or contains an IEEE
> 802.1Q Customer VLAN Tag, the solution MUST
>
> 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.