Hi, all,
Why not just have the Tenant Systems that act as end hosts just follow
RFCs 1122 and 1123?
I.e,:
----
Tenant Systems that source or sink IP traffic are Internet hosts, and
thus are (already) required to be compliant with RFC 1122 and 1123.
Tenant Systems that forward IP traffic are Internet routers, and thus
are (already) required to be compliant with RFC 1812 (etc.).
---
(that goes for a lot of other stuff in this doc - if properly mapped to
existing Internet components, there is no need for either new mechanism
or even new requirements).
Joe
On 5/22/2014 1:11 AM, LASSERRE, MARC (MARC) wrote:
Hi David,
Thanks for the suggested text. It will be incorporated in the next revision.
Concerning your last question, the following sentence in 3.5 indicates that MTU
discovery is the TS's responsability:
"The interface MTU as seen by a Tenant System SHOULD be adjusted such that no
fragmentation is needed. This can be achieved by configuration or be discovered
dynamically."
Marc
-----Original Message-----
From: nvo3 [mailto:[email protected]] On Behalf Of Black, David
Sent: Wednesday, May 21, 2014 6:14 PM
To: [email protected]
Subject: [nvo3] Dataplane requirements draft - section 3.5 -
path MTU text
Turning to the dataplane requirements draft, here's proposed
elaboration text for the path MTU material in section 3.5 (no
change to the second and third bullet items - they're
included for completeness):
OLD
Either of the following options MUST be supported:
o Classical ICMP-based MTU Path Discovery [RFC1191]
[RFC1981] or
Extended MTU Path Discovery techniques such as defined in
[RFC4821]
o Segmentation and reassembly support from the overlay layer
operations without relying on the Tenant Systems
to know about
the end-to-end MTU
o The underlay network MAY be designed in such a
way that the MTU
can accommodate the extra tunnel overhead.
NEW
At least one of the following options MUST be supported:
o Classical ICMP-based MTU Path Discovery [RFC1191]
[RFC1981] or
Extended MTU Path Discovery techniques such as defined in
[RFC4821]. Both techniques are based on use of
probe packets.
Classical MTU Path Discovery requires ICMP
responses from
the underlay network. Extended MTU Path
Discovery requires
detection of probe packet loss at the receiver
and means to
communicate that loss to the sender.
o Segmentation and reassembly support from the overlay layer
operations without relying on the Tenant Systems
to know about
the end-to-end MTU
o The underlay network MAY be designed in such a
way that the MTU
can accommodate the extra tunnel overhead.
------------------------------
There's an additional question - what does that initial
"MUST" ("At least one of the following options MUST be
supported:") apply to??
The framework draft text on this topic describes Tenant
Systems using MTU discovery techniques, whereas some of the
options above apply to the nvo3 dataplane (e.g., overlay
segmentation and reassembly could reside in NVEs).
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
