Subject: I-D:Extension to BGP-VPLS for E-Tree

From: "Sam Cao" <[email-masked]>
Date: Fri, 15 Apr 2011 22:25:09 +0800

Hi L2VPN working group,

I have just updated "Extension to BGP-VPLS for E-Tree"
(http://www.ietf.org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft
proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree
(E-Tree) in Virtual Private LAN Service using BGP for auto-discovery and
signaling [RFC4761], and I believe that these solution concepts can be
applied to both LDP-VPLS and BGP-VPLS, but the implementation may be a
little different.

Grateful if you could review and collaborate on the mailing list, or direct
to the author. Looking forward to your feedback.

Many thanks to Raymond for his comments on initial version. And thank you in
advance for your time,

Regards,

Yuqun(Sam) Cao

---

From: "Rogers, Josh" <[email-masked]>
Date: Fri, 22 Apr 2011 16:32:27 -0400

Sam,

Thanks so much for your work on this draft.  Some points below:

+ 3.2 - Maybe you can rephrase this?  I'm having trouble following it.  3.1 mentions a method that uses a 'tag' for each frame that denotes it is sourced from a leaf, and 3.2 (in contrast) uses a different method.  If I understand correctly, you want the router to be aware of what the endpoints are and decide whether to forward to other PE's/AC's, rather than send it, and decide after it arrives (as in 3.1).  An alternate way of phrasing this that you may consider is:

3. Terminology

  <snip>

   2. The decision to forward a frame to another AC or across a PW is based on foreknowledge of the local AC type and the remote AC type.  If a frame comes from a local Leaf-AC, then it will not forward to any other local Leaf-AC's, and will only forward across PW(s) to a PE which has a Root-AC.  In this way, we restrict the communication between Leafs by building a partial mesh of PW's, intentionally excluding PW's between Leaf-AC's.  Additional PWs will need to be created to/from PE's that contain both Root and Leaf ACs.

   The purposed solution in this document prefers to the second.  Two terms are introduced,

   o Root-endpoint. One endpoint which connects only Root-ACs, one or
      more Root-ACs.

   o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or
      more Leaf-ACs.

   There is no endpoint which connects both Root-ACs and Leaf-ACs in the
   second solution, however a PE may have one of each endpoint configured in the same vpls instance.

+ Is 'endpoint' defined somewhere else?  I can gather (from figure 2) that you mean a pseudowire endpoint, but I'm not sure that is very clear here.

Regarding figure 2, I at first thought there should only be one PW between PE1 and PE3, and there should be two PW's between PE1 (since both AC1 and AC2 can/should talk to both AC5 and AC6)  In fact, I believe with the topology drawn, there should be three PW's total, however PE1 should have two VE-ID's, and PW's terminating to each, rather than one VE-ID's terminating two PW's as the other two PE's, which is what allows unique forwarding decisions based on the source VE-ID type, root or leaf).

After looking through it a second time, I realized that your intention is to terminate PW per 'endpoint' (this goes back to the earlier comment about whether this is already defined somewhere) on each PE, almost segmenting the PE into behaving as though it was two PE's (one for the root AC's and one for the leaf AC's) participating in the instance.  While I believe that the additional PW may be unnecessary in this particular example, I believe your approach of using one 'endpoint' per AC type should scale with any scenario.   It may be a good idea to try and represent the 'endpoints' in figure 2, maybe in place of the VSI box, place two endpoint boxes on PE1, and one box on each of the other PE's?  Put an R in the root endpoints and L in the leaf ones, like this:

                   |<-----------E-Tree------------>|
                   |                               |
                   V                               V
                   +----------+          +---------+
     Root endpoint--   PE1    |          |   PE2   |    /Leaf endpoint
   +---+           |\ +---+   |          |  +---+  |  /\           +---+
   |CE1+-------AC1-+--+ R +---|---PW12---+--+   +--+-|--- --AC3----+CE3|
   +---+  (Root AC)|  +---+-+ |          |  | V |  | |  |(Leaf AC) +---+
                   |        | |          |  | S |  | |  |
   +---+           |  +---+ | |          |  | I |  | |  |          +---+
   |CE2+----AC2----+--+ L | | |          |  |   +--+-|------AC4----+CE4|
   +---+  (Leaf AC)| /++--+ | |          |  +-+-+  |  \/ (Leaf AC) +---+
                   /---|----|-+          +----+----+
     Leaf endpoint +^   |    |                |
                   |   |    |PW13-2          |PW23
                   |   |    |                 |
                 PW13-1|    |           +----+----+    /Root endpoint
                   |   |    |           |  +-+-+  |  /\          +---+
                   |   |    |           |  | V +--+-|--------AC5-+CE5|
                   |   |    +-----------+--+ S |  | |  |(Root AC)+---+
                   |   |                |  | I |  | |  |         +---+
                   |   +----------------+  |   +--+-|------AC6---+CE6|
                   |                    |  +---+  |  \/ (Root AC)+---+
                   |                    |   PE3   |
                   |                    +---------+
                   |                              ^
                   | <-----------E-Tree---------->|

There is a small typo in 5.3, I believe Foex should be For.

Is 5.7 a duplicate of 5.6?

Regarding signaling, under the existing standards (no defined 'endpoints'), we use opposing target communities (one for root sites, and one for leaf sites) successfully today to accomplish ETREE services.  In the topology outlined in figure 2, we'd configure like this:

PE      export          import          Add'l knobs
PE1     target:123:1    target:123:2    (core-facing)
PE2     target:123:2    target:123:1    (No local-switching)
PE3     target:123:1    target:123:2

The two primary problems that we face with this method are:
1) Root to root communication is not possible.  Root-Leaf and Leaf-Root are the only possible combinations.
2) the 'core facing' knob available on the Juniper platform will cause AC2 to communicate with AC1, but NOT communicate with any other AC's, including AC5 and AC6.

Both of these problems break the ETREE requirements draft Raymond worked on earlier, and both are addressed with the draft you are working on now.  I look forward to seeing section 5.7 completed/extended.

To recap, the primary problem we need to solve with this topology is 1) AC3 and AC4 cannot be allowed to communicate (no local switching), and 2) AC2 cannot be allowed to communicate with AC3 and AC4 and vice versa.  I believe what you are trying to convey is that PE1 will forward traffic from AC2 to PE3, but not PE2, and PE2 will forward to PE3 but not PE2, while still allowing AC1 to forward to PE2.

Sam, this is a very good start, and I look forward to seeing it through.  Really appreciate your efforts here, as this is a very relevant draft.  Please let me know if I can help.

-Josh

On Apr 15, 2011, at 9:25 AM, Sam Cao wrote:

> Hi L2VPN working group,
>
> I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf.org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service using BGP for auto-discovery and signaling [RFC4761], and I believe that these solution concepts can be applied to both LDP-VPLS and BGP-VPLS, but the implementation may be a little different.
>
> Grateful if you could review and collaborate on the mailing list, or direct to the author. Looking forward to your feedback.
>
> Many thanks to Raymond for his comments on initial version. And thank you in advance for your time,
>
> Regards,
>
> Yuqun(Sam) Cao

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: Raymond Key <[email-masked]>
Date: Sat, 23 Apr 2011 18:40:38 +1030

A comment on Figure 2 under Section 4. Reference Model (extracted below)
 
                   |<----------E-Tree------------>|
                   |                              |
                   V                              V
                   +---------+          +---------+
                   |   PE1   |          |   PE2   |    /Leaf endpoint
   +---+           |  +---+  |          |  +---+  |  /\           +---+
   |CE1+-------AC1-+--+ V |  |          |  | V +--+-|--- --AC3----+CE3|
   +---+  (Root AC)|  | S +--+---PW12---+--+ S |  | |  |(Leaf AC) +---+
   +---+           |  | I |  |          |  | I |  | |  |          +---+
   |CE2+----AC2----+--+   |  |          |  |   +--+-|------AC4----+CE4|
   +---+  (Leaf AC)|  +-+-+  |          |  +-+-+  |  \/ (Leaf AC) +---+
                   +---+-+---+          +----+----+
                   ^   | |                   |
                   |   | |PW13-2             |PW23
                   |   | |                   |
                 PW13-1| |              +----+----+    /Root endpoint
                   |   | |              |  +-+-+  |  /\          +---+
                   |   | |              |  | v +--+-|--------AC5-+CE5|
                   |   | +--------------+--+ s |  | |  |(Root AC)+---+
                   |   |                |  | I |  | |  |         +---+
                   |   +----------------+  |   +--+-|------AC6---+CE6|
                   |                    |  +---+  |  \/ (Root AC)+---+
                   |                    |   PE3   |
                   |                    +---------+
                   |                              ^
                   | <-----------E-Tree---------->|

As PE3 has Root ACs only, communication between an AC on PE1 and an AC on PE3 is always allowed.  This scenario seems not really need extension to current VPLS.
 
IMO it may be better if you add a Leaf AC (called it AC7) on PE3 and explain how your proposed solution prohibits communication between AC2 (Leaf AC on PE1) and AC7 (Leaf AC on PE3). 
 
Regards,
Raymond Key 

> From: [email-masked]
> To: [email-masked]
> Date: Fri, 22 Apr 2011 16:32:27 -0400
> Subject: Re: I-D:Extension to BGP-VPLS for E-Tree
> CC: [email-masked]; [email-masked]; [email-masked]
> 
> Sam,
>

---

From: "Rogers, Josh" <[email-masked]>
Date: Sat, 23 Apr 2011 11:04:50 -0400

Yes, I agree.

A leaf and root PE to another leaf and root PE would have cleared this up for me as well.  Either include a 7th AC as Ray recommended, or add a fourth PE configured just like PE1.

Also, regarding the target communities...  I've often thought that if I had the ability to import more than one community, it would address the current inability to have root-root communication that I experience today.  It would not, however, address a root/leaf to root/leaf communication.

-Josh

On Apr 23, 2011, at 3:10 AM, Raymond Key wrote:

Regards,
Raymond Key

> From: [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> CC: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
>
> Sam,
>

---

From: "Sam Cao" <[email-masked]>
Date: Sun, 24 Apr 2011 07:21:49 +0800

Hi Josh,

Thank you very much for your comments. Yes, we can import/export route
targets, one for Root endpoint and one for Leaf endpoint (Refer to RFC 4761
and 6074), but for communication between 2 root-leaf-mixed PEs, maybe we
need some changes, so maybe it is not good solution. That is why are working
on new E-Tree drafts. Luca shared his expert opinion with me through Email
before.

Thank you very much for your time and your help. I will review your points
case by case, and then update the draft.

Sam

-----邮件原件-----
发件人: Rogers, Josh [mailto:[email-masked]] 
发送时间: 2011年4月23日 23:05
收件人: Raymond Key
抄送: [email-masked]; [email-masked]; [email-masked];
[email-masked]
主题: Re: I-D:Extension to BGP-VPLS for E-Tree

Yes, I agree.

A leaf and root PE to another leaf and root PE would have cleared this up
for me as well.  Either include a 7th AC as Ray recommended, or add a fourth
PE configured just like PE1.

Also, regarding the target communities...  I've often thought that if I had
the ability to import more than one community, it would address the current
inability to have root-root communication that I experience today.  It would
not, however, address a root/leaf to root/leaf communication.

-Josh

As PE3 has Root ACs only, communication between an AC on PE1 and an AC on
PE3 is always allowed.  This scenario seems not really need extension to
current VPLS.

IMO it may be better if you add a Leaf AC (called it AC7) on PE3 and explain
how your proposed solution prohibits communication between AC2 (Leaf AC on
PE1) and AC7 (Leaf AC on PE3).

Regards,
Raymond Key

> CC: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]>
> + 3.2 - Maybe you can rephrase this? I'm having trouble following it. 3.1
mentions a method that uses a 'tag' for each frame that denotes it is
sourced from a leaf, and 3.2 (in contrast) uses a different method. If I
understand correctly, you want the router to be aware of what the endpoints
are and decide whether to forward to other PE's/AC's, rather than send it,
and decide after it arrives (as in 3.1). An alternate way of phrasing this
that you may consider is:
>
>
> 3. Terminology
>
> <snip>
>
> 2. The decision to forward a frame to another AC or across a PW is based
on foreknowledge of the local AC type and the remote AC type. If a frame
comes from a local Leaf-AC, then it will not forward to any other local
Leaf-AC's, and will only forward across PW(s) to a PE which has a Root-AC.
In this way, we restrict the communication between Leafs by building a
partial mesh of PW's, intentionally excluding PW's between Leaf-AC's.
Additional PWs will need to be created to/from PE's that contain both Root
and Leaf ACs.
> + Is 'endpoint' defined somewhere else? I can gather (from figure 2) that
you mean a pseudowire endpoint, but I'm not sure that is very clear here.
>
> Regarding figure 2, I at first thought there should only be one PW between
PE1 and PE3, and there should be two PW's between PE1 (since both AC1 and
AC2 can/should talk to both AC5 and AC6) In fact, I believe with the
topology drawn, there should be three PW's total, however PE1 should have
two VE-ID's, and PW's terminating to each, rather than one VE-ID's
terminating two PW's as the other two PE's, which is what allows unique
forwarding decisions based on the source VE-ID type, root or leaf).
>
> After looking through it a second time, I realized that your intention is
to terminate PW per 'endpoint' (this goes back to the earlier comment about
whether this is already defined somewhere) on each PE, almost segmenting the
PE into behaving as though it was two PE's (one for the root AC's and one
for the leaf AC's) participating in the instance. While I believe that the
additional PW may be unnecessary in this particular example, I believe your
approach of using one 'endpoint' per AC type should scale with any scenario.
It may be a good idea to try and represent the 'endpoints' in figure 2,
maybe in place of the VSI box, place two endpoint boxes on PE1, and one box
on each of the other PE's? Put an R in the root endpoints and L in the leaf
ones, like this:
> Regarding signaling, under the existing standards (no defined
'endpoints'), we use opposing target communities (one for root sites, and
one for leaf sites) successfully today to accomplish ETREE services. In the
topology outlined in figure 2, we'd configure like this:
> 2) the 'core facing' knob available on the Juniper platform will cause AC2
to communicate with AC1, but NOT communicate with any other AC's, including
AC5 and AC6.
>
> Both of these problems break the ETREE requirements draft Raymond worked
on earlier, and both are addressed with the draft you are working on now. I
look forward to seeing section 5.7 completed/extended.
>
>
> To recap, the primary problem we need to solve with this topology is 1)
AC3 and AC4 cannot be allowed to communicate (no local switching), and 2)
AC2 cannot be allowed to communicate with AC3 and AC4 and vice versa. I
believe what you are trying to convey is that PE1 will forward traffic from
AC2 to PE3, but not PE2, and PE2 will forward to PE3 but not PE2, while
still allowing AC1 to forward to PE2.
>
> Sam, this is a very good start, and I look forward to seeing it through.
Really appreciate your efforts here, as this is a very relevant draft.
Please let me know if I can help.
> > I have just updated "Extension to BGP-VPLS for E-Tree" (http://www.ietf.
org/id/draft-cao-l2vpn-bgp-vpls-etree-01.txt). This draft proposes an
approach to support Metro Ethernet Forum (MEF) Ethernet Tree (E-Tree) in
Virtual Private LAN Service using BGP for auto-discovery and signaling
[RFC4761], and I believe that these solution concepts can be applied to both
LDP-VPLS and BGP-VPLS, but the implementation may be a little different.
> >
> > Grateful if you could review and collaborate on the mailing list, or
direct to the author. Looking forward to your feedback.
> 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: "Sam Cao" <[email-masked]>
Date: Tue, 26 Apr 2011 10:43:05 +0800

Josh,

Thank you very much for your comments, and I gave the answer to your questions below. 
I will check-in new version ASAP.

> +A leaf and root PE to another leaf and root PE would have cleared this up for me as well.  
Either include a 7th AC as Ray recommended, or add a fourth PE configured just like PE1.
[Sam] Yes, I add one AC7, and refer to attachment for figure.

> + 3.2 - Maybe you can rephrase this? I'm having trouble following it. 3.1 mentions a method 
that uses a 'tag' for each frame that denotes it is sourced from a leaf, and 3.2 (in contrast) uses a 
different method. If I understand correctly, you want the router to be aware of what the endpoints 
are and decide whether to forward to other PE's/AC's, rather than send it, and decide after it arrives 
(as in 3.1). An alternate way of phrasing this that you may consider is:
[Sam] Yes, I try to make it clear. Comply with RFC 4761, VPLS edge ID should be assigned by 
administrator, and PE in VPLS also calculate label with VE ID, block size, Label base, offset. So
 if we seperate Leaf ACs from Root ACs with VE ID, then we can break communication between Leafs. 
This follows Appendix A in http://tools.ietf.org/html/draft-key-l2vpn-etree-frwk-04#appendix-A
A.8.  I have extended RFC 4761 in new version, and I will check-in ASAP. This can be used for 
LDP-VPLS, but I need to clear it first.

> + Is 'endpoint' defined somewhere else? I can gather (from figure 2) that you mean a pseudowire endpoint, 
but I'm not sure that is very clear here.
[Sam] Endpoint is defined in RFC 4761,and I try to use this to seperate Leaf from Root. In one word, Every 
endpoint should be designated one ID (VE ID in RFC 4761), and it has one or more ACs. Just as mentioned in 
my draft, one endpoint only has Leafs or Roots, but can not have Roots and Leafs. This is key point in my draft.

> + Is 5.7 a duplicate of 5.6?
[Sam] No, there are different, one is for Leaf endpoint, and one is Root endpoint. Now I upgrate it and like below,
5.6.2. Leaf endpoint

   1. Checks if w is Leaf endpoint with "Layer2 Info Extended Community".
      If it is, PE-b ignores this message since remote endpoint is Leaf,
      and skips the rest of this procedure.

  Cao                 Expires October 26, 2011               [Page 11]

Internet-Draft    Extension to BGP-VPLS for E-Tree          April 2011

   2. Checks if w is part of PE-a's 'remote VE set': if VBO <= w < VBO+
      VBS, then w is part of PE-a's remote Root VE set.  If not, PE-b
      ignores this message, and skips the rest of this procedure.

        4. Sets up a PW to PE-a: the demultiplexor label to send traffic
           from PE-b to PE-a is computed as (lLB + w - VBO).

        5. Checks if l is part of any 'remote VE set' that PE-b
           announced, i.e., PE-b checks if l belongs to some remote VE
           set that PE-b announced, say with VE Block Offset VBO', VE
           Block Size VBS', and label base LB'. If not, PE-b MUST make a
           new announcement as described.

        6. Sets up a PW from PE-a: the demultiplexor label over which
           PE-b should expect traffic from PE-a is computed as: (LB' + l
           - VBO').

   If PE-a withdraws an NLRI for l that PE-b was using, then PE-b MUST
   tear down its ends of the pseudowire between PE-a and PE-b.

> PE3 target:123:1 target:123:2
[Sam] Yes, we can use Route Target in most cases, but for Root-Leaf-Mixed cases (In Figure1), 
it can not figure out Root and Leaf easily. I have discussed this with Raymond and Luca through E-mail.

Again, Josh, thank you very much for your time. 

Sam

----- Original Message ----- 
From: "Rogers, Josh" <[email-masked]>
To: "Raymond Key" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, April 23, 2011 11:04 PM
Subject: Re: I-D:Extension to BGP-VPLS for E-Tree

Yes, I agree.

-Josh

Regards,
Raymond Key