Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND

From: Gregory Daley <[email-masked]>
Date: Tue, 02 Mar 2004 00:19:14 +0900

Hi,

I know that this has been cross posted, so I'll
respond to both lists, but perhaps we can talk about
specific issues in the individual mailing lists
subsequently.  I'd suggest DNA, unless the MIP6
chairs wish to respond.

If we need to discuss needs more generally for 
multiple interface configuration procedures or
vertical handoff, it may be useful to take it up 
with the chairs of either or both WGs (depending
on the circumstances).

Please see my take below.
----- Original Message -----
From: NJEDJOU Eric FTRD/DMR/REN <[email-masked]>
Date: Monday, March 1, 2004 9:51 pm
Subject: RE : [DNA] Current IETF-Draft version - POLIMAND

> Pekka,
> The problem with MIP6 movement detection handover optimizations 
> (see http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical-
> handover-00.txt for another draft) is that it is being considered 
> out of scope for DNA because of the mobile IPv6 issue raised and 
> out of scope for MIP6 because of the link triggers that has to be 
> taken into account. Actually, it is within the scope of both as 

I'd guess while this is frustrating, it's largely a statement 
of fact.

Please inform me of any incorrect statements I make, since
there may be subtlties I miss in the drafts.

While the drafts being discussed are principally interested in
handling multiple connectivity scenarios associated with 
wireless networks, neither MIPv6 (regarding Link hints) or
DNA (Discussing global signalling) are currently chartered to 
work on these topics.

It is indeed possible that the combination of the techniques
is seen as the stumbling block by both groups.

For example, if indeed it is necessary to provide vertical
handover support for MIPv6, is it strictly necessary to talk
about link layer interactions (polimand may talk about policy instead,
Of course, it is always hard to standardize policy).

Whether a document looking at multiple interface connectivity
for MIPv6 would be useful or not (or whether there's much difference
except the movement detection algorithm) I don't know.

Particularly for DNA, we can't really discuss handovers,
considering that this term principally refers to session
restoration or continuation using mobility protocols.

DNA is looking basically at signalling using mechanisms 
within the local link only.  Any reference to other
protocols (except in a confined way) can make documents
look like they're (for example) MIP specific.

If there's a difference in the configuration detection
procedures when a host has multiple interfaces, that may be
different.

For example, a host may wish to wait passively for router
advertisements on the GPRS interface (testing reachability
when the host switches connections to that interface), and
probes fairly aggressively on a WLAN interface.

Any decision or action based on this the configuration detection
is starting to push into uncomfortable areas as far as DNA's tight
charter  is concerned.  Perhaps this is analogous to the reasoning
used in MIP6?

> DNA -link triggers/hints that will be catalogued/standardized 
> within DNA will also be used for Mobile IPv6 optimised movement 
> detection. Other ones may be needed for this specific purpose. 
> Better detecting network attchment/detachment is a requirement for 
> Mobile IPv6 better performance movement detection and handover. 
> These issues are therefore strongly linked. 

I think we have to be particularly careful about the word
standardized in the previous paragraph.
There's already been some out-of-band feedback to DNA that we
should avoid delving into standardization of L2 oriented
mechanisms.

> MIP6 -Optimized movement detection an handover schemes are 
> essenttial for base Mobile IPv6 Operation, which means, the 
> protocol operation needs exploiting L2 triggers/hints. And  MIPv6 
> implementors use L2 triggers/hints in a confusing way, if not at all.

While the usage of hints may be unavoidable in some DNA schemes, 
there will still be some systems where it is not possible to 
the the kind of hints you desire.  It would be short-sighted to 
design systems which only work if information from the link-layer
is reliable and available. 

> We could be ping-ponging betwwen these two groups for years.

I really hope not, but MOBOPTS isn't necessarily a place for 
killing ideas off to (no matter what some people say!).   
Our research team has (voluntarily!) submitted some ideas there
for further discussion recently and gotten useful feedback.

I don't even mind if people winnow their existing work down to
a problem statement which is DNA centric.
It may be that there's a chance that we'd think it out-of-scope
anyway, but that's because the WG scope is very narrow.

If the work is clear input into one of the documents on the DNA
charter, that may change things.

We're only likely to produce 4 documents this year (optimistically).
so focussing on how the vertical handover/polimand work can
directly help those is more immediately useful.

As Pekka said, this may mean leaving MIPv6 specific parts to
MIP6WG or MOBOPTS.
 
Greg

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

---

From: "Stefan Aust" <[email-masked]>
Date: Tue, 2 Mar 2004 11:31:07 +0100

Dear Greg,
dear all.

Thank you very much for your comments regarding the draft. We hope that
we can support the current work items in the DNA WG with our draft 
submission and we are grateful for the ongoing discussion concerning L2/L3 
interaction. 

However, in this draft it is described how the interaction of L2/L3 can be
used to establish handovers based on a policy. We will think about to extend

this draft in a way that is more independent of MIP. Proactive handover 
decision can be appropiate to force Neighbor Discovery/Neighbor
Unreachability Detection 
for DNA, for instance. However, we think that it might be important to
inform the MN 
on the fastest way that the MN will change its point of attachment. The
first 
implementation of POLIMAND has shown that lossless handovers can be provided
by using 
L2 information for vertical handovers in overlay networks.

Kind regards,
Stefan

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> Gregory Daley
> Gesendet: Montag, 1. März 2004 16:19
> An: NJEDJOU Eric FTRD/DMR/REN
> Cc: Pekka Nikander; Stefan Aust; [email-masked]; 
> Carmelita Görg; Niko A. Fikouras; Cornel Pampu; Dna; Greg 
> Daley; [email-masked]
> Betreff: Re: RE : [DNA] Current IETF-Draft version - POLIMAND
> 
> 
> Hi,
> 
> While the drafts being discussed are principally interested 
> in handling multiple connectivity scenarios associated with 
> about link layer interactions (polimand may talk about policy 
> instead, Of course, it is always hard to standardize policy).
> 
> for MIPv6 would be useful or not (or whether there's much 
> difference except the movement detection algorithm) I don't know.
> 
> procedures when a host has multiple interfaces, that may be different.
> 
> Any decision or action based on this the configuration 
> detection is starting to push into uncomfortable areas as far 
> as DNA's tight charter  is concerned.  Perhaps this is 
> analogous to the reasoning used in MIP6?
> 
> standardized in the previous paragraph. There's already been 
> some out-of-band feedback to DNA that we should avoid delving 
> into standardization of L2 oriented mechanisms.
> 
> design systems which only work if information from the 
> link-layer is reliable and available. 
> 
> Our research team has (voluntarily!) submitted some ideas 
> there for further discussion recently and gotten useful feedback.
> 
> I don't even mind if people winnow their existing work down 
> to a problem statement which is DNA centric. It may be that 
> there's a chance that we'd think it out-of-scope anyway, but 
> that's because the WG scope is very narrow.
> 
> If the work is clear input into one of the documents on the 
> DNA charter, that may change things.
> 
> We're only likely to produce 4 documents this year 
> (optimistically). so focussing on how the vertical 
> handover/polimand work can directly help those is more 
> immediately useful.
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 1 Mar 2004 16:02:08 -0800

I hesitate to even bring this up, but there's a long history in the IETF of
trying to figure out where to do this kind of work. We've been working on
multiple interface (vertical) handover, handover optimization, and such in
MIP and Seamoby for over three years. There are some experimental protocols
(CARD, CTP, FMIP, HMIP) approaching publication, but they still need a lot
of work before they are ready for deployment. The effort has been hampered
by a lack of impending product or deployment pressure. IETF does not
function well when a particular technology does not have a group of vendors
and network operators behind it who need interoperability for their product
or deployment, and that has been the case for this particular technology.

The result is that the work has been moved to the IRTF MOBOPTS research
group, and I would advise that any proposals be taken there.

            jak

----- Original Message ----- 
From: "Gregory Daley" <[email-masked]>
To: "NJEDJOU Eric FTRD/DMR/REN" <[email-masked]>
Cc: "Pekka Nikander" <[email-masked]>; "Stefan Aust"
<[email-masked]>; <[email-masked]>; "Carmelita Görg"
<[email-masked]>; "Niko A. Fikouras" <[email-masked]>;
"Cornel Pampu" <[email-masked]>; "Dna" <[email-masked]>;
"Greg Daley" <[email-masked]>; <[email-masked]>
Sent: Monday, March 01, 2004 7:19 AM
Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND