Re: Comments on PMTU-Draft-RFC
mogul (Jeffrey Mogul) Fri, 02 February 1990 17:40 UTC
Received: by acetes.pa.dec.com (5.54.5/4.7.34)
id AA18426; Fri, 2 Feb 90 09:40:48 PST
From: mogul (Jeffrey Mogul)
Message-Id: <9002021740.AA18426@acetes.pa.dec.com>
Date: 2 Feb 1990 0940-PST (Friday)
To: mtudwg
Cc:
Subject: Re: Comments on PMTU-Draft-RFC
I'll save the hard ones for the IETF meeting, but there are a few of Steve Deering's comments that are easy to take care of: page 6, third paragraph: I agree with Pradeep, concerning the confusion over whether or not the next-hop field contains zero. Seems to me there is *no* need ever to set it to zero -- the decision can always be: "is this my address or not". As it is, you've introduced three states (my address, zero, other), when only two are needed (my address, other), making it harder to understand the protocol. Or have I missed some subtle requirement for three states? One thing that some people apparently have missed is that the whole point of this next-hop business is so that when the option reaches the last-hop router, it is possible to know if ALL the routers on the path have correctly updated the MTU value. Steve is correct, though, that if we change the protocol so that a router simply stops updating the next-hop field if it isn't "right", rather than setting it to zero, it will be "wrong" when it reaches the last-hop router; that is, there is no need for the zero state. Keith pointed out to me that this change means that, at least at the receiver, you automatically get the address of the (first) router that doesn't understand the option. This might make finger-pointing easier! page 20, section 8.5: do you want to mention proxy-ARP situations? That's a case where PMTU discovery would be useful, but the sender thinks it is sending to a neighbor. Of course, in that case, the next-hop field doesn't work too well. Is proxy ARP being actively discouraged yet? Proxy ARP is only "used" (unwittingly) by senders that have not been upgraded to support subnetting (or more precisely, RFC950). I see no reason to expect that a sender that is upgraded to support MTU discovery would not also be upgraded to meet the existing mandatory standards. Does the RFC have to include explicit prohibitions against stupidity? -Jeff
- Comments on PMTU-Draft-RFC Nuggehalli Pradeep
- Re: Comments on PMTU-Draft-RFC Keith Mc Cloghrie
- Re: Comments on PMTU-Draft-RFC Steve Deering
- Re: Comments on PMTU-Draft-RFC Jeffrey Mogul
- Re: Comments on PMTU-Draft-RFC Philippe Prindeville
- Re: Comments on PMTU-Draft-RFC Philippe Prindeville