On Thu, Apr 18, 2002 at 04:01:29PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> I've attached a revised version of the proposed text according to
> discussions after the proposal, including very recent results.
> I'll soon submit a new I-D with this change, but if you see something
> missing in the attached text, please let me know.
> Also, path MTU discovery for multicast has severe scalability
> limitations and should thus be avoided.
... by default.
Not sure if you want to spend rfc space on tis, but this would be the
rationale i would give:
... Applications sending multicast traffic should explicitly enable
path MTU discovery only when they understand that the benefit of
possibly larger MTU usage outweights the possible impact of MTU
discovery for active sources across the delivery tree(s).
And here is an outlook you may want to add (or not):
... This default behavior is based on todays available MTU path discovery
mechanism and may change in the future once better scalable mechanisms are
sufficiently ubiquitously available.
(As in: We do well understand what technology must be defined/deploy to
allow for efficient and scalable path MTU discovery for ip multicast
(like: define an appropriate GRA option and ensure that everybody and
his routers implement this), but practice has shown that it won't happen
because it is not there yet, it's not even defined, so at best we can start
to work on it, but i wouldn't bet any major wagers on a chance to see it
in a mayority of routers within 5 years).
Cheers
Toerless
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
