yes but if you're using GPE as an encap mechanism then any payload type needs to be explicitly named.
On Mon, May 11, 2015 at 2:16 PM, Behcet Sarikaya <[email protected]> wrote: > 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 >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
