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:[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
