Route (IP traffic) within subnet is happening, regardless physical or virtual, vpn or non-vpn, call it enhanced/advanced forwarding. Luyuan
-----Original Message----- From: Lucy yong <[email protected]> Date: Tuesday, December 18, 2012 10:10 AM To: Luyuan Fang <[email protected]>, Kireeti Kompella <[email protected]>, "NAPIERALA, MARIA H" <[email protected]> Cc: Aldrin Isaac <[email protected]>, "[email protected]" <[email protected]> Subject: RE: [nvo3] FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt >My comments are inline. > >> -----Original Message----- >> From: Luyuan Fang (lufang) [mailto:[email protected]] >> Sent: Tuesday, December 18, 2012 12:04 AM >> To: Kireeti Kompella; NAPIERALA, MARIA H >> Cc: Aldrin Isaac; Lucy yong; [email protected] >> Subject: Re: [nvo3] FW: New Version Notification for draft-yong-nvo3- >> frwk-dpreq-addition-00.txt >> >> >> >> On 12/17/12 1:57 PM, "Kireeti Kompella" <[email protected]> >> wrote: >> >> >For IP traffic, whether intra and inter-subnet, IP VPNs suffice. >> >> Yep. >[Lucy] not sure. We are working on the network virtualization. The one of >goals is to virtualizes the enterprise physical networks that provides >the networking for compute resource on a DC common infrastructure. If you >look at today's enterprise data center networks, do they all use routers >without any switch? Not at all. If routers can do all the functions, why >it is not the case today in any physical network? You may argue that they >are legacy. But I do not see a new built DC without a switch too. Why is >that? How can we assume that IP VPN is sufficient for a tenant virtual >network. > >> > >> >The solution is simple: route if IP, bridge if not. Yes, one could do >> >IRB, but why? IRB brings in complications, especially for multicast. >> >> Exactly, thank you for speaking out. >[Lucy] Again, IRB are widely used in enterprise data center. It is >useful. How do we know that IP VPN is not complicated for a tenant >virtual network? >> >> >> >I'm sure someone suggested this already, so put me down as supporting >> >this view. >> >> I believe Pedro gave detailed explanations many times a few months ago. >> Of >> course, Maria and I had been expressing such opinions all along on-line >> and off-line, and brushed off good amount of bullets. :-). >[Lucy] IMO: Pedro's solution applies to certain application, but not >other application. For example, his draft does not mention how to provide >a broadcast for a subnet. Unless a tenant virtual network does not need >this at all, we can not remove this requirement. >> >> > >> >If there is a case for _only_ intra-subnet traffic, one may create an >> >E-VPN to handle both IP and non-IP; but I suspect this is a rare case. >> >> A solution just for some very narrow cases is not that too useful. >[Lucy] Not at all. Another objective of NV03 is the ability to move TS >among different servers regardless if they are on the same or different >subnet. Do you see this is "very narrow cases"? > > >Sorry, we are back to use VPN terms again. I did not start this. > >Regards, >Lucy >> >> >From that point of view, I would like to see E-VPNs in the data center >> >*always* coupled with IP VPNs, and only dealing with non-IP traffic. >> >> Do you mean the following? IP VPN alone is sufficient if all traffic is >> L3 >> or handling the majority traffic which is IP; but E-VPN is not in the >> same >> case, E-VPN needs to leverage IP VPN for inter-subnet routing (unless >> you >> never get out of a subnet), therefore it needs to "*always* coupled >> with >> IP VPNs"? >> If this is correct understanding, and we are talking about VPN cases >> only >> (there are also other non-VPN options too), I agree with you. >> >> The "*always* coupled" wording makes me a little nervous, better to ask >> you to elaborate. >> >> What I don't want to see is that the implementation ties IP VPN and E- >> VPN >> together. If the traffic is IP (might well be 90+% cases), there should >> not be any E-VPN involvement. If both L2 and L3 are needed, there >> should >> be clear demarcation, not mixed together, not sharing the same VRF, not >> make one VPN with some l2 sites and some l3 sites. Let's keep it clean >> and >> simple. >> >> > >> >This may appear drastic, but I think operationally, this is will >> simplify >> >things. >> >> Yes, operation simplicity is the key to success. IP VPN is a living >> proof. >> Others are not at par. >> >> I think Thomas Narten and Maria both expressed the point to avoid >> complication, agree with them too. >> >> >> I have a larger question, not to Kireeti or any particular person. >> How come we only talk about MPLS VPNs here now? >> What happened to other technologies? Were not VXLAN and NVGRE the >> original >> motivation for nvo3? >> I am a MPLS VPN person, but I also don't believe in one size fits all. >> IP >> VPN or E-VPN are right for some operators, cannot say for everyone. >> Where >> are the folks talking non MPLS topics? >> >> Luyuan >> >> >> > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
