On 5/22/2014 11:19 AM, Black, David wrote:
Concerning your last question, the following sentence in 3.5 indicates that
MTU discovery is the TS's responsibility:
"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."
In that case, the use of "interface MTU" seems off, as I interpret that term
as the link MTU presented by the network interface to the TS (that interface may
be virtual or physical.
Right - and that's typically configurable, but it represents only the
property of the interface and its L2 subnet, not a path (PMTUD and
PLMTUD discover path properties).
Joe
That interpretation would not be correct for a Tenant
System implementation of RFC 4821 (PL PMTUD) that's integrated with a transport
protocol such as TCP because the result has no effect on interface MTU (if the
path MTU is smaller than the interface MTU, TCP sends smaller packets).
If RFC 4821 is implemented to deal with this path MTU discovery requirememnt,
where would that implementation be located?
Thanks,
--David
-----Original Message-----
From: LASSERRE, MARC (MARC) [mailto:[email protected]]
Sent: Thursday, May 22, 2014 4:12 AM
To: Black, David; [email protected]
Subject: RE: Dataplane requirements draft - section 3.5 - path MTU text
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
