On Thu, Mar 27, 2014 at 1:57 PM, Tom Herbert <[email protected]> wrote:
> On Thu, Mar 27, 2014 at 1:50 PM, Anoop Ghanwani <[email protected]> > wrote: > > > > > > > > On Thu, Mar 27, 2014 at 11:34 AM, Erik Nordmark <[email protected]> > wrote: > >> > >> > >> On 3/21/14 9:25 AM, Tom Herbert wrote: > >>> > >>> 7) In a large network bit errors, HW failures, SW bugs are common > >>> occurrences. It's problematic that in VXLAN and nvgre even a single > >>> bit error in the vni could misdirect a packet to the wrong VM (no CRC > >>> or checksum protects vni). > >> > >> > >> It sounds like we need some approach to be able to avoid misdelivering > >> packets if there is a bit error in the vni field. > >> I suspect there might be multiple approaches (UDP-lite covering the NVO3 > >> header, header checksum field in the NVO3 header). > > > > > > I must be missing something...why is the CRC of the received Ethernet > frame > > not enough? That does cover the VNI along with the rest of the packet. > > When an NVE receives a packet, if it experiences a CRC error, it should > be > > discard the frame and not try to decap it. > > This is a layer 3 protocol. A packet may routed across several hops > some of which might not even be Ethernet. > The CRC protects the entire frame till it gets to a router. Once in the router, it's the responsibility of the router to maintain packet integrity and not introduce errors via an internal checksum or some other mechanism. A similar issue exists with MPLS labels used for tenant identification. If we don't trust the router, then we have a problem. IPv6 lacks a header checksum and I'm not aware of many routers that will compute the TCP checksum in order to validate the integrity of the IPv6 destination address before delivering it to a host. Anoop
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
