Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 23 Jul 2003 23:02:23 +0200

Hi Alpesh,

	I'd considered writing something like this, but you beat me
to it! :-)

	Some comments:

	* I don't believe the vendor/org-ID should be in there - 
that would mean that during experimentation, you still could not
use extensions with exactly the format they would have when 
eventually deployed. As laid out in your draft, there is not a
great deal of difference from the existing vendor-specific options,
and one might as well use them. I believe that apart from assigning
the number, the format should be left completely unspecified.

	* In order to be able to experiment with both skippable 
and non-skippable options, there needs to be assigned numbers for
experimental extensions in both ranges. Just one won't do, as 
mip entities already are (should be) coded to handle the two
ranges differently.

	* Possibly 1 single experimental number in each range is
insufficient - witness the AAA key extensions. On the other hand,
it could be argued that in order not to exhaust the existing 
address space too fast, experimenters should be encouraged to use
subtypes, so 1 experimental number in each range is advisable.
Comments?

	Henrik

Wednesday 23 July 2003, Alpesh wrote:
> 
> 
> Hi:
> 
> A new ID is available for your reference at:
> 
> ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-00.txt
> 
>    Abstract
> 
> 
>         Mobile IPv4 message types range from 0 to 255. This document
>         reserves a message type for use by an individual, company, or
>         organization for experimental purpose, to evaluate enhancements
>         to Mobile IPv4 messages before formal standards proposal.
> 
> Thanks
> Alpesh
> 
> 
> 
> 
> 
> _______________________________________________
> Mip4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mip4
> 

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Alpesh <[email-masked]>
Date: Wed, 23 Jul 2003 14:08:29 -0700

Henrik:

Good that you responded on the new alias - so it is functional now!
Also, good that you too were thinking something similar :)

Beyond that, please inline under ALPS>>

>the number, the format should be left completely unspecified.
ALPS>> We thought of doing that, but then that may create 
interoperability issues - the
fix would have been for implementations to include their (C/N)VSEs in 
each message. We
thought that by including the Vendor/Org_ID right in the message type, 
parsing could be
simplified - entity won't have to parse the whole message to analyze the 
semantics.

Comments? Others?

>mip entities already are (should be) coded to handle the two
ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable and 
unskippable
messages. I thought we have reserved the range for extensions only. I 
thought we didn't - but
can double check.

>subtypes, so 1 experimental number in each range is advisable.
ALPS>> See above and beyond that, agree that experimenters would use 
subtypes to
interpret the message differently.

Alpesh

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 23 Jul 2003 23:20:03 +0200

Alpesh,

Oops, sorry,

	There's the danger of assuming similar thoughts! I read
too swiftly, and managed to read experimental *extension* instead
of message!

	No, your're right, we don't have skippable/non-skippable
messages.

	I still don't think the vendor ID should be in there, but
now for a different reason: it would make it inviting to use this
not as an opaque experimental message, but as a vendor-specific
message, which might be used not for experimentation but for 
persistent vendor-specific use. This could be a real destroyer
of interoperability.

	But here's one additional comment then: Maybe it would be
good to specify experimental *extensions* while we're at it? :-)

	Henrik

Wednesday 23 July 2003, Alpesh wrote:
> simplified - entity won't have to parse the whole message to analyze
> the semantics.
> 
> Comments? Others?
> 
> >
> ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable
> ALPS>and 
> unskippable
> >>ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experime
> >ntal-messages-00.txt>
> >>   Abstract
> >>
> >>
> >>        reserves a message type for use by an individual, company,
> >or>        organization for experimental purpose, to evaluate
> >enhancements>        to Mobile IPv4 messages before formal standards
> >proposal.>
> >>Thanks
> >>Alpesh
> >>
> >>
> >>
> >>
> >>

---

From: Alpesh <[email-masked]>
Date: Wed, 23 Jul 2003 14:29:21 -0700

Henrik:
See under ALPS>>

>persistent vendor-specific use. This could be a real destroyer
ALPS>> Even if used as a vendor specific message (I am neither intending 
nor suggesting
that), why would it destroy interoperability?
If my implementation does not know how to parse your messages, then 
there is no
interoperability even for experimental messages - right?

>good to specify experimental *extensions* while we're at it? :-)

ALPS>> Don't the VSE's serve the purpose of experimental extensions? 
Vendors can
then bring to IETF if they want to standardize them.

-a

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 23 Jul 2003 23:55:17 +0200

Wednesday 23 July 2003, Alpesh wrote in reply to Henrik:

> ALPS> Even if used as a vendor specific message (I am neither
> ALPS> intending nor suggesting that), why would it destroy
> ALPS> interoperability? If my implementation does not know how to
> ALPS> parse your messages, then there is no interoperability even for
> ALPS> experimental messages - right?

Well, my thinking was that if vendors design in vendor specific messages
to do various things, and use them for not only experimentation, but
rely on them to make some features work right, it could both decrease
the desire to write up and standardise the features, and evolve into a
morass of tens or hundreds of different ways of implementing more or
less the same feature. Currently, the *messages* are fixed, so the basic
operation of the protocol is the same, while we have vendor-specific
*extensions* to carry special things (and experiment). But if the 
*messages* also come in a vendor-specific flavour, it would basically
be possible to design a whole new alternate protocol in parallel, but
still maintain that it was Mobile-IP.

> ALPS> Don't the VSE's serve the purpose of experimental extensions?
> ALPS> Vendors can then bring to IETF if they want to standardize them.

For sure. But it's the same thing there - you can't use exactly the
same format during experimentation as in final deployment. Having 
experimental extensions available during interop-testing of new
features would ensure we didn't get into the trouble we recently did
with already deployed extension numbers which had not been registered
with IANA.

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Wed, 23 Jul 2003 17:39:43 -0700

>still maintain that it was Mobile-IP.

Good point.  That was what we had in mind to begin with, then thought to
provide a reference format to avoid inter-operability issues between
experimentations.  That resulted in stating the specific message format.

We could go back to original format of having a Type field which is
designated as EXP-MSG-TYPE and rest as opaque.  But also
show the current format as reference model.

Though wondering if conflict between experimentations be required to
be avoided?

>with already deployed extension numbers which had not been registered

If folks deploy messages with unregistered IANA extension types, then
they will need to fix them if the types are assigned elsewhere.  Not sure
having experimental extension type will help?  Let's say experimental
extension type used for an extension w/o IANA type number.  When
IANA assigns the number, the implementation still has to go back to
fix the type number.  There doesn't seem to be alot of difference using
VSEs that are formatted somewhat similar instead.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 24 Jul 2003 09:43:50 +0200

Hi Kent,

> Though wondering if conflict between experimentations be required to

Personally, I'd say that if an extension is used for experimentation,
you need to have some amount of control and monitoring of the
experiment, otherwise you won't get any significant amount of reliable
data to draw conclusions from. You'd certainly want to eliminate other
experiments in the same setup, as they could skew or invalidate your
data. So I'm not even sure that avoiding conflict is advisable, more
important could be to discover influences in your setup which should not
really be there. 

> VSEs that are formatted somewhat similar instead.

There shouldn't be, I guess, but maybe you remember the query I sent you
some months ago about use of unassigned extension numbers? This was
because the number first assigned for one of the UDP tunnelling
extensions was already being used by some implementations for an
aaa-keys extension, and we had to re-assign. Apparently some people had
agreed on those numbers during an interop, and gone ahead and deployed
products with those numbers. There would have been a much stronger
incentive to use VSEs when deploying if all interop testing was done
with a known experimental extension number, I believe.

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Thu, 24 Jul 2003 09:24:10 -0700

>important could be to discover influences in your setup which should not

So this means agreement that existing format remain as reference model,
right?

>with a known experimental extension number, I believe.

Yes, I remember the problem faced before and agree we need to avoid that
in the future.

A few options:

1) Use VSE with Vendor ID 0 "reserved" for pre-standard interop.  I'm not in
     favor of this at all, just wanted to throw the options out there.

2) Add experimental extension types (critical and normal) to the draft as well.
     May be useful to have a range of types instead of just one in each 
category?
     Maybe 8 each?  Note: seems other protocols have also defined experimental
     message types and extensions (ie RADIUS).

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 25 Jul 2003 09:34:37 +0200

> So this means agreement that existing format remain as reference model,

Eh - not sure which original format you mean :-)  - I think the best would be
to use:

      0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     Type      |                   Opaque ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                                   Opaque ... 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
  
>      favor of this at all, just wanted to throw the options out there.

Right, I agree.

>      May be useful to have a range of types instead of just one in each category?

Right. EAP is doing the same in 2284bis.

I originally was thinking 2 or 4 of each, but then I started to think of the 
situation which DHCP faced after some years of deployment - near exhaustion of the
option values - so I thought that it might encourage the use of extensions with
subtypes, rather than multiple extensions, to have only one of each. Thoughts?

	Henrik

---

From: Kent Leung <[email-masked]>
Date: Fri, 25 Jul 2003 01:17:53 -0700

>Eh - not sure which original format you mean :-)  - I think the best would be

This would be the format of Experimental Message.

The one that's in version 00 would be kept as possible way of filling in
the fields for Vendor Specific implementations.

>subtypes, rather than multiple extensions, to have only one of each. Thoughts?

Right, using subtype would be ideal way to conserve type values.  The only 
issue I
see is that if we are trying to use Experimental Extensions so pre-draft 
implementations
can use exact formats with only different type value to inter-operate, then 
this doesn't
provide that capability if the new extension does not have subtypes.

I don't think that's a big deal and can go with your suggestion of just 1 
value for
each category with subtypes.

Thanks.

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 25 Jul 2003 15:10:50 +0200

Hi Kent,

On Friday, 25 Jul 2003, Kent wrote:

> >Eh - not sure which original format you mean :-)  - I think the best
> >would be to use:
> >
> >  0                   1                   2                   3

Ok.

> The one that's in version 00 would be kept as possible way of filling
> in the fields for Vendor Specific implementations.

I see. I'm still a bit doubtful about publishing this format, as it
might facilitate experimental stuff leaking out into deployment, though.

> 
> >I originally was thinking 2 or 4 of each, but then I started to think
> >of the situation which DHCP faced after some years of deployment -
> >near exhaustion of the
> Right, using subtype would be ideal way to conserve type values.  The
> only issue I see is that if we are trying to use Experimental
> Extensions so pre-draft implementations can use exact formats with
> only different type value to inter-operate, then this doesn't provide
> that capability if the new extension does not have subtypes.

True, but only if the existance of only 1 experimental type would make
new designs consistently use subtypes for multiple extensions belonging
to the same feature ,:-)
 
> I don't think that's a big deal and can go with your suggestion of
> just 1 value for each category with subtypes.

Ok. I'm open to using more than 1, too, if there is a proper need for it.

	Regards,
		Henrik