Hi Xiaohu, Joe,
On Sun, May 3, 2015 at 10:19 PM, Xuxiaohu <[email protected]> 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. > This is a very good question. Let me give draft links below for Joe in case he can not find them: VXLAN-GPE: https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-00 GENEVE: https://www.ietf.org/archive/id/draft-gross-geneve-02.txt Regards, Behcet > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
