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

From: George Tsirtsis <[email-masked]>
Date: Wed, 3 Apr 2002 18:53:57 -0500

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Wednesday, April 03, 2002 10:33 PM
To: [email-masked]
Cc: Scott Corson; Vincent Park; Matt Impett
Subject: Re: [mobile-ip] parameters in draft v16

George Tsirtsis wrote:

> 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".

Ah, the 'M' bit familiar to us from a number of other protocols ;-)

It's possible. I'm not sure if it's worth it though. Exactly what
will we lose if we don't have that possibility?

GT> Well, we can think of something I am sure :-). But seriously the concern
is about any type of future extension that will result in error if the
receiver just ignores it and processes the rest of the packet. Without the
'M' bit, we will never have the option of creating such extensions. Are we
prepared to make that call now? and why would we?

...
Anyway, the 'M' bit approach for parameters has also some
concerns, one of them being the possibility that vendors
"lock in" peers to use the same vendors since a vendor-specific
parameter would have the 'M' bit on. But perhaps this can be
handled by the IETF not allocating any parameter type codes
with the 'M' bit on without a very general purpose use.

GT> And/Or maybe we place a requirement that only extensions that result in
actual error, rather than inconvenience, are allowed to set the 'M' flag.

George

George

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 4 Apr 2002 18:40:15 +0200 (CEST)

> Given the hope that MIPv6 will be with us for considerable time :-) we were
> non-skippable parameters is received but not recognized the receiver should

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.
 - 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.

IPv6 destination options have a skippable/non-skippable notion
but IPv6 isn't a request/response protocol like MH or TCP.

   Erik

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 5 Apr 2002 07:20:52 -0500

Erik,

What you say makes sense, a new MH type can be used with the same results to
non-skippable parameters. So, I think it is fine...although it would still
be good to define what kind of error is returned on unrecognized MH Type, as
you mentioned earlier.

Thanks
George

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]]
Sent: Friday, April 05, 2002 10:01 AM
To: George Tsirtsis
Cc: 'Erik Nordmark'; [email-masked]; Scott Corson;
Vincent Park; Matt Impett
Subject: RE: [mobile-ip] parameters in draft v16

> 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.

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