Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

["Templin, Fred L" <[e-mail]>]

Hi Joe,

> -----Original Message-----
> From: Joe Touch [mailto:[e-mail]]
> Sent: Tuesday, May 05, 2015 12:33 PM
> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
> 
> 
> 
> On 5/5/2015 11:47 AM, Templin, Fred L wrote:
> > Hi Joe,
> >
> >> -----Original Message-----
> >> From: Joe Touch [mailto:[e-mail]]
> >> Sent: Tuesday, May 05, 2015 11:26 AM
> >> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; [e-mail]
> >> Cc: [e-mail]; [e-mail]; [e-mail]
> >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
> >>
> >>
> >>
> >> On 5/5/2015 11:04 AM, Templin, Fred L wrote:
> >>> Hi Joe,
> >>>
> >>>> -----Original Message-----
> >>>> From: Joe Touch [mailto:[e-mail]]
> >>>> Sent: Tuesday, May 05, 2015 10:54 AM
> >>>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; [e-mail]
> >>>> Cc: [e-mail]; [e-mail]; [e-mail]
> >>>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
> >>>>
> >>>>
> >>>>
> >>>> On 5/5/2015 9:39 AM, Templin, Fred L wrote:
> >>>>> Hi Joe,
> >>>> ..
> >>>>>> IP in UDP adds only port numbers and an Internet checksum.
> >>>>>>
> >>>>>> That doesn't address fragmentation; if outer fragmentation is assumed,
> >>>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet
> >>>>>> checksum is insufficient to correct those collisions.
> >>>>>
> >>>>> Right - that is why we have GUE. But, when these functions are not
> >>>>> needed GUE can perform header compression and the result looks
> >>>>> exactly like IP in UDP.
> >>>>
> >>>> That seems impossible.
> >>>
> >>> Not impossible - Tom Herbert provided the solution:
> >>>
> >>> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html
> >>
> >> That is allocating bits (or bit patterns) from the IP header.
> >>
> >> The solution provided - to check for 0x01 - is incorrect. IP can have
> >> versions that include 0x10 and 0x11.
> >
> > The version field in both IPv4 and IPv6 have that bit set to 1. If GUE
> > then deems that bit to indicate "direct IP encapsulation, then there
> > is no need for a GUE header of length greater than 0.
> >
> > You may say that future IP protocol versions might not have that bit
> > set in the version field. But, the version bits for IPv4 and IPv6 will
> > never change (by definition) and we do not see a new IP protocol
> > version replacing IPv4 or IPv6 on the near-term horizon.
> 
> 0x01 is valid for four version numbers:
> 	4
> 	5
> 	6
> 	7

Sure.

> You cannot assume either that 0x01 always means IPv4 and IPv6 only OR
> that any other pattern is NOT an IP packet UNLESS GUE is assigned the
> values you are assuming (e.g., 0x00, 0x10, 0x11), and that's not going
> to happen.

You are making this way more complicated than it really is. 0xX1XX means
that this is an IP header - at this moment, either IPv4 or IPv6. But, having
checked the bit the next step is to test the entire nibble to ensure that it
is indeed either 0x0100 or 0x0110. And, if it is neither, the packet is
dropped due to a malformed header.

But, 0xX0XX means that the GUE header is present. There is no ambiguity
here, and it just works.

> As I said on the other post:
> 
> 	Codepoints you aren't assigned aren't yours to assume.
> 
> > Even if a new IP protocol version emerged with the "direct IP
> > encapsulation" bit set to 0, that version can still be accommodated
> > by GUE. It's just that direct encapsulation cannot be used and a
> > non-zero-length GUE header is needed.
> 
> It's more than that - you need to ensure that all other IP values are
> NOT interpreted as uncompressed.

Again, you are twisting something that is very simple to make it appear
complicated when in fact it is not.

Thanks - Fred
[e-mail]

> Joe