ietf
[Top] [All Lists]

Re: Last Call on draft-ietf-netlmm-proxymip6

2008-02-13 18:02:15
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 language around 
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 description in
bullet 4 of Section 6.9.1.1, 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 language clarity
problem, at least I hope, at this point.

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 mobile node.".  
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 document's 
complexity 
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 design constraints 
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 signalling 
mechanism, 
using an RFC-Editor's note.

2) Put draft-netlmm-mn-ar on the standards track, but make an explicit 
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 highly-structured 
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
time pressures.  


I'm aware that the charter states that there should be no signalling required 
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 interoperable mechanism 
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.

                        regards,
                                Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>