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.
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. From: Thomas Morin <[email protected]<mailto:[email protected]>> Organization: Orange Date: Friday 13 November 2015 at 09:57 To: Wim Henderickx <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
