Hi Xiaohu, (removed sfc, nvo3 and trill lists from distribution)
I have gone through this thread and feel that the distribution list
for this thread seems to be excessive. If you do believe that there are
intarea specific issues that need to be addressed, please feel free to
start a new thread (preferably with an appropriate subject line) on the
intarea list. Otherwise, please discuss wg specific issues on the
respective wg mailing lists.
Thanks
Suresh
On 05/05/2015 10:53 PM, Xuxiaohu wrote:
-----Original Message-----
From: Joe Touch [mailto:[email protected]]
Sent: Wednesday, May 06, 2015 12:33 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/4/2015 7:23 PM, Xuxiaohu wrote:
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.
That's insufficient. They are only applicable where fragmentation and a strong
checksum are not *needed*.
Agree that "needed" is a more appropriate word.
Once you run IP in IP (IP in UDP in IP qualifies as this), you have only two
choices:
- support fragmentation
- use in networks that are engineered so that
fragmentation is never needed
As to the strong checksum, similarly you have to either support one or deploy
the result where that checksum isn't needed - either because you know that all
apps will have strong enough checksums of their own or because you know
enough about the kinds of errors that will occur that strong checksums aren't
needed.
But the key there is to define a use case where these properties are true AND to
limit the document solution to uses in those case ONLY.
The use case is the Softwire networks (including both mesh and hub-spoke modes)
where IP-in-IP and IP-in-GRE are good enough to address the MTU and checksum
issues.
Best regards,
Xiaohu
For those network environments where fragmentation on the tunnel layer
and stronger checksums are required, GUE should be considered instead.
Agreed.
Joe
_______________________________________________
sfc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sfc
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
