Subject: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Aug 2003 10:03:20 -0700

Folks,

This email is to confirm the concensus at the IETF 56 meeting to proceed toward
completing the Seamoby work and closing the Working Group. This email also
advances proposals for a couple of other issues that were not discussed at the
meeting but are required to close out Seamoby.

CARD:
      - Drop draft-ietf-seamoby-card-requirements-02.txt.
      - Take draft-ietf-seamoby-card-protocol-01.txt to Experimental rather than
         Proposed Standard
      - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD information on
        AR-MN interface. Consult with FMIP draft editor about best way to do
this..
      - Complete protocol on AR-AR interface that will support both learning
based
         and server based approaches.
      - Protocol design complete by IETF 57 in Vienna.

CT:

    - Drop draft-ietf-seamoby-ct-reqs-05.txt.
    - Take draft-ietf-seamobyh-ctp-01.txt to Experimental rather than
       Proposed Standard.
    - Complete protocol design by IETF 57 in Vienna.

We did not discuss the following issues, here they are with some suggestions:
about how to resolve them

    - What to do with draft-ietf-seamoby-cardiscovery-issues-04.txt.
       Since a clear statement of the problem is necessary for formulating
       the research questions, continue to advance this document to
       Informational.

    - Relationship between CT and FMIP. Since the purpose of
      Seamoby is to support fast handover, focus on a design
      that integrated well with FMIP signaling.

Discussion?

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 20:27:24 +0200 (EET)

Hi,

maybe I'm out of line here, but I would really like to see that CARD and
CT are not tied directly to (F)MIP. The reason is that there are other
ways to support mobile hosts, where you don't need (F)MIPv4/6. You could
use SIP to find the initial location of the user (if needed) and then use
a local mobility management mechanism to support the mobility within the
local domain. You would still need CARD and CT to enable seamless
mobility, though.

Regards,
Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 20:27:24 +0200 (EET)

Hi,

Regards,
Jukka

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 21 Mar 2003 10:55:15 -0800

Hello Jukka,

> local domain. You would still need CARD and CT to enable seamless

Could you elaborate what you mean by "local mobility management
mechanism" ?

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 21 Mar 2003 10:55:15 -0800

Hello Jukka,

Thanks,

-Rajeev

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 21:11:45 +0200 (EET)

Hi,

examples such as BCMP, Cellular IP, MER-TORA. Especially BCMP has been 
shown to be quite good for supporting local mobility, and it is one of the 
protocols that does not expect MIP to be available. May be I'm just an 
academic that has no sense of the "real world", but restricting CARD and 
CT to a spcecific mobility management mechanism (MIP) sounds somewhat 
narrow minded...

Regards,
Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 21:11:45 +0200 (EET)

Hi,

Regards,
Jukka

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Aug 2003 11:14:39 -0700

Jukka,

For CARD, the problem is that if the FMIP prehandover information signaling is
not specified as the vehicle, CARD must specify a separate protocol that
performs a substantially identical function. This is in direct violation of RFC
1958 Principle 3.2 (and I quote):

       3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

Using the FMIP prehandover signaling does not mean that FMIP must be used for
handover. One could use GPRS or any other protocol for that purpose.

With respect to CT, its a bit murkier, since the proposal is to directly use the
FMIP handover signaling (as opposed to the prehandover signaling) as transport
for the context and for the signaling from the Mobile Node to trigger the
context transfer.
One way we could finesse this is to define CT as an extension mechanism, then
define in an appendix how it would apply to FMIP. This would avoid the problem
of tying the base design to FMIP, while still ensuring it would work well with
FMIP.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 21 Aug 2003 11:14:39 -0700

Jukka,

            jak

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 21:25:16 +0200 (EET)

Hi,

your proposal is what I was looking forward to see: a generic architecture 
and protocol and then an example use case with FMIP, for example.

Regards,
Jukka

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 21 Mar 2003 21:25:16 +0200 (EET)

Hi,

Regards,
Jukka

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 22 Mar 2003 12:13:16 -0800

FMIP PrxyRtSol/SolPrxyRtAdv are just for delivering the CAR information
after discovery.
In Dycard, the discovery requires messages between MN and AR for delivering
the IP address of the previous AR to the current AR. This is beyond the
purpose of FMIP PrxyRtSol/SolPrxyRtAdv messages.
I wonder whether the proposal is to extend the semantics of FMIP
PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages between AR
and MN for CARD.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 22 Mar 2003 12:13:16 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Aug 2003 20:57:47 -0700

Extending the semantics is the proposal. Or, alternatively, delivering the
learning-based information via a RS.

If it turns out not to be a good match, then an additional message could be
added for the learning based approach.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 22 Aug 2003 20:57:47 -0700

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 23 Mar 2003 07:37:07 -0800

It was agreed to make the CARD messages piggyback-able in the past.
Then the CARD messages could be transported even on top of other messages
than FMIP messages.
Also we don't have to worry about how FMIP will turn out in the future. Or
the FMIP designers don't have to worry about the semantics change required
by the CARD protocol.
Piggybacking wouldn't be better than tight-coupling with FMIP?

Eunsoo

> > > This email is to confirm the concensus at the IETF 56 meeting to
proceed
> > toward
> > > advances proposals for a couple of other issues that were not
discussed at
> > the
> > >       - Use FMIP PrxyRtSol/SolPrxyRtAdv as transport for CARD
information
> > on
> > >         AR-MN interface. Consult with FMIP draft editor about best way
to
> > do

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sun, 23 Mar 2003 07:37:07 -0800

Eunsoo

proceed
discussed at
information
to

---

From: "James Kempf" <[email-masked]>
Date: Sun, 24 Aug 2003 09:21:08 -0700

Defining the CARD messages as generalized ICMP options for RFC 2461 and
associated extentions is acceptable. I presume this is what you mean by
"piggybacking".

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sun, 24 Aug 2003 09:21:08 -0700

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 24 Mar 2003 12:34:18 -0800

James,

Right.The design team proposed that the specification allows two options:
piggybacking as ICMP options and stand-alone messages.
I think this is a good approach that can satisfy many things.

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 24, 2003 8:21 AM
Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

> > > If it turns out not to be a good match, then an additional message
could
> > be
> > > > PrxyRtSol/SolPrxyRtAdv for all the necessary signaling messages
between
> > AR
> > > > > completing the Seamoby work and closing the Working Group. This
email
> > also
> > > > >       - Take draft-ietf-seamoby-card-protocol-01.txt to
Experimental
> > > > rather than
> > > > >       - Complete protocol on AR-AR interface that will support
both
> > > > learning
> > > > >     - What to do with
draft-ietf-seamoby-cardiscovery-issues-04.txt.

---

From: "Eunsoo Shim" <[email-masked]>
Date: Mon, 24 Mar 2003 12:34:18 -0800

James,

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: "Eunsoo Shim" <[email-masked]>; <[email-masked]>
Sent: Sunday, August 24, 2003 8:21 AM
Subject: Re: [Seamoby] Confirmation of Concensus on Completing Seamoby Work

could
between
email
Experimental
both

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Mar 2003 11:20:19 -0800

So that there is no misunderstanding...

I don't think having a new ICMP message is necessary. That's what I meant by the
"one protocol" statement in RFC 1958. If there is a protocol, such as FMIP
PrxyRtAdv/SolPrxyRtAdv, that performs a particular function, then don't invent
another one. For learning-based information distribution, SolRtAdv would work as
well.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Mon, 24 Mar 2003 11:20:19 -0800

jak