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

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Feb 2008 17:01:14 -0800

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
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Feb 2008 06:39:20 +0200

Ted,

> I assume that the WG is reviewing the changes in parallel. 
...
> I assume that the issuance
Thanks for your review.

Just for information about the versions. -09 was issued in response to
AD review comments; the review and the required changes were discussed
on the mailing list during January. (I normally do not ask for WGLC to
be repeated based on changes relating to AD review, unless, of course,
the document needs to go back to the WG process for redesign. Or if the
discussion shows that there the changes are contentious.)

When -09 came out it was OK from my perspective except for one issue
relating to the handoff indicator semantics. I started the Last Call
anyway but asked the authors to fix the remaining issue in -10 in parallel.

There has been a small amount of editorial corrections etc that have
been detected in the WG in the meanwhile and those have also been put
into -09 and -10.

Authors, WG, please respond to Ted's technical comments.

Jari

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Thu, 14 Feb 2008 23:17:03 +0200

Hi Ted,

I agree with you on the notion that we shouldn't publish anything that we
know already that will need fixes or does not work properly for the intended
use at this point. However, I think it is completely proper to revise
specifications based on operational experience - ever rather quickly after
publishing as a PS. Though, seldom done I have understood it is has been
even the original idea of the three step standardization process.

However, that is not my main point. And I don't quite agree that this
document in its current format is in a shape where we would have to revise
it right after publishing.

I would like to comment a bit on your proposal to make the MN-AR draft a
normative reference, and moving MN-AR to standards-track. First of all, I'm
happy to say that the MN-AR draft has been revived and can be found at
http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt

Secondly, taking into account the multiple customers for the pmip6 and the
multitude of environments where PMIP is either going to be used or
potentially going to be used (3GPP, 3GPP2, Wimax to my understanding) I
don't think it is possible to write a MN-AR draft that would cover
adequately those networks and be really useful for them. I think the purpose
of the MN-AN is not to show how PMIP6 should be deployed, but how it could
be deployed. I however do agree that MN-AR draft should go forward in the
working group and it should not be forgotten.

I cross-posted this to the netlmm mailing list to make sure everybody knows
this discussion is going on.

Cheers,

Jonne. 

On 2/14/08 3:01 AM, "ext Ted Hardie" <[email-masked]> wrote:

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

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 14 Feb 2008 17:55:27 -0800

Hi Jonne,
	Thanks for your reply; some comments inline.

>even the original idea of the three step standardization process.

I agree that we should be able to revise specifications very quickly.
RFC 2026 is pretty clear, though, that we shouldn't publish things that
we believe are missing important pieces:

   A Proposed Standard should have no known technical omissions with
   respect to the requirements placed upon it.  However, the IESG may
   waive this requirement in order to allow a specification to advance
   to the Proposed Standard state when it is considered to be useful and
   necessary (and timely) even with known technical omissions.

The tricky bit here is that the requirements placed on this have shifted
since the work was chartered, and it is not clear whether the technical
omissions here are meant to be consonant with the original charter,
even though they don't meet the technical requirements of the current
working scope.

As you should also note in reading my mail, I am encouraging the IESG to waive
this requirement in order to get this document out in a timely fashion,
but with a forward pointer in place that would allow us to indicate
we intend to fill the empty slot in the toolbox and, generally speaking,
where someone should eventually look for the tool.

>http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-03.txt

Good news indeed!

>working group and it should not be forgotten.

I'm glad that you also support MN-AR going forward.  I also hope that you
are too pessimistic on the possibility of making a general mechanism.
While the networks you cite are certainly complex and will no doubt have
systems engineering documents which describe exactly how to use PMIP
in their environments, that's not the work I'm suggesting the IETF should take
on.  Instead, I'm suggesting that we need and should complete the work
of describing a general mechanism specifying how a mobile node
talks to a mobile access gateway.  That may well not replace the systems
engineering work needed by the current customers for PMIP, but it will make
the work more generally useful.  It may even be in the fullness of time
that the mobile-node to MAG signalling will be used in those environments,
once it is generally available. 

Thanks again for your thoughtful reply,
				regards,
					Ted Hardie

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 14 Feb 2008 19:17:07 -0800

Hi Ted,

Thanks for the review. Please see inline.

Regards
Sri

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ted Hardie
> Sent: Wednesday, February 13, 2008 5:01 PM
> To: [email-masked]; [email-masked]
> Subject: Re: Last Call on draft-ietf-netlmm-proxymip6
> 

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

> 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
> is inconsistently available. Adding the higher-layer 
> signalling makes this a complete solution.
> 
> 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.
> 
> 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.  
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Feb 2008 06:31:53 -0800

Ted,

Responding to your scope question.

Actually, we are walking a fine line with the scope. At the time that
this work got chartered, we did not have a good understanding of all the
issues. After two years of development and analysis there are some parts
of the problem space that we understand better. One of these issues
relates to being able to provide a Netlmm service without breaking
existing hosts. In 2007 it became apparent that we actually have to
understand the semantics of the host's attachment in order to not cause
a problem in situations like having two interface cards in the same host
both connected to the same Netlmm domain. Fortunately, this information
is available in certain major use cases of Netlmm. For instance, in
cellular networks the link layer actually knows what is happening when a
host moves around and can distinguish new vs. moved attachments. The
support for multihoming/cross-access handovers in the document is
actually very limited, merely building on this. Its a side effect of
having to prevent a problem. As I have required that the WG not cause a
problem I also have to accept the implications. I think avoiding the
problem is more important.

(By the way, the multiple interfaces question is not the only scope
issue in the WG; they also want to work on IPv4 support. A rechartering
process is in progress for this and possibly some other extensions.)

With regards to host modifications for handling multihoming and all
types of cross-technology handovers: the current document supports
limited forms of this, and requires support from link layer to do this.
As I mentioned above such support exists in the networks that are prime
customers for this work. However, I think there is interest for an L3
solution, and I think it would be interesting work. From the perspective
of the current document that would merely be an additional source of
information. But at the same time I think it would be beneficial to look
at other issues around the multiple interfaces/handovers question. I
would support adding something along these lines to the new charter, and
have the WG produce extensions for this.

However, this should be seen as an option for relatively limited class
of networks that can actually assume host changes. For instance,
networks with purpose built handsets. I still believe in the current
charter's core idea that unmodified hosts must be able to plug into
Netlmm domains and work at least as well as they would without Netlmm.
In fact, I would go as far as stating that requiring host modifications
would be a complete non-starter for most of the applications of Netlmm
that I am aware of. As a result, I am against extending mn-ar-if with
new functionality and making its support a requirement for mobile nodes,
if that's what you meant.

I am on the other hand supportive of such extension. I'm even supportive
of it eventually becoming even mandatory to implement on the network
side. Perhaps this is actually what you wanted? Note that there is
really no interoperability issue with making such an extension from day
one vs. later. Hosts do not know Netlmm is running in the network, and
obviously they cannot assume they will only visit Netlmm-based networks.
As a result, whatever additional service they wish to get from the
network would have to be negotiated anyway.

Hope this clarifies,

Jari

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Feb 2008 14:55:46 -0800

At 6:31 AM -0800 2/15/08, Jari Arkko wrote:
>issues.

Jari, the charter explicitly rules out some of the work in this document.
I don't have a problem with the current scope, but it isn't a fine line:
"The protocol will not attempt to hide handover  between two separate interfaces on the mobile
node." is actually one of the clearer charter statements we've ever written.

> After two years of development and analysis there are some parts
>host moves around and can distinguish new vs. moved attachments.

At least as I understand it, this required work from folks like 3gpp; they
had to define a solution that let the network know whether a mobile
supported PMIP or not.  I very much appreciate the clarity now in the document
that strongly indicates that in the absence of clear indicators that an
inter-technology attachment is a handoff, it MUST be treated as multi-homing.
Without that clarity, we would be in a far worse place. 

> The

I appreciate your willingness to have this work go forward.  As you recognize,
there are currently "prime customers" for this work who have a sense of
the system changes they will require to deploy inter-technology PMIP
(e.g. terminals capable of using a virtual interface over multiple physical
interfaces; handoff indicators at multiple link-layers, and so on).  Without
an L3 interface that allows the terminal to support PMIP, those will be
difficult deployments.  They seem to have the engineering resources
to succeed, but both that crop of networks and some not in our current
crop of customers will find this much easier going with at least the
option of using a standard L3-or-above mechanism to signal their support
of PMIP and to provide handoff indicators.

>that I am aware of.

For Netllmm systems within a single technology, this is not required.  It
is not even required for multi-technology hosts in a network capable of
providing  inter-technology hand-off, providing the network does not try
to do inter-technology hand-off to unmodified hosts.  But inter-technology
hand-off requires hosts that understand that an IP address they got on
interface0 may show up on interface1; pretty generally that involves a
modification to allow for a virtual interface that covers both.

>As a result, I am against extending mn-ar-if with

Hosts that do no know NETLMM is running in an inter-technology handoff
network do not get handoff when changing technologies.   They get multi-homing. 
That's fine, but we need to be as clear in discussion as the draft is that this is the case. 
In the current networks, they may well signal their support and handoff at
layers below IP; for the current customers that may, indeed, work well
enough.  But I believe that a standardized solution to the more general
problem is a necessary part of this solution, and we should strongly indicate
where it will fit in the toolkit as soon as possible. 

For those who wonder how often the multi-interface case will arise, the laptop
I am using has 5 physical interfaces that can run IP (ethernet, bluetooth, 802.11,
firewire, evdo), and the phone sitting next to it 3 (802.11, bluetooth, cellular).

Thanks for your response and clarifications,
					Ted

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 19 Feb 2008 13:49:59 +0200

Ted,

Thanks for your kind words and sorry for taking my time to answer. Please,
find below some thoughts, comments, and questions to your mail.

>    necessary (and timely) even with known technical omissions.

I agree, and I think I wrote that as well in my mail. We shouldn't publish
PS'es with known technical omissions. Instead we should fix the omissions or
problems when we find them.

However, I don't think we have such technical omissions in the current
draft. I think the draft - due to extensive review and long debates - is in
a pretty good shape.

> even though they don't meet the technical requirements of the current

I think this is the general problem we seem to have sometimes in the IETF.
We charter things for a year's worth of work, but in the end the work takes
quite some years more than that. The requirements have shifted and the
original scope doesn't fit the solution needed in the end. Hence,
flexibility is needed.

I think "the right thing to do" would have been to recharter the work
already earlier to fit the right problem. However, it didn't seem worth the
effort earlier as the main focus still should be on the technical work.

> where someone should eventually look for the tool.

I'm happy that you also find the flexibility needed in this case. However,
I'm not really sure what you are referring to with your comment about an
empty slot in the toolbox. Which slot in your mind seems to be empty?

[snip]
> once it is generally available.

I am generally a pessimist. I have heard that a pessimist is never
disappointed. However, I think in this particular case I would say that it
is not really pessimism. Practically the MN-AR interface is very link layer
dependent. Different systems have quite different link layers and might have
rather different procedures. So, I don't think a general view is really
possible, or perhaps even desirable.

I have to say that I don't see much use currently to specify a standard for
MN-AR signalling in the IETF. Not at least currently. However, perhaps I'm
missing something here.

Thank you for your comments, and I guess I forgot to thank you for your
review of the document as well!

Cheers,

Jonne.

>>> First, let me start by saying that -09, which was put out for Last Call, was
>>> a
>>> substantial
>>> and the number of really solid additions in this update was quite high.  I
>>> was
>>> a bit
>>> I assume that the WG is reviewing the changes in parallel.   I assume that
>>> the
>>> issuance
>>> This document (and, as I understand it, the working group discussion for
>>> some
>>> time)
>>> is because it does handle the multi-interface case.  While it would have
>>> been
>>> nice
>>> to the network is one of the clearest and most likely to be interoperable
>>> ways
>>> to achieve
>>> big win here would be to enable the signaling .  As it stands, the
>>> operations
>>> are based
>>> 3) Go ahead with IESG processing on this document on the basis of the
>>> existing
>>> Last Call
>>> for signalling  where the mobile node had the capability and interest.
>>> Where
>>> it did
>>> that I'm in favor of pretty much anything that reduces the need for updated
>>> IP
>>> addresses

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34