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. 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
