Finally, some visible progress
mogul (Jeffrey Mogul) Fri, 12 January 1990 23:35 UTC
Received: by acetes.pa.dec.com (5.54.5/4.7.34)
id AA26646; Fri, 12 Jan 90 15:35:25 PST
From: mogul (Jeffrey Mogul)
Message-Id: <9001122335.AA26646@acetes.pa.dec.com>
Date: 12 Jan 1990 1535-PST (Friday)
To: mtudwg
Cc:
Subject: Finally, some visible progress
Most of you may have wondered what has happened to this working group. Well, as you may remember, Keith McCloghrie and Rich Fox volunteered at the meeting (exactly one month ago today) to draft an RFC describing the protocol we arrived at during the meeting. Keith, Rich, and I have exchanged numerous messages and several drafts of the RFC, and (because the February IETF is less than a month away) it is now time to circulate it among the members of the group. Some of you might notice on your own that we've made some changes from the consensus proposal that emerged from the meeting. Most importantly, we have eliminated any transport-level involvement in the discovery protocol itself. I don't think any of you actually wanted transport-level involvement, although some argued that it appeared to be necessary. Keith and Rich have worked out a simple, although fairly subtle, mechanism that allows all the work to be done at the IP level and yet doesn't pollute the net with lots of ICMPs if someone happens to run NFS at the wrong time. The very astute reader will realize that this is no longer really Steve Deering's "Report Fragmentation" scheme at all, but something that we are calling "Unexpected Fragment Report" which tracks changes in the apparent MTU rather than simply the occurrence of fragmentation. For the less-astute reader: well, now you know anyway. We have also simplified the format of the IP Path MTU (PMTU) Query option; this was driven by the scarcity of space in the IP header option area. The "Valid" flag is now implicitly encoded in the next-hop address field, saving one bit. The "Fragmentation Report Allocation" (original Keith's send-N reports mechanism) has been changed, from something sent in the option by the sender, to an architected constant; this is because we didn't expect the senders to actually excercise any discretion in the value, and we saved another few bits in the IP option (meaning at least one byte!). My hope is that during the next 3 weeks we will be able to arrive at a consensus that the basic scheme is either sound or unsound, and argue about some of the details. At the February IETF meeting (which Keith, Rich, and I plan to attend) we have a half-afternoon session scheduled (Wednesday, Feb. 7), and I hope that at that meeting we can lay to rest any remaining doubts. In other words, allowing some time for final draft preparation, we should have an RFC out in early March. The RFC itself follows in another message. -Jeff
- Finally, some visible progress Jeffrey Mogul