Thanks for the review. Please see inline.
Behalf Of Ted Hardie
Sent: Wednesday, February 13, 2008 5:01 PM
To: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call on draft-ietf-netlmm-proxymip6
Summary: One issue needs resolution.
First, let me start by saying that -09, which was put out for
Last Call, was a substantial
improvement over the -08. I normally read Last Call
documents using a diff tool,
and the number of really solid additions in this update was
quite high. I was a bit
surprised, given the extent of the new text, that there was
no WG last call, but
I assume that the WG is reviewing the changes in parallel.
I assume that the issuance
of -10, which came out during the last call, was a response
to one or more reviews
from the WG or solicited experts.
To call out one particular improvement, I found the update's
multi-homing much clearer, and I believe the risk of
assignment of the same
address to multiple interfaces is much reduced in this
version. Given the
potential consequences (watching your stack scream "I'm
melting! I'm melting!"
as someone entertainingly put it), that's a really good thing.
There are still some opportunities for editorial update, and
I hope that as
the IESG enters its discussions that some of those are
targets for resolution.
I'd particularly like to see even more clear light on the
bullet 4 of Section 220.127.116.11, as "predictably knows" is not as clean as
it might be. (The current sentence is: "The Handoff
Indicator field MUST be set to
value 1 (Attachment over a new interface), if the mobile
access gateway predictably
knows that the mobile node's current attachment to the
network over this
interface is not as a result of an handoff of an existing
mobility session (over
the same interface or through a different interface), but as
a result of an
attachment over a new interface. "). But that is really a
problem, at least I hope, at this point.
There are clearly specified rules as when a mobile access
gateway is allowed to choose a specific handoff hint. These
rules are clearly layed out and there was a quite of focus in
the AD review on this aspect. It is not the intent of the
document to allow the mobility entities to specify a given
handoff hint, say HI=Handoff between MAG's, unless it is
absolutely sure its the same session that is being handed off.
Probably there needs to be better choice of the words in the
above rule. It is a language clarity issue. We will rephrase
The big issue that remains is actually one that starts from
the scope creep.
I was on the IESG during the period when this charter was
approved, and it
was clear at the time that some of the limitations being put
in were intended
to focus NETLMM on cases where nodes were re-associating at
layer 2 with the
same network. The charter says, for example: "The protocol
will not attempt
to hide handover between two separate interfaces on the
This document (and, as I understand it, the working group
discussion for some time)
has gone beyond that initial scope. A good portion of this
is because it does handle the multi-interface case. While it
would have been nice
to have the charter updated to state the new scope, I don't
personally have a
problem with the scope. I am concerned, however, that the
changed with that new scope and that other parts of the
charter are limiting
folks' understandings of what can be done here, when those
restraints are really
salient for the single layer 2 initial scope.
To put it simply, given the inter-technology handoff,
signalling from the mobile node
to the network is one of the clearest and most likely to be
interoperable ways to achieve
the correct behavior in some of the base cases. At the
moment, because the mechanisms
for setting the handoff indicator do not necessarily involve
the mobile node (and are
appear to be below IP where between the mobile node and the
networ), a mobile node with multiple interfaces will not
always be able to signal that it desires handoff or
prefers multihoming. The document is now clear that in that
case it gets
multihoming. That's a tremendous advance over the previous
state. But the really
big win here would be to enable the signaling . As it
stands, the operations are based
on the handoff indicator provided by the MAG, but the
document does not provide
any information on how the MAG will know this information.
There certainly will
be cases where a network architecture will allow the MAG to
use layer 2 indicators
or other mechanisms, but there will also be cases where that
set of mechanisms
is inconsistently available. Adding the higher-layer
signalling makes this a complete solution.
I'm concerned that sending the document out in its current
state will either require
a quick re-spin at PS to enable this once the issues arise in
deployment or that some of
the contexts in which this is intended to be used will work
around the problem in ways which will hinder an
interoperable, long-term deployment.
I am very conscious, however, that there is considerable time
pressure on this
document. I propose the following as a way forward which
should not add any significant delay.
1) Add an explicit, normative reference to
draft-netlmm-mn-ar (which would
need to be revived) as the basis for a forthcoming above-IP
using an RFC-Editor's note.
2) Put draft-netlmm-mn-ar on the standards track, but make an
downref statement for this document to the internet-draft.
This would allow
this document to progress without delay, but provide a
reference for those who
will be deploying this in contexts which do not have the same
network management of the networks for which this is urgent. When
draft-netlmm-mn-ar is published, it would be available, of
course, to both network types.
3) Go ahead with IESG processing on this document on the
basis of the existing Last Call
date, with the understand that the IESG would reconsider only
if the second Last Call
with the explicit downref raised new issues. IESG
consideration prior to the end of a Last Call already occurs
in some cases, and it certainly could be used in this case to meet the
I'm aware that the charter states that there should be no
between the mobile and the network. In the context of the
original design scope,
that should have been read quite strictly. In the context of
the current design scope,
I believe we have to distinguish between making something
required and setting
a standard way of handling something in the inter-technology
case. I do not believe
that adding this normative reference would make it required.
It would simply
show how the IETF intended to meet the need for an
for signalling where the mobile node had the capability and
interest. Where it did
not, the basic mechanisms in this draft would suffice.
I understand that this has been an active, and at times
contentious, area of discussion,
and I do not want this last call comment to fan any old
flames. As an APPs guy, trust
that I'm in favor of pretty much anything that reduces the
need for updated IP addresses
and all the concomitant pain. I also see us about to miss
an opportunity here, by
setting out a toolkit that is missing a critical tool. I
don't believe the time pressures
here should or need to stop us from building the full
toolkit, even if the first shipment
of toolboxes goes out simply with the right shape cut out, to
be filled later.
Ietf mailing list
Ietf mailing list