On Tue, May 5, 2015 at 1:41 PM, William Caban <[email protected]> wrote: > > >> On May 5, 2015, at 12:52 PM, Behcet Sarikaya <[email protected]> wrote: >> >> On Tue, May 5, 2015 at 1:31 AM, Joe Touch <[email protected]> wrote: >>> >>> >>> On 5/4/2015 7:05 PM, Larry Kreeger (kreeger) wrote: >>>> Hi Joe, >>>> >>>> Please see my response in this thread >>>> http://www.ietf.org/mail-archive/web/nvo3/current/msg04612.html . >>>> >>>> Also, could you explain the problems that would be caused by indicating >>>> IPv4/IPv6 directly rather than requiring implementations to look at two >>>> places to determine this? >>> >>> 1. it accounts for only IPv4 and IPv6, not any subsequent values >>> >>> 2. it encourages the encapsulation layer to handle these two >>> differently, when they should not be handled differently >>> >>> IP is a protocol. v4 and v6 are versions. >> >> +1 >> >> I think that Ethernet and NSH are not needed. NSH is not a protocol, >> it is some abstract data. How NSH will be encapsulated is being >> discussed in SFC WG. >> So if the payload is only IP, then why do we need the next protocol field? >> >> Behcet > > > Next Protocol Ethernet type is needed for scenarios where you want to > encapsulate Ethernet based protocols which do not use IP (i.e. VLAN, FCoE, > etc). >
Is this scenario(s) explained in the draft? I said Ethernet next protocol header is not needed because that case is already handled by VXLAN. Behcet > _William > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
