The question that I have is: How does your notion of flow-based forwarding relate to the notions of L2 and L3 service in the problem statement and framework drafts?
We've had a prior discussion of IRB (combined L2/L3 implementation) and my impression of the conclusion of that discussion is that the service is still L2, but the L3 implementation has been optimized. Is something similar going on here? Thanks, --David From: [email protected] [mailto:[email protected]] On Behalf Of Lizhong Jin Sent: Thursday, July 25, 2013 11:52 AM To: Thomas Narten Cc: [email protected] Subject: Re: [nvo3] Arch: Flow based forwarding service On Thu, Jul 25, 2013 at 12:53 AM, Thomas Narten <[email protected]<mailto:[email protected]>> wrote: > 1. Since TS is the end of the network, flow (e.g, 5 tuple) based VN > forwarding would bring much network flexibility. The L2/L3 VN service is > the traditional service, but I believe the VN should have the capability to > provide a flow based forwarding service. I'm not at all sure what it would mean for the VN itself (that is NVO3) to provide "flow based forwarding service". What did you have in mind? What benefits would that have? [Lizhong] flow based forwarding will not have influence to the underlay, but the interface between NVE and NVA needs to exchange the flow entry, not L2/L3 forwarding entry. There would be some scenario for flow based forwarding, e.g, firewall needs to forward different flow to different VM. The benefits is more finely control of the flow distribution. In my mind, how traffic is forwarded by the underlay network is entirely the business of the underlay. Flow based forwarding would be fine, if desirable. But, that would be completely orthogonal to NVO3 and the virtual network itself. I don't see right off the need for NVO3 itself to be involved in this. Thomas
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
