Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

["Templin, Fred L" <[e-mail]>]

Hi,

> -----Original Message-----
> From: Int-area [mailto:[e-mail]] On Behalf Of Xuxiaohu
> Sent: Monday, May 04, 2015 7:23 PM
> To: Joe Touch; Donald Eastlake; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Int-area] [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
> 
> Hi Joe,
> 
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Tuesday, May 05, 2015 12:12 AM
> > To: Xuxiaohu; Donald Eastlake; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > 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
[e-mail]

> Best regards,
> Xiaohu
> 
> > Joe
> >
> >
> > >
> > > Best regards,
> > > Xiaohu
> > >
> > >> -----Original Message-----
> > >> From: trill [mailto:[e-mail]] On Behalf Of Joe Touch
> > >> Sent: Saturday, May 02, 2015 3:48 AM
> > >> To: Donald Eastlake; [e-mail]
> > >> 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* <[e-mail]
> > <mailto:[e-mail]>>
> > >>> Date: Tue, Apr 28, 2015 at 9:26 AM
> > >>> Subject: Re: Mail regarding draft-ietf-trill-over-ip
> > >>> To: Mingui Zhang <[e-mail]
> > >>> <mailto:[e-mail]>>
> > >>>
> > >>> Hi Mingui,
> > >>>
> > >>> Thanks for these comments! See below.
> > >>>
> > >>> On Tue, Apr 28, 2015 at 4:27 AM, Mingui Zhang
> > >>> <[e-mail] <mailto:[e-mail]>> 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   [phone] <tel:%2B1-508-333-2270>
> > (cell)
> > >>>  155 Beaver Street, Milford, MA 01757 USA  [e-mail]
> > >>> <mailto:[e-mail]>
> > >>>
> > >>>> Thanks,
> > >>>> Mingui
> > >>>
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> trill mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/trill
> > >>>
> > >>
> > >> _______________________________________________
> > >> trill mailing list
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/trill
> 
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area