Subject: [Mip6] Agenda for MIP6 at IETF58

From: [email-masked]
Date: Tue, 4 Nov 2003 10:26:12 -0600

MIP6 (Mobility for IPv6 WG) Draft Agenda (version 2)
---------------------------------------------------

MONDAY, November 10, 2003 
1530-1730 Afternoon Sessions II

CHAIRS: Basavaraj Patil <[email-masked]>
        Gopal Dommety	<[email-masked]>

Agenda:

1. Preliminaries	10 Mins			Chairs
   - Minutes
   - Agenda bashing

Document status:
Mobile IPv6 base specifications are in the RFC editors queue. IANA is
currently in the process of allocating type numbers, error codes
etc. to the I-D.

2. MIPv6 MIB		15 Mins			Glenn Keeni
   I-D: draft-ietf-mip6-mipv6-mib-00.txt

The intent of this agenda item is to update the WG on ths current
status of the MIB work and to seek input from WG community.

3. MIPv6 Remote interop testing	 15 Mins	T.J Kniveton/Samita C.
   I-D: draft-kniveton-mipv6-remote-testing-00.txt

Interop testing of the Mobile IPv6 protocol will ensure that the specs
are unambiguous. It will also enable the discovery of problems/issues
which will then form the basis for revising various features that are
present in the base spec. This I-D proposes the creation of a MIPv6
testbed that allows interop testing remotely.

4. Inter Home Agents Protocol (HAHA)  10 Mins	Ryuji Wakikawa
   I-D: draft-wakikawa-mip6-nemo-haha-00.txt

Home agent reliability is a part of the MIP6 charter. This I-D
explores a possible solution. The intent is to seek WG support for
this item.

5. Extension to Sockets API for Mobile IPv6	15 Mins	S. Chakrabarti
   I-D: draft-chakrabarti-mobileip-mipext-advapi-01.txt

This is a combined effort by the MIP6 and IPv6 WGs. The specification
will be worked in in the MIP6 WG. This agenda slot is intended to
present an update on the Sockets API for MIPv6.

6. Route Optimization hint option	10 Mins		K. Shima
   I-D: draft-shima-mip6-rohints-00.txt

While RO is a part of the base specification, there are no real
guidelines when RO should be triggered. This agenda slot will discuss
the problem and provide some hints on when RO is optimal.

7. Multi-interfaced/Multi-homed MNs - Problem statement discussion  
					      10 Mins T. Ernst
   I-D: draft-montavont-mobileip-multihoming-pb-statement-00.txt

This agenda slot is intended to discuss the problem statement stated
in the I-D and to solicit WG input regarding how important this work
is and if MIP6 WG should deal with it.

8. Roadmap for WG	10 Mins			Chairs and ADs

This agenda item will discuss next steps for the WG especially in
terms of what happens between now and IETF59.

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Nov 2003 12:21:11 -0500

Hi.

> explores a possible solution. The intent is to seek WG support for

This ID seems to be mostly a solution. Before looking at solutions, it
would be good to focus on getting agreement on a problem
statement. Once there is agreement on the problem statement, looking
at solutions makes sense.

Has the WG already agreed on a problem statement? "home agent
reliability" is a pretty vague description. :-)

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Nov 2003 10:45:35 -0800

hi Thomas,

> reliability" is a pretty vague description. :-)

we could spend more time on describing the actual problems
that this ID is trying to solve. we can avoid spending a
lot of time on the solution.

infact the ID is kind of broad. the problems that the ID
has solutions for

1. Home Agent reliability
2. Load sharing (ability to pick and switch Home Agents)
3. Binding Cache synchronization between Home Agents
    (we had a long discussion in the Mobile IP mailing list
     earlier on a mobile node which forgets which Home Agent
     it was registered when it was switched off and picks
     another Home Agent when it comes online a few minutes
     later. the binding with the new Home Agent cannot
     succeed until the binding on the old Home Agent expires.
     Binding cache synchronization helps avoid this).
4. MIPv6 currently restricts all Home Agents serving the
    a home prefix to be on the same physical home link.

Vijay

---

From: Thomas Narten <[email-masked]>
Date: Tue, 04 Nov 2003 14:13:52 -0500

Hi Vijay.

> lot of time on the solution.

That would be preferable, IMO.

> 1. Home Agent reliability

Please expand.

> 2. Load sharing (ability to pick and switch Home Agents)

transparently to the MN? Or does the MN need to know?  and does this
restrict backup HAs to be on the same link? And who needs to initiate
a switch? Totally under the HA's control, or should MN be involved?

>      Binding cache synchronization helps avoid this).

It does seem like there are some issues lurking there...

>     a home prefix to be on the same physical home link.

yep. So how much do folks want to relax this distinction? Must be
"nearby" (which I'm deliberately leaving vague, but presumably means
within same organization where all the machines and infrastructure are
under the same admin). Or, backup HAs can be located anywhere? (The
former might have less complex solutions.)

Thomas

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 04 Nov 2003 11:35:03 -0800

>>1. Home Agent reliability

sure. Home Agent goes down. MN has no indication. you have
a big problem. with the HAHA protocol, another Home Agent
can take over (because binding cache is synchronized) and
the MN can be made to switch Home Agents (there are messages
for this).

> a switch? Totally under the HA's control, or should MN be involved?

this is all open to discussion. the HAHA draft currently
has a solution for this. but we dont have to talk about
the solution in the draft yet.

> It does seem like there are some issues lurking there...

:)

> former might have less complex solutions.)

this is something even Pascal, Ryuji and I couldnt agree
on. :)

I leave it to the WG to decide on which of the above
problems (if any at all) should be solved in the MIP6 WG.

Vijay

---

From: Thomas Narten <[email-masked]>
Date: Wed, 05 Nov 2003 09:59:41 -0500

> the MN can be made to switch Home Agents (there are messages

So, the requirement seems to be HA failover.

> the solution in the draft yet.

I suspect that there are a bunch of tradeoffs here. It would be
advantageous if everything is transparent to MNs (i.e., no protocol
changes). But what are the limitations? Are some of them significant?
Talking about some of this (in fairly general terms) might be useful.

> this is something even Pascal, Ryuji and I couldnt agree

Good reason for the WG to discuss then!

Thomas

---

From: ken nagami <[email-masked]>
Date: Thu, 06 Nov 2003 01:03:17 +0900

Hi Vijay and all,

 >this is something even Pascal, Ryuji and I couldnt agree

I would like to relax the restriction for HA.
Even if ISP which HA connects gets trouble, MN needs to communicate with CNs.
Therefore, I want to put HAs on different ISP.
I think it need to relax the restriction.

Regards,

Ken Nagami

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 15:14:47 -0800

> So, the requirement seems to be HA failover.

well, the charter says

     - Improving home agent reliability: in the event of a home agent
       crashing, this would allow another home agent to continue
       providing service to a given mobile node.

> Talking about some of this (in fairly general terms) might be useful.

agree that there would be tradeoffs. the MN continues to send
reverse tunneled packets to the Home Agent which just crashed.
it would be good if the MN can switch Home Agents. OTOH, if
the Home Agent, which took over, can proxy the address of the
Home Agent which crashed, then maybe we can do it transparently.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Thu, 06 Nov 2003 11:17:53 +1100

Hi Vijay,

Vijay Devarapalli wrote:
[cut]
> Home Agent which crashed, then maybe we can do it transparently.

One mechanism which could be used for this, is
if the advertised HA addresses were VRRP instances,
and the hosts exchanged information about binding
caches on other addresses.

Obviously, we're not up to talking about mechanisms yet,
but it seems like this is a feasible thing to swap
HAs with little or no MN knowledge.

Greg

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 05 Nov 2003 17:13:52 -0800

> caches on other addresses.

the solution should also work if the multiple Home Agents
are not on the same physical link. VRRP, I think, requires
all routers to be on the same link.

Vijay

---

From: Greg Daley <[email-masked]>
Date: Thu, 06 Nov 2003 12:37:48 +1100

Hi Vijay,

> all routers to be on the same link.

If the routers aren't on the same link, it is likely
(except if we're talking multilinks), that the home
network is on an isolated interface, which can be moved
between the two networks exclusively by routing.

In this case VRRP is not needed.

The issue was that other (non-HA) hosts could be on a shared
network, in which case it is important not only to have IP
routing working correctly, but local delivery (i.e. Neighbor
Discovery).  In this case, VRRP provides advantages which
remove some requirements for IP address and NC update
(maybe NA:O=1 can do almost as well, though).

Greg

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Sun, 09 Nov 2003 17:43:14 +0900

Hi,

 >    I-D: draft-ietf-mip6-mipv6-mib-00.txt

If you haven't already downloaded and read the draft -
the latest version of the draft is available at
     http://www.cysol.co.jp/contrib/draft-ietf-mip6-mipv6-mib-01.txt

If you do not like reading the draft and are just keen to see what
types of dials and knobs are being proposed in the MIB - a diagram
showing the mipv6MIB in a hierarchical manner is available at

     http://www.cysol.co.jp/contrib/mipv6MIB.Tree

Cheers

Glenn