Joe, I am for whatever allows us to do direct encapsulation (i.e., IP/UDP/IP with NULL GUE header) in the simplest way possible. I'm not too concerned with future-proofing it; is that what you are worried about?
Thanks - Fred > -----Original Message----- > From: Joe Touch [mailto:[email protected]] > Sent: Thursday, May 25, 2017 3:14 PM > To: Tom Herbert <[email protected]>; Templin, Fred L > <[email protected]> > Cc: [email protected] > Subject: Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number > resource running out?// re: I-D Action: draft-ietf- > intarea-gue-04.txt > > > > On 5/25/2017 1:40 PM, Tom Herbert wrote: > > On Thu, May 25, 2017 at 12:44 PM, Templin, Fred L > > <[email protected]> wrote: > >> If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I > >> agree > >> > >> with the current spec and that direct encapsulation (i.e., with no > >> additional > >> > >> encapsulations between the IP/UDP and inner IP headers) is desirable and > >> > >> should remain as part of the spec. I think we may be over-thinking this. > >> > > +1. I think a little too much has been inferred beyond the what is > > actually in draft. Versions are straightforward: > > > > - There is a two bit version number field that begins GUE header. The > > format of the rest of the header depends on the version. > > - Version 0 defines an encapsulation header that encapsulates by IP > > protocol number. > > - Version 1 defined a means for direct encapsulation of select > > protocols as an optimization. Formats for IPv4 and IPv6 are defined. > > - Version 2 and 3 are reserved > I continue to be confused as to why it is more useful to try to make > decisions based on the first two bits rather than the first four. > There's near zero benefit, and the harm is that you end up with only two > reserved versions. > > > > > Rather Version 1 constitutes a new version or a different format seems > > to be a matter of terminology, however semantically and implementation > > wise the intent is clear. If it's necessary the field could be renamed > > "version/format" > It is not a version; I think that's at least part of the problem. It's a > type or kind, but version implies that V0 is superceded by V1, which may > or may not be backward compatible with V0. > > Joe > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
