On 5/19/2017 11:09 PM, Xuxiaohu wrote: >> GUE is supposed to be both signalling and content (data), where the data are >> IP >> packets. > Since IANA strives to assign one port for a service, IP packet within the UDP > tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP > are distinguished by the different port numbers. GUE is one service that includes both encapsulation of IP packets and signaling. Frankly, it seems like it would work anywhere IP works - where IPv0 is defined as the signalling channel (which is sufficient because IPv0 isn't defined).
In that case, the first field after v0 needs to be a signal channel version number, to allow for future updates. > >> Take away the IP part and GUE isn't an E anymore. >>>> Services are expected to have version fields and subtype >>>> demultiplexing indicators, to so that all message variants of current >>>> and future versions can use a single port number. >>> Sure, the version field within the IPvx packet could be used for >>> demultiplexing >> purpose. >> >> That demultiplexes within IPvx. There still needs to be a way to demultiplex >> non-IPvx packets (control) from IPvx. > Since GUE and IP-in-UDP have different UDP port numbers, They don't and they shouldn't. That would complicate forwarding - a single service needs to use a single port. Using separate ports complicates configurations - this is a case where you want "fate sharing" (either both IP encapsulation and the signal channel work or neither do). > I don't know why there is still a need to demultiplex GUE and IP-in-UDP. The point of GUE is an IP encapsulation channel with in-band signalling. That is a single service, IMO. Note - AFAICT, GUE could work anywhere an IP packet works. IP packets always start with a version number, and v0 isn't really defined. Defining v0 as the signal channel is the same thing as how GUE is currently specified. Joe
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
