From: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Date: Monday 16 November 2015 at 08:29 To: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc
In-line From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> on behalf of Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> Organization: Orange Date: Monday 16 November 2015 at 07:37 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, 2015-11-13, Henderickx, Wim (Wim): Thomas, we can discuss forever and someone need to describe requirements, but the current proposal I cannot agree to for the reasons explained. Well, although discussing forever is certainly not the goal, the reasons for rejecting a proposal need to be thoroughly understood. WH> my point is what is the real driver for supporting a plain VXLAN data-plane here, the use cases I have seen in this txt is always where an application behind a NVE/TOR is demanding option c, but none of the NVE/TOR elements. (more below) 2015-11-13, Henderickx, Wim (Wim): Thomas, we need a solution that is implementable and will scale in control/data-plane. As such the solution I outline is standardised today and does not need new extensions in control/data-plane. Hence informational draft and can be implemented if there is market demand. The above argument would fully make sense to me if support MPLS/MPLS/(UDP or GRE) was common place in ToRs or vswitches. With respect to MAC you need to address both directions and does not make sense to manage this if it is not required/doe snot add value. On VXLAN and the Ethernet header: it looks to me that addressing both direction is just a matter of documenting in the draft (if not already there) what is the expected behavior for VXLAN/NVGRE. But VXLAN and NVGRE are not the only encaps proposed in the specs anyway. Compared to 3-label option C, my understanding is that the added-value is to not require the support of an MPLS/MPLS/(UDP or GRE) encap in ToRs and vswitches. The right trade-off to make may in fact depend on whether you prefer: (a) a new dataplane stitching behavior on DC ASBRs (the behavior specified in this draft) or (b) an evolution of the encaps on the vswitches and ToRs to support MPLS/MPLS/(UDP or GRE) WH> b depends on the use case I don't get what you mean by "b depends on the use case". WH> see my above comment. If the real use case is an application behind NVE/TOR requiring model C, than all the discussion on impact on NVE/TOR is void. As such I want to have a discussion on the real driver/requirement for option c interworking with an IP based Fabric. I wrote the above based on the idea that the encap used in MPLS/MPLS/(UDP or GRE), which hence has to be supported on the ToRs and vswitches. Another possibility would be service-label/middle-label/Ethernet assuming an L2 adjacency between vswitches/ToRs and ASBRs, but this certainly does not match your typical DC architecture. Or perhaps had you something else in mind ? WH> see above. The draft right now also requires changes in existing TOR/NVE so for me all this discussion/debate is void. WH> and depending on implementation you don’t need to change any of the TOR/vswitches. Does this mean that for some implementations you may not need to change any of the TOR/vswitches, but that for some others you may ? WH> any proposal on the table requires changes, so for me this is not a valid discussion Let me take a practical example : while I can quite easily see how to implement the procedures in draft-hao-bess-inter-nvo3-vpn-optionc based on current vswitch implementations of VXLAN, the lack of MPLS/MPLS/(UDP, GRE) support in commonplace vswitches seems to me as making that alternate solution you suggest harder to implement. WH> I would disagree to this. Tell me which switch/TOR handles multiple UDP ports for VXLAN ? -Thomas From: Thomas Morin <thomas.mo...@orange.com<mailto:thomas.mo...@orange.com>> Organization: Orange Date: Friday 13 November 2015 at 09:57 To: Wim Henderickx <wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>> Cc: "<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>" <<mailto:bess@ietf.org>bess@ietf.org<mailto:bess@ietf.org>> Subject: Re: [bess] draft-hao-bess-inter-nvo3-vpn-optionc Hi Wim, I agree on the analysis that this proposal is restricted to implementations that supports the chosen encap with non-IANA ports (which may be hard to achieve for instance on hardware implementations, as you suggest), or to context where managing multiple IPs would be operationally viable. However, it does not seem obvious to me how the alternative you propose [relying on 3-label option C with an MPLS/MPLS/(UDP|GRE) encap] addresses the issue of whether the encap behavior is supported or not (e.g. your typical ToR chipset possibly may not support this kind of encap, and even software-based switches may not be ready to support that today). My take is that having different options to adapt to various implementations constraints we may have would have value. (+ one question below on VXLAN...) -Thomas 2015-11-12, Henderickx, Wim (Wim): On VXLAN/NVGRE, do you challenge the fact that they would be used with a dummy MAC address that would be replaced by the right MAC by a sender based on an ARP request when needed ? Is the above the issue you had in mind about VXLAN and NVGRE ? WH> yes I you don't mind me asking : why do you challenge that ?
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
