Subject: MEF E-Tree over MPLS/VPLS

From: Raymond Key <[email-masked]>
Date: Thu, 03 Dec 2009 12:59:59 +1100

Thanks a lot for the comments. I would like to share my view with the workgroups.

(1) "it uses the CW to signal topology information."

The information in the proposed Control Word L-bit is "whether the Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or not". I consider this as per-payload information, rather than topology information.

(2) "E-tree construct was always envisioned to be used in conjunction with VPLS BGP autodiscovery."

Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, static provisioning. Service providers and vendors have the freedom to use any technologies (existing or develop new) to implement E-Tree services.

(3) "There are a couple of corner problems, like when there are leafs co-located with Roots in the same PE. These I believe can be solved by using multiple VFIs in that particular PE."

The problem re Leaf-to-Leaf communication restriction that leads to the proposed Control Word L-bit is "Two or more PEs in one E-Tree construct with both Root AC and Leaf AC", as specified in section 5.2.1 in the Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft-key-l2vpn-etree-frwk-00.txt).

There are possible ways to get around this problem without any extension to current VPLS and PWE3 standards. The main ones I know are H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE. Unfortunately, they all come with significant design complexity and/or deployment constraints. That is the reason why we explore whether a minimal extension to the current standards could bring a simple and effective solution.

(4) "The reference the P2MP PW, I do not understand." 

The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448] by using bit 4 (one of the reserved bits specified in [RFC4448]) for the ingress PE to signal per payload to the egress PE whether the frame is from a Leaf AC on the ingress PE or not. If future development of VPLS uses P2MP PW for unicast unknown/broadcast/multicast frame, provided that [RFC4448] is used on the P2MP PW, the extension proposed in this I-D should be applicable. 

(5) "Ideally we should try to find though a flag/tag in the Ethernet header that works for all use cases instead of just VPLS. ... ... But this is a discussion to have first in IEEE rather than IETF."

I believe there are considerable number of service providers currently implementing MEF E-LAN services on "just VPLS". The proposed Control Word L-bit approach is a straight forward solution for VPLS. It is good to explore the approach of using the Ethernet header but I would like to see things progressing in different angles rather than "first in IEEE rather than IETF".

Thanks,
Raymond Key

---

From: Yong Lucy <[email-masked]>
Date: Wed, 02 Dec 2009 22:46:17 -0600

Raymond has given great answers for all the questions. Thanks Raymond.

PW label and CW is for service encapsulation. CW is for per-packet
encapsulation. L-bit in CW indicates whether the packet is from root or leaf
that is the service attribute, it is not topology information. This
indication enables egress PE to perform forwarding properly.

Thanks,
Lucy
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Raymond Key
> Sent: Wednesday, December 02, 2009 8:00 PM
> To: [email-masked]; [email-masked]
> Subject: [PWE3] MEF E-Tree over MPLS/VPLS
> 
> The information in the proposed Control Word L-bit is "whether the
> Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or
> not". I consider this as per-payload information, rather than topology
> information.
> 
> Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service
> definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery,
> static provisioning. Service providers and vendors have the freedom to use
> any technologies (existing or develop new) to implement E-Tree services.
> 
> (3) "There are a couple of corner problems, like when there are leafs co-
> located with Roots in the same PE. These I believe can be solved by using
> multiple VFIs in that particular PE."
> 
> The problem re Leaf-to-Leaf communication restriction that leads to the
> proposed Control Word L-bit is "Two or more PEs in one E-Tree construct
> with both Root AC and Leaf AC", as specified in section 5.2.1 in the
> Internet-Draft - A Framework for E-Tree Service over MPLS Network (draft-
> key-l2vpn-etree-frwk-00.txt).
> 
> There are possible ways to get around this problem without any extension
> to current VPLS and PWE3 standards. The main ones I know are H-VPLS,
> separate VSIs for Root and Leaf, separate PWs for "From Leaf" traffic and
> "From Root" traffic, separate PEs for Root and Leaf, all Roots on same PE.
> Unfortunately, they all come with significant design complexity and/or
> deployment constraints. That is the reason why we explore whether a
> minimal extension to the current standards could bring a simple and
> effective solution.
> 
> The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation
> [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448]
> by using bit 4 (one of the reserved bits specified in [RFC4448]) for the
> ingress PE to signal per payload to the egress PE whether the frame is
> from a Leaf AC on the ingress PE or not. If future development of VPLS
> uses P2MP PW for unicast unknown/broadcast/multicast frame, provided that
> [RFC4448] is used on the P2MP PW, the extension proposed in this I-D
> should be applicable.
> 
> (5) "Ideally we should try to find though a flag/tag in the Ethernet
> header that works for all use cases instead of just VPLS. ... ... But this
> is a discussion to have first in IEEE rather than IETF."
> 
> I believe there are considerable number of service providers currently
> implementing MEF E-LAN services on "just VPLS". The proposed Control Word
> L-bit approach is a straight forward solution for VPLS. It is good to
> explore the approach of using the Ethernet header but I would like to see
> things progressing in different angles rather than "first in IEEE rather
> than IETF".
> 
> Thanks,
> Raymond Key
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Thu, 03 Dec 2009 09:24:14 -0700

> The information in the proposed Control Word L-bit is "whether the Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE or not". I consider this as per-payload information, rather…
No. this is routing , or topology information in the same way as  source 
IP address is.
This does not belong in the CW.
Why are you not using the MPLS label ? You can simply bind this 
information to a label.

> Metro Ethernet Forum (MEF) defined the Ethernet Tree (E-Tree) service definition with no reference to MPLS, VPLS, BGP, LDP, auto-discovery, static provisioning. Service providers and vendors have t…
ok. so BGP VPLS autodiscovery is a very good fit .

> There are possible ways to get around this problem without any extension to current VPLS and PWE3 standards. The main ones I know are H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From…
Splitting the VSI on the PE for ROOT/LEAF is very simple. In fact this 
is a common practice today in networks using BGP to signal Labels.

> The current VPLS standards use only P2P PW and PWE3 Ethernet Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension to [RFC4448] by using bit 4 (one of the reserved bits specifie…
ok, but that path has been already explored 10 years ago. It has all the 
problems of ATM LANE..., SO I doubt we'll look at it again.
> (5) "Ideally we should try to find though a flag/tag in the Ethernet header that works for all use cases instead of just VPLS. ... ... But this is a discussion to have first in IEEE rather than IET…
Or we can simply bing the E-tree bit to the label ....
> I believe there are considerable number of service providers currently implementing MEF E-LAN services on "just VPLS". The proposed Control Word L-bit approach is a straight forward solution for VP…
I think that give that the forwarding in the IETF is not based on the 
Ethernet MAC, but rather on a label .... it should be easy to add this 
topology constraint to the information that is bound to the MPLS label 
in the control plane.

Luca

---

From: "BALUS Florin" <[email-masked]>
Date: Thu, 3 Dec 2009 10:53:03 -0600

On your answer for (5)
> header that works for all use cases instead of just VPLS. ... ... But
> this is a discussion to have first in IEEE rather than IETF."
> 
> implementing MEF E-LAN services on "just VPLS". The proposed Control
> Word L-bit approach is a straight forward solution for VPLS. It is
good
> to explore the approach of using the Ethernet header but I would like
> to see things progressing in different angles rather than "first in
> IEEE rather than IETF".

Maybe I should have stated differently: we should ask IEEE for an
opinion on this and take their feedback into consideration. A good venue
for that might be the interim IEEE 802.1 meeting in January 2010. Then
we can pick up the discussion in IETF in the spring. I think it is
worthwhile to try to come up with one solution for all use cases instead
of multiple ones. 

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Raymond Key
> Sent: Wednesday, December 02, 2009 6:00 PM
> Subject: MEF E-Tree over MPLS/VPLS
> 
> Ethernet frame encapsulated is coming from a Leaf AC on the ingress PE
> or not". I consider this as per-payload information, rather than
> topology information.
> 
> static provisioning. Service providers and vendors have the freedom to
> use any technologies (existing or develop new) to implement E-Tree
> services.
> 
> (3) "There are a couple of corner problems, like when there are leafs
> co-located with Roots in the same PE. These I believe can be solved by
> using multiple VFIs in that particular PE."
> 
> Internet-Draft - A Framework for E-Tree Service over MPLS Network
> (draft-key-l2vpn-etree-frwk-00.txt).
> 
> There are possible ways to get around this problem without any
> extension to current VPLS and PWE3 standards. The main ones I know are
> H-VPLS, separate VSIs for Root and Leaf, separate PWs for "From Leaf"
> traffic and "From Root" traffic, separate PEs for Root and Leaf, all
> Roots on same PE. Unfortunately, they all come with significant design
> complexity and/or deployment constraints. That is the reason why we
> explore whether a minimal extension to the current standards could
> bring a simple and effective solution.
> 
> The current VPLS standards use only P2P PW and PWE3 Ethernet
> Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an
> extension to [RFC4448] by using bit 4 (one of the reserved bits
> specified in [RFC4448]) for the ingress PE to signal per payload to
the
> egress PE whether the frame is from a Leaf AC on the ingress PE or
not.
> If future development of VPLS uses P2MP PW for unicast
> unknown/broadcast/multicast frame, provided that [RFC4448] is used on
> the P2MP PW, the extension proposed in this I-D should be applicable.
> 
> header that works for all use cases instead of just VPLS. ... ... But
> this is a discussion to have first in IEEE rather than IETF."
> 
> implementing MEF E-LAN services on "just VPLS". The proposed Control
> Word L-bit approach is a straight forward solution for VPLS. It is
good
> to explore the approach of using the Ethernet header but I would like
> to see things progressing in different angles rather than "first in
> IEEE rather than IETF".
> 
> Thanks,
> Raymond Key

---

From: Yong Lucy <[email-masked]>
Date: Thu, 03 Dec 2009 11:00:17 -0600

Hi Luca,

> Why are you not using the MPLS label ? You can simply bind this

Root and leaf represent AC attribute parameters only. One E-tree service can
have multiple root ACs and many leaf ACs, it is not like IP address to
associate with one certain entity. The attribute gives some forwarding
restriction and does not contribute for routing at all. So it is not
topology information. 

> is a common practice today in networks using BGP to signal Labels.
This solution requires building more PWs and interworking between two VSIs
on a PE. Our proposal seems more simple that this extension.

> topology constraint to the information that is bound to the MPLS label

Disagree on that is a topology constraint. In addition, this leads to "MUST"
separating roof PW label and leaf PW label, which requires the more complex
extension than this.

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Luca Martini
> Sent: Thursday, December 03, 2009 10:24 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: MEF E-Tree over MPLS/VPLS
> 
> Raymond Key wrote:
> Encapsulation [RFC4448]. The Control Word L-bit I-D proposes an extension
> to [RFC4448] by using bit 4 (one of the reserved bits specified in
> [RFC4448]) for the ingress PE to signal per payload to the egress PE
> whether the frame is from a Leaf AC on the ingress PE or not. If future
> development of VPLS uses P2MP PW for unicast unknown/broadcast/multicast
> frame, provided that [RFC4448] is used on the P2MP PW, the extension
> proposed in this I-D should be applicable.
> >
> >