Hi Lucy,

> -----Original Message-----
> From: Lucy yong [mailto:[email protected]]
> Sent: Wednesday, April 29, 2015 11:48 AM
> To: Templin, Fred L; Tom Herbert
> Cc: [email protected]; [email protected]
> Subject: RE: [Int-area] Why combine IP-in-UDP with GUE?
> 
> >
> > Change the GUE header to treat the first nibble as a next header selector. 
> > 4 means IPv4, 6 means IPv6 and X means GUE.
> > [Lucy] As I mentioned in several previous mails, I don't think that
> > this is a good design for GUE. Even if a compression is required, the
> > solution SHOULD use a separate UDP port to indicate IP first and then check 
> > the first nibble for IPv4 or IPv6, which, in fact, is the IP-
> in- UDP proposal.
> 
> I will say again that the IP-in-UDP proposal as it stands does not have a 
> solution for tunnel fragmentation (made available by GUE).
> [Lucy] That is true. The IP-in-UDP proposal applies the case where no 
> fragmentation at tunnel end point is needed. GUE can deal with
> it.

Existing tunnel protocols (IP*-in-IP*) are deficient in not providing a tunnel
fragmentation mechanism per Section 3.1.7 of RFC2764.

> > However I agree with Tom that the compression concept does not align
> > with GUE principal. GUE encapsulation should not assume IP payload in first 
> > place!
> 
> The proposed solution does not assume IP; it assumes a next header selector 
> in the first nibble of the data following the UDP header.
> Non IP can be conveyed when the next header selector indicates GUE.
> [Lucy] the first nibble is intended for indicating version of IP, not for a 
> next header selector. Forcing other protocol to follow this
> assumption is bad. Please read RFC4928.  There are many cases that GUE 
> payload is IP or other and GUE header is required. The first
> nibble design splits majority from a corner case as first logic, which is a 
> bad design. The "compression" version does not have the same
> tunnel property as GUE based tunnel, we should not mix them at design level.

I disagree with "bad", and I do not think RFC4928 is applicable when the first 
nibble
appears within a UDP encapsulation for which there is a specific user of that 
UDP
port number. ECMP classifications in the network would not reach deeply into a
UDP encapsulation in order to inspect bits specific to that UDP port.

Thanks - Fred
[email protected]

> Lucy
> 
> Thanks - Fred
> [email protected]
> 
> > Regards,
> > Lucy
> >
> >
> >
> > Thanks - Fred
> > [email protected]
> >
> > > Tom
> > >
> > > > Thanks - Fred
> > > > [email protected]
> > > >
> > > >> Tom
> > > >>
> > > >> > Thanks - Fred
> > > >> > [email protected]
> > > >> >
> > > >> >> Lucy
> > > >> >>
> > > >> >> Thanks - Fred
> > > >> >> [email protected]
> > > >> >>
> > > >> >> > However, if GUE payload is
> > > >> >> > IP, it is OK to inspect the first nibble of the payload to 
> > > >> >> > determine IPv4 or IPv6 because this aligns with IP protocol.
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Lucy
> > > >> >> >
> > > >> >> > - Stewart
> > > >> >> >
> > > >> >> >
> > > >> >> >
> > > >> >> > _______________________________________________
> > > >> >> > Int-area mailing list
> > > >> >> > [email protected]
> > > >> >> > https://www.ietf.org/mailman/listinfo/int-area
> > > >> >> >
> > > >> >> > _______________________________________________
> > > >> >> > Int-area mailing list
> > > >> >> > [email protected]
> > > >> >> > https://www.ietf.org/mailman/listinfo/int-area
> > > >> >
> > > >> > _______________________________________________
> > > >> > Int-area mailing list
> > > >> > [email protected]
> > > >> > https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area

Reply via email to