Hi, > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Xuxiaohu > Sent: Monday, May 04, 2015 7:23 PM > To: Joe Touch; Donald Eastlake; [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [Int-area] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > Hi Joe, > > > -----Original Message----- > > From: Joe Touch [mailto:[email protected]] > > Sent: Tuesday, May 05, 2015 12:12 AM > > To: Xuxiaohu; Donald Eastlake; [email protected] > > Cc: [email protected]; [email protected]; [email protected] > > Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > > > > > > > On 5/3/2015 8:19 PM, Xuxiaohu wrote: > > > Hi Joe, > > > > > > I'm wondering whether your proposal as below is also applicable to > > > other UDP-based encapsulation approaches which have not yet considered > > > doing fragmentation on the tunnel layer, such as GENEVE, VXLAN-GPE, > > > GRE-in-UDP and NSH-UDP. > > > > Again: > > > > We know of at least four things that tunnels need that IP-in-UDP ignores: > > > > - stronger checksums > > > > - fragmentation support > > > > - signalling support (e.g., to test whether a tunnel is up or > > to measure MTUs) > > > > - support for robust ID fields (related to fragmentation, > > e.g., to overcome the limits of IPv4 ID as per RFC 6864) > > I'm just wondering whether the above is only applicable to IP-in-UDP or > applicable to all the other UDP-based encapsulations as well. > > > I haven't scrubbed GUE to ensure that all four are addressed, but it may be > > more > > than the above, and certainly it's important not to start from scratch > > needlessly. > > I don't intend addressing items 1), 2) and 3). As for item 3), I would add > the following text: > > "Ingress AFBRs MUST NOT fragment I-IP [RFC5565] packets (i.e., UDP > encapsulated IP packets), and when the outer IP header is IPv4, > ingress AFBRs MUST set the DF bit in the outer IPv4 header. It is strongly > RECOMMENDED that I-IP [RFC5565] transit core be > configured to carry an MTU at least large enough to accommodate the added > encapsulation headers. Meanwhile, it is strongly > RECOMMENDED that Path MTU Discovery [RFC1191][RFC1981] is used to prevent or > minimize fragmentation." > > Ahead of the following existing text in Section 4: > > "If an ingress AFBR performs fragmentation on > an E-IP packet before encapsulating, it MUST use the same source UDP > port for all fragmented packets so as to ensures these fragmented > packets are always forwarded on the same path." > > > In a word, IP-in-UDP is just intended for those network environments where > fragmentation on the tunnel layer and strong checksums > are not desired. For those network environments where fragmentation on the > tunnel layer and stronger checksums are required, > GUE should be considered instead.
I thought we determined the IP-in-UDP is just GUE with header compression? Thanks - Fred [email protected] > Best regards, > Xiaohu > > > Joe > > > > > > > > > > Best regards, > > > Xiaohu > > > > > >> -----Original Message----- > > >> From: trill [mailto:[email protected]] On Behalf Of Joe Touch > > >> Sent: Saturday, May 02, 2015 3:48 AM > > >> To: Donald Eastlake; [email protected] > > >> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip > > >> > > >> Hi, all, > > >> > > >> Have you considered GUE as an encapsulation layer? > > >> > > >> Encapsulating anything in UDP directly has a number of hazards, > > >> including support for at-rate fragmentation, IPv4 ID generation, > > >> etc., that GUE is intended to address. > > >> > > >> Joe > > >> > > >> On 5/1/2015 9:58 AM, Donald Eastlake wrote: > > >>> Forwarded with permission. > > >>> > > >>> Thanks, > > >>> Donald > > >>> ---------- Forwarded message ---------- > > >>> From: *Donald Eastlake* <[email protected] > > <mailto:[email protected]>> > > >>> Date: Tue, Apr 28, 2015 at 9:26 AM > > >>> Subject: Re: Mail regarding draft-ietf-trill-over-ip > > >>> To: Mingui Zhang <[email protected] > > >>> <mailto:[email protected]>> > > >>> > > >>> Hi Mingui, > > >>> > > >>> Thanks for these comments! See below. > > >>> > > >>> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang > > >>> <[email protected] <mailto:[email protected]>> wrote: > > >>>> Hi, > > >>>> > > >>>> I read the document. It's comprehensive and well written. Below, > > >>>> several > > >> comments for your information. > > >>>> > > >>>> 1. It's not clear how the ports IPs are associated with the ports? > > Maybe, > > >> we can add some words to explain that they can be got from DHCP or > > >> manual configuration? Or we just say it is out the scope of this > > >> document. > > >>> > > >>> Yes, they need to be configured. Could be DHCP or manual or maybe > > >>> some sort of orchestration thing... Seems reasonable to mention this > > >>> in the draft. > > >>> > > >>>> 2. Is it helpful to add a reference topology? Terminologies, such > > >>>> as IP > > >> tunnel, port IPs, RBridges can be put onto this figure. A > > >> walk-through example based on this reference topology can be used to > > >> explain how the IP tunnel is set up, how does a TRILL Data packet get > > >> encapsulated/decapsulated and transported in the IP tunnel. I think this > > would be educational. > > >>> > > >>> A few more network diagrams would probably be helpful. If you look > > >>> at the minutes from the Dallas TRILL WG meeting, the suggestion of > > >>> having a couple of example packets was supported... > > >>> > > >>>> 3. Both IP and TRILL have specified BFD. Since TRILL is dependent > > >>>> on > > IP > > >> in TRILL-over-IP, it's unnecessary to have both TRILL and IP interact > > >> with BFD. It's best to assert TRILL-over-IP will have the IP interact > > >> with BFD. Please refer to > > >> https://tools.ietf.org/html/rfc5882#section-4.4 > > >>> > > >>> Well, if you are only going to use one then I agree with the section > > >>> you reference in RFC 5882 and you should do BFD over IP. But that > > >>> doesn't check the TRILL stack, just the IP and lower stacks. So we > > >>> could recommend just using IP BFD but I don't think we should try to > > >>> prohibit people from also using BFD over TRILL on the link. > > >>> > > >>>> 4. Is the IP link in this document "a single link (physical, or a > > >>>> secure > > >> tunnel such as IPsec)"? Then, we can require the TTL "MUST be set to > > >> the maximum on transmit, and checked to be equal to the maximum value > > >> on reception (and the packet dropped if this is not the case)." See > > >> also RFC 5880 Section 9. > > >>> > > >>> I don't think so. There is nothing wrong with the communication > > >>> between two TRILL IP ports being multiple IP hops. Even if IPsec is > > >>> in use, it could be integrated with the TRILL over IP port at one > > >>> end but at the other end, the IPsec implementation could be > > >>> integrated with a firewall a couple of hops from the RBridge... > > >>> > > >>>> 5. There are six tiny typos marked in the attached doc. > > >>> > > >>> OK. We'll fix this up in the next version. > > >>> > > >>> Maybe you should post these comments, or some of them, to the TRILL > > >>> WG mailing list. It would be good if there was more discussion of > > >>> drafts there. Or if it OK with you, I could just forward your > > >>> comments and my responses to the list... > > >>> > > >>> Thanks, > > >>> Donald > > >>> ============================= > > >>> Donald E. Eastlake 3rd +1-508-333-2270 <tel:%2B1-508-333-2270> > > (cell) > > >>> 155 Beaver Street, Milford, MA 01757 USA [email protected] > > >>> <mailto:[email protected]> > > >>> > > >>>> Thanks, > > >>>> Mingui > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> trill mailing list > > >>> [email protected] > > >>> https://www.ietf.org/mailman/listinfo/trill > > >>> > > >> > > >> _______________________________________________ > > >> trill mailing list > > >> [email protected] > > >> https://www.ietf.org/mailman/listinfo/trill > > _______________________________________________ > 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
