Re: comments on draft-park-pppext-mip6-co

> I can't tell, but I assume that the author is intending to propose
> this for publication as some form of RFC (Informational?).  I don't
> think that this should be published as an RFC in its current form.
> There seem to be a number of problems here.

I agree that this draft cannot be published in its current form.
Among other things, LCP is not the right place to negotiate network layer
parameters.

Overall, this protocol appears to be designed to shorten the total IPv6
address assignment conversation, which would normally involve IPv6CP
Identifier negotiation as well as RS/RA.

> Why is a single round-trip time important?  Are there really links
> where this round-trip time is significant compared to any network
> layer traffic that might flow on the link?

The absolute value of the round-trip time may be significant on links such
as GPRS or UMTS where RTT can be 800-5000 ms.  Network layer traffic will
experience the same level of delay, however.

> Is this perhaps papering over implementation flaws, such as an
> inability to buffer datagrams when the link is down or (maybe)
> triggering retransmit at opportune times?

The high RTT times in GPRS/UMTS are in part due to large buffers in the
GGSN;  today's TCP implementations may cause those buffers to fill,
resulting in very high RTT values, and somewhat unstable TCP performance.

> Why is it not sufficient to have the MN remember the last identifier
> it used and try the same one again?

This should work fine.

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext