Hi Kireeti,
This mean that IP packet will always undergo routing even if someone just
want L2 based service. The L2 and L3 service in nvo-dataplane-requirement draft
gives both option of forwarding. Even a IP packet can be forwarded by using L2
header information. But your proposal of making "All IP packet route" takes
away the flexibility of L2 forwarding IP packets .
Regards,
Vivek
-----Original Message-----
From: Kireeti Kompella [mailto:[email protected]]
Sent: Friday, December 28, 2012 8:40 AM
To: Vivek Kumar
Cc: [email protected]
Subject: Re: Multi-subnet VNs [was Re: FW: New Version Notification for
draft-yong-nvo3-frwk-dpreq-addition-00.txt]
If you "route if IP, bridge otherwise", the Ethernet header for IP packets is
pretty much just framing; the DA shouldn't matter. To avoid confusion, have the
NVE be the gateway router, and also respond to all ARPs with its own MAC. Then
all IP frames will have a DA of the NVE. That keeps things clean, and "route if
IP, bridge otherwise" falls out naturally.
Kireeti
On Dec 27, 2012, at 1:02, "Vivek Kumar" <[email protected]> wrote:
> Hi Kireeti,
> One clarification . When you say "route if IP, bridge otherwise" , did you
> mean that all IP packets should be routed even if they come without router
> MAC address ( MAC-DA doesn't match the router address) ?
>
> Regards,
> Vivek
>
>
> Date: Wed, 26 Dec 2012 18:48:59 -0800
> From: Kireeti Kompella <[email protected]>
> To: Lucy yong <[email protected]>
> Cc: Thomas Narten <[email protected]>, "[email protected]"
> <[email protected]>, Aldrin Isaac <[email protected]>, "NAPIERALA,
> MARIA H" <[email protected]>
> Subject: Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version
> Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt]
> Message-ID:
> <CABRz93VCm57rc59SdWNuDZuQRfbv_0=ko99mnttrfocysmh...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Lucy,
>
> On Wed, Dec 26, 2012 at 8:33 AM, Lucy yong <[email protected]> wrote:
>
>> Kireeti,****
>>
>> ** **
>>
>> It seems that you make EVPN and IPVPN orthogonal now: If IP, use IPVPN, if
>> not, EVPN.****
>>
>> ** **
>>
>> Do you also see that the end system can be distinguished this way?****
>>
>> ** **
>>
>> Using IP VPN for all the IP applications is good in one way, but it
>> requires the substantial changes on all the hosts/hypervisor and require
>> the behavior changes on the VM/physical server. Giving millions VM/servers
>> are there, will this realistic? Why do we ask all the tenant systems to
>> change behavior in order to use of IPVPN?
>
> The only change needed is on the NVE. If this resides in the
> host/hypervisor, so be it. The NVE has to change to implement IP VPN/EVPN.
> The additional change to "route if IP, bridge otherwise" is minor.
>
> No change is needed on the VM/tenant system.
>
> BTW, as an example, IRB (if my MAC, then route else bridge) is completely
> transparent to the end host (VM, tenant system).
>
> Kireeti.
>
> IMO, IPVPN is very useful for many applications and it is also necessary
>> to support multi-tenancy in DC without changing tenant system behavior.***
>> *
>>
>> ** **
>>
>> Thanks,****
>>
>> Lucy ****
>>
>> ** **
>>
>> *From:* [email protected] [mailto:[email protected]] *On Behalf
>> Of *Kireeti Kompella
>> *Sent:* Friday, December 21, 2012 10:21 PM
>> *To:* NAPIERALA, MARIA H
>> *Cc:* Thomas Narten; [email protected]; Aldrin Isaac
>> *Subject:* Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version
>> Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt]****
>>
>> ** **
>>
>> Hi Maria,****
>>
>> ** **
>>
>> On Dec 20, 2012, at 13:36, "NAPIERALA, MARIA H" <[email protected]> wrote:***
>> *
>>
>> The question is what problem does EVPN solve? ****
>>
>> Pure layer 2 traffic. Yes, it does exist, and needs to be dealt with
>> properly. But just that. ****
>>
>> In the context of DC, EVPN can only address packets bridged in the same
>> VLAN. If most packets are routed then EVPN, even if all the complexity
>> problems are addressed, doesn't achieve anything for the traffic that is
>> routed. I believe it is the wrong tradeoff to design a solution around EVPN
>> (i.e., around bridging).****
>>
>> Agreed.****
>>
>> ** **
>>
>> Kireeti. ****
>>
>> _______________________________________________
>> nvo3 mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/nvo3
>
>
> --
> Kireeti
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
