> -----Original Message----- > From: Templin, Fred L [mailto:[email protected]] > Sent: Wednesday, May 06, 2015 10:39 PM > To: Xuxiaohu; Joe Touch; Tom Herbert > Cc: Donald Eastlake; [email protected]; [email protected]; [email protected]; > [email protected] > Subject: RE: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > HI, > > > -----Original Message----- > > From: Xuxiaohu [mailto:[email protected]] > > Sent: Tuesday, May 05, 2015 7:47 PM > > To: Joe Touch; Tom Herbert; Templin, Fred L > > Cc: Donald Eastlake; [email protected]; [email protected]; [email protected]; > > [email protected] > > Subject: RE: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > > > > > > -----Original Message----- > > > From: Joe Touch [mailto:[email protected]] > > > Sent: Wednesday, May 06, 2015 3:42 AM > > > To: Tom Herbert; Templin, Fred L > > > Cc: Xuxiaohu; Donald Eastlake; [email protected]; [email protected]; > > > [email protected]; [email protected] > > > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > > > > > > > > > On 5/5/2015 12:34 PM, Joe Touch wrote: > > > >> Or just define a simple version translation as part of encapsulation. > > > >> > So for IPv8: > > > >> > > > > >> > 0x1000->0x0101 on encapsulation > > > >> > 0x0101->0x1000 on decapsualtion > > > > And what happens to 0x0101 WHEN it shows up? > > > > > > > > You need more patterns than you have because IP is allowed to use > > > > any of them. > > > > > > FWIW, you're essentially arguing for bit-stuffing, i.e., if a > > > pattern you think will be common shows up, don't stuff, and if something > else shows up, then do. > > > > > > That works only if you do true stuffing, e.g.,: > > > > > > 0x01** = uncompressed > > > (might as well add 0x11** and 0x10** to that) > > > 0x00** = compressed > > > > > > But then if 0x0000, 0x0001, 0x0010 or 0x0011 show up, you need to > > > decide how to represent them - they CANNOT be uncompressed without > > > at least two more bits somewhere else that indicates they're uncompressed > and their value. > > > > > > So now your GUE methods are very sensitive to IP version numbers, > > > which IMO defeats the "G" in the name. Never mind how this > > > complicates hardware when > > > > Agree. As I had mentioned to Tom in private, I do believe the > > additional capability of GUE (e.g., fragmentation) would be much > > useful in some network environments. However, since GUE is intended to > > be a generic UDP encapsulation approach, we'd better design it as > > generic and future-proof as possible from the beginning, specifically > > speaking, > without being deeply influenced by a particular GUE payload type. If both > foo-in-GUE (foo could be NSH, TRILL...) and foo-in-UDP (i.e., a compact > version > of foo-in-GUE) are needed someday, could you still achieve the same effect as > that for IP-in-UDP (as a compact IP-in-GUE) and IP-in-GUE? > > I don't get why we are still talking about this. We have already shown how > IP-in-UDP can be properly accommodated by GUE with header compression.
Show us how TRILL-in-UDP and NSH-in-UDP can be properly accommodated by GUE with header compression as well. Best regards, Xiaohu > Thanks - Fred > [email protected] > > > Best regards, > > Xiaohu > > > > > (not if) other IP versions are used (for whatever reason). > > > > > > Joe > > > > > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
