Subject: RE: [mobile-ip] parameters in draft v16

From: George Tsirtsis <[email-masked]>
Date: Thu, 4 Apr 2002 12:01:48 -0500

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Thursday, April 04, 2002 5:40 PM
To: [email-masked]
Cc: [email-masked]; Scott Corson; Vincent Park; Matt
Impett
Subject: Re: [mobile-ip] parameters in draft v16

> Given the hope that MIPv6 will be with us for considerable time :-) we
were
> wondering if something better can be done for future compatibility. The
> current spec only allows for skippable parameters. Wouldn't be useful to
> also allow for non-skippable parameters? Since "parameters" are TLVs, one
> could set aside 'Type' space for non-skippable parameters. If one of the
> non-skippable parameters is received but not recognized the receiver
should
> send an error code indicating "unknown parameter".

We currently have two methods for introducing incompatible changes (things
where either the sender needs to know that the receiver doesn't support it):
 - use a new message type in the MH protocol
	Oops - the spec should say what a node does when receiving 
	an unspecified type. Send an ICMP parameter problem seems like
	the right thing.

GT> Yes, as the moment it only says that an error should be sent back...but
not what kind of error.

 - use the parameter/option echo mechanisms much like TCP SYN - SYN|ACK.
   If the receiver understands the option it includes the some option
   in the response (where a response is a HoT for a HoTI, a BA for a BU etc)

I *think* those two mechanisms are sufficient for extensibility.

GT> OK, so you say that the sender of, for example a BU, with a future
parameter extention sould get back a BAck which will include the same
extension. If the extention is not included it means that it was not
understood and ignored. The potential problem is that the BU was
nevertheless accepted and thus a new binding was created. I am wondering if
there is value in supporting extensions that unless accepted should force
the receiver to *drop* rather than ignore the message and return an error.

George

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 5 Apr 2002 11:00:46 +0200 (CEST)

> the receiver to *drop* rather than ignore the message and return an error.

If you don't want the BU to be processed unless the CN supports the new stuff
you'll end up doing an extra roundtrip in that case.
So it would be ok to define a new "BUnew" MH type for this purpose,
get the error back, and fallback to the "BU" MH type.

If you want to avoid the extra roundtrip and are using RR then the HoTI/HoT
can be used to exchange the capabilities i.e. the MN can find out
whether the CN supports the new functionality.

So I don't see what a "mandatory option" notion would add here.

   Erik