Hi Joe, Vxlan is a Layer-2 tunnel and carries layer-2 frame(complete packet including l2 header) as payload. Hence the encap/decap and information derivation differs from L3-tunneling mechanism. L2 payload can contain non-IP encapsulation as well (ARP etc)
Secondly, Vxlan Gateway can potentially act as a Layer-2 gateway and Layer-3 gateway for client devices connected over same or different subnet respectively. For Layer-2 gateway case, MTU derivation may not make sense, as the destination is one L3-hop away. Though this is contentious, and it can still be implemented to allow judicious use of resources (computational and bandwidth) in core network , but the end point device should not be expecting an icmp error in this case. If we venture out in l2 gateway scenarios, then there may be cases of Vxlan packet encap is done with Outer Destination IP as multicast address bound to the vni. Though I can recheck its feasibility for L3-gateway case. Vxlan gateways in a typical datacenter deployment may act as ToR and hence may have anycast address configuration. That needs to be avoided while generating ICMP errors in underlay network from these devices. Although anycast configuration should be client facing and not part of the underlay. Thanks Saumya. On 7/1/15, 11:20 PM, "Joe Touch" <[email protected]> wrote: > > >On 6/30/2015 8:29 PM, Saumya Dikshit (sadikshi) wrote: >> Hi Joe, >> >> Thanks for your comments. I will surely remove these references from >> draft. >> Those were more of typo misses and shouldn¹t have been there in first >> place. >> >> The idea in this draft is to provide a solution, wherein >> Vxlan gateway can translate the icmp errors (either PTB or >>Fragmentation) >> generated in the underlay and pass it on to the end-point device. > >If that is your goal, then it should focus on the specific issue of ICMP >translation in the title. However, it's important to understand exactly >how this is unique or different for Vxlan vs any other IP encapsulation. > >If it isn't provably different, then IMO this WG should leave it alone >and cite existing specs. > >Joe _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
