Subject: Re: [MOBILE-IP] Consensus for the extensions template defined in MIER

From: Mohamed Khalil <[email-masked]>
Date: Wed, 12 Jan 2000 16:52:12 -0600

> -----Original Message-----
> From: Wolfgang Schoenfeld [SMTP:[email-masked]]
> Sent: Wednesday, January 12, 2000 4:16 AM
> To:   [email-masked]
> Subject:      Re: [MOBILE-IP] Consensus for the extensions template
> defined in MIER
>
> > Basavaraj Patil wrote:
> >
> > The MIER draft (draft-ietf-mobileip-mier-00.txt) states that all new
> > extensions defined for Mobile IP in the future MUST follow the
> > template that is specified in the document.
> > The difference from the existing definition specified in RFC2002 is
> > that adds a subtype field and the length field is increased two
> > octets.
> >
> > If you have concerns or disagree with this proposal, please express it
> > on the mailing list by the end of this week.
> >
> > -Basavaraj Patil
>
> I disagree with the proposal, for the following reasons.
>
> Let me view types and subtypes as a means of multiplexing a control
> channel.
> Adding a subtype field to the type field of Mobile IP has two effects.
> First, there are more bits,
> hence more channels can be multiplexed.
> Second, these bits are partitioned in two groups,
> hence implementations may use a two-layer nesting of switches
> (if-statements).
> Neither from the discussion in this mailing list
> nor from the extensive tests we carried out with current Mobile IP
> can I conclude that Mobile IP needs more channels
> or a two-layer arrangement of these channels.
> Though this should suffice as a justification (I think that
> the necessity of adding something should be proved,
> not the necessity of not adding it),
> I'd like to repeat some known arguments with which I agree.
> First, existing software would have to be re-implemented.
> [MK>]  I disagree completely by what you said, no software has to be
> re-implemented at all. All what you have to do for the protocols which
> adopt MIER is to have one function to process the general type and inside
> this function the subtype will be processed. In the matter of fact it
> aggregate processing similar elements in one function instead   of
> multiple ones. This will make implementation and debugging problems more
> easier. I don't understand why do you think that existing software has to
> be re-implemented?
>
.

> Second, existing proposals for protocol extensions would have to be
> re-worked.
> [MK>]   We agree with that but we think that this re-work would be for the
> benefit of the WG.
.
> Third, there is some chance that future proposals are hard to fit
> [MK>] General statemets does not proof anything. Give me an example for
> one which cannot fit. All what i am doing is adding a subtype field to the
> current extension and increasing the length field. How would these minor
> changes really make it hard for future proposals?
> into the MIER format, anyhow.
> Fourth, having more bits for the type field might entail
> the temptation to overburden Mobile IP.
> [MK>] I don't understand how this could be true?
>
> -- Wolfgang Schoenfeld
> GMD-IPSI, Dolivostr. 15, Room 128, D-64293 Darmstadt
> +49-6151-869-865 (Phone), -818 (FAX)
> +49-170-2285450 (Mobile Phone)

---

From: Wolfgang Schoenfeld <[email-masked]>
Date: Thu, 13 Jan 2000 11:34:36 +0100

I wrote:

> ...
> re-implemented at all. All what you have to do for the protocols which adopt
> MIER is to have one function to process the general type and inside this
> function the subtype will be processed.

There is no guarantee that all implementors have followed this systematic way.
The (current) RFC does not say anything about that.
Imagine someone optimizing his/her code by masking the type field,
i.e. going to the very bits!

> In the matter of fact it aggregate
> processing similar elements in one function instead   of  multiple ones. This
> will make implementation and debugging problems more easier.

Again, this is an implementation issue and, perhaps, can also be
solved by some clever masking. Note that the type-subtype field separation
hinders flexible use of all bits in the field
(compare the role of subnet masking of IP addresses in routing!).

> I don't
> understand why do you think that existing software has to be re-implemented?

You are right: It may happen that, when considering to incorporate MIER,
some implementors will not feel forced to completely re-implement.

>
> Second, existing proposals for protocol extensions would have to be re-worked.
>
> [MK>] General statemets does not proof anything. Give me an example for one
> which cannot fit. All what i am doing is adding a subtype field to the current
> extension and increasing the length field. How would these minor changes
> really make it hard for future proposals?

I'm very sorry - YOU should prove that all future proposals fit to MIER,
and not me that there is some which does not. See my previous note.

> [MK>] I don't understand how this could be true?

This was meant similarly to the well-known programming experience:
Not always does an abundance of resources (here: bits to represent types)
lead to better (seen from the user) programs.

Hoping not to annoy the other readers of this mailing  list,
yours

Wolfgang Schoenfeld