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
