RE: L2vpn Digest, Vol 100, Issue 15

["Sam Cao" <[e-mail]>]

+1.

Sam

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Tuesday, September 25, 2012 3:00 AM
To: [e-mail]
Subject: L2vpn Digest, Vol 100, Issue 15

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/l2vpn

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.



Send L2vpn mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of L2vpn digest..."


Today's Topics:

   1. RE: FW: New Version Notification for
      draft-jiang-l2vpn-evpn-etree-2vlan-00.txt (UTTARO, JAMES)


----------------------------------------------------------------------

Message: 1
Date: Mon, 24 Sep 2012 14:32:07 +0000
From: "UTTARO, JAMES" <[e-mail]>
To: "'Aldrin Isaac'" <[e-mail]>, Jiangyuanlong
	<[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Ali Sajassi
	<[e-mail]>,	Himanshu Shah <[e-mail]>
Subject: RE: FW: New Version Notification for
	draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Message-ID:
	
<[e-mail]>
	
Content-Type: text/plain; charset="us-ascii"

+1

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Aldrin Isaac
Sent: Monday, September 24, 2012 12:28 AM
To: Jiangyuanlong
Cc: [e-mail]; Ali Sajassi; Himanshu Shah
Subject: Re: FW: New Version Notification for
draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Hi Yuanlong,

I'm not clear as to why different forwarding contexts for root and leaf is
less than good -- can you elaborate?  Also I'm not clear as to why you see
that ETREE using EVPN is any different from other topologies that can be
created with EVPN.  EVPN's ability to create any topology is fundamental to
it.  In IPVPN we commonly create hub-and-spoke VPN with hubs and spokes in
different VRF. In some cases we even overlap one or more hub-and-spoke RT
pairs with one or more mesh RT.  EVPN was purposefully designed to bring
this flexibility to Ethernet.

Best regards -- aldrin


On Sunday, September 23, 2012, Jiangyuanlong wrote:
Hi Aldrin,

I agree with you that using different labels for root/leaf AC can work, but
not sure using 2 forwarding contexts (EVI) is a good thing - that means
forwarding plane for E-Tree will be very different from other services in
E-VPN.

Regards,
Yuanlong

From: Aldrin Isaac
[mailto:[e-mail]<javascript:_e(%7b%7d,%20'cvml',%20'aldrin.isa
[e-mail]');>]
Sent: Sunday, September 23, 2012 9:21 PM
To: Alexander Vainshtein
Cc: Jiangyuanlong; Giles Heron; Himanshu Shah; Ali Sajassi;
[e-mail]<javascript:_e(%7b%7d,%20'cvml',%20'[e-mail]');>
Subject: Re: FW: New Version Notification for
draft-jiang-l2vpn-evpn-etree-2vlan-00.txt



With EVPN, leaf AC should have different context and associated label from
root AC.  A leaf AC forwarding context (say EVI) on an ingress PE would not
import the RT for other leaf AC and hence not have forwarding vectors to any
leaf AC.  The packet would have nowhere to go and hence be dropped on
ingress.  In the case of BUM ingress replication, the leaf AC forwarding
context on the ingress PE would not have imported the Inclusive Tag route of
egress leaf AC and hence have no vectors to local replication context IDs of
other leaf AC .  In the case of BUM tree, the leaf EVI would not have
imported the Inclusive Tag route of other leaf EVI and hence not form a tree
to other leaf EVI.




On Sunday, September 23, 2012, Alexander Vainshtein wrote:

Yuanlong, Giles, Himanshu, Ali and all,

I have probably missed something important (not being present at the latest
IETF meeting).

But I think something is wrong with the statement "there was no benefit in
the E-VPN case in using an additional tag (such as a VLAN)".



IMHO and FWIW the real E-Tree problem is the situation when there are two
(or more) PEs with both Root and Leaf ACs.

When one of such PEs receives a VPLS packet from another such PE, it must
somehow identify the source AC of the Ethernet frame in this packet, and, in
the case of it being a leaf AC, prevent its forwarding to the local Leaf
AC(s) while allowing forwarding to local Root AC(s). This equally applies to
regular VPLS and E-VPN, e.g., in the case when the contained Ethernet frame
is a broadcast one (so that no learning is associated with it). And I
strongly doubt this can be achieved without some "tags" in the
encapsulation.



My 2c,

     Sasha



> -----Original Message-----

> From: [e-mail]<mailto:[e-mail]> 
> [mailto:[e-mail]] On Behalf

> Of Jiangyuanlong

> Sent: Saturday, September 22, 2012 5:32 AM

> To: Giles Heron

> Cc: [e-mail]<mailto:[e-mail]>

> Subject: RE: New Version Notification for 
> draft-jiang-l2vpn-evpn-etree-2vlan-

> 00.txt

>

> Hi Giles,

>

> Perhaps the gauge of the consensus in the minutes was not so clear for me:

> "         Giles - are we agreed we want to get to one solution for VPLS
and E-

> VPN.

>           Not many people.  But even fewer who want multiple.  Checked 
> to see

> if

>           people want one solution only for E-VPN and VPLS - only a 
> couple of

> hands."

> Nevertheless, E-VPN needs an E-Tree solution and it is the WG 
> consensus to

> decide which way to take.

>

> Thanks,

> Yuanlong

>

> -----Original Message-----

> From: Giles Heron [mailto:[e-mail]]

> Sent: Friday, September 21, 2012 9:09 PM

> To: Jiangyuanlong

> Cc: [e-mail]<mailto:[e-mail]>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/l2vpn/attachments/20120924/329cfcac/at
tachment.htm>

------------------------------

_______________________________________________
L2vpn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/l2vpn


End of L2vpn Digest, Vol 100, Issue 15
**************************************