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

[Joe Touch <[e-mail]>]

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 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.

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