Subject: [Mip6] IETF59: Minutes of MIP6 WG meeting

From: [email-masked]
Date: Fri, 2 Apr 2004 15:22:16 -0600

Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59
----------------------------------------------------------

Meeting notes courtesy of: Behcet Sarikaya and Glenn Keeni 
(Thank you). 

Monday, March 1 at 1300-1500
CHAIRS: Basavaraj Patil <[email-masked]>
        Gopal Dommety <[email-masked]>

1. Agenda, Bluesheets, Note takers
**********************************

- Some reshuffling of the agenda posted for the WG meeting earlier
  based on prioritization of work items.
- Added Charles Perkins' I-D draft-perkins-mip6-precfgKbm-00.txt to
  the agenda

2. WG Docs status update
************************
Basavaraj Patil

- Base Mobile IPv6 specification moving forward after having been
  stuck with IANA for a long time. Thanks to Jari Arkko for his
  efforts to get the IANA issue resolved. The I-D is headed now to the
  RFC editors queue.

- Revision 01 of the MIB document for MIP6 completed. Intent is to go
  to WG last call mid-April after one more revision. There is also a
  demo of the current MIB implementation by Glenn Keeni for anyone who
  would like to see it.

- The API I-D has received some comments on the list and also
  discussed at Connectathon. Will go to WG LC with the next revision. 

- MIPv6 test suites are at the URL shown in the slides

Gabriel: Has there been a WG LC on Pekka Nikander's I-D
	 <draft-nikander-mobileip-v6-ro-sec-02>?
Raj: Do not remember. But will check and follow up. The intent is to
	 publish this as an informational I-D.

3. Bootstrapping Problem
************************
Presenter: James Kempf <draft-kempf-mip6-bootstrap-00.txt >

- What is dymanic bootstraping? Two things: Dynamically allocating HA
  and Home network prefix discovery, and dynamically setting up an
  IPsec SA between MN and HA.  
  Benefits. Enables wider address assignment choices, Better
  configuration and, Load balancing.

Hesham: Dynamic HA discovery does load balancing, not necessarily
	dynamic HA assignment using AAA.  
James: Agree. AAA based approach supports new business models, allows
	nonsubscriber based access.  
Raj: Bootstrapping should be independent of AAA infrastructure. 
Jari: But we do need something for bootstrapping.
James: One alternative is AAA.
Charlie: Why not use DHCP like mechanism that we have here at the
	IETF-59 venue. Why require AAA? 
Hesham: Should not mandate AAA.
James: Current spec is based on manual keying or IKEv1 SA establishment. 

Francis: Disagreement with statement on statically assigned addresses
	in the slides. But ofcourse it just makes life easier.
	Mobile node does not get the information if the device is
	switched off. [ E.g. renumbering information]. Old info needs
	to be maintained. 
Hesham: The same is applicable in the case MN is un-reachable.
James: Benefits include reduced RTT and others.
       Current support for pushing prefix changes to dormant MNs has
	drawbacks. 
TJ: This problem has been discussed. Renumbering should be kept for
	sometime, dormant mobile has to bootstrap after it wakes up. 
Raj: Bootstrapping not a solution for the renumbering problem.
James: Prefix problem needs to be solved.
James: HA discovery uses ICMP and some ISPs disable ICMP.
Four bootstrapping scenarios. Out of four 2,3 and 4 are of interest.
Conclusion. Dynamic bootstrapping is useful. Current IPsec SA
	mechanism does not allow dynamic bootstrapping.
Greg: Option 2, 3, 4 is of primary scope
James: Disagrees
Greg: Which security assocs we will we use? What are the scenarios being
       considered for bootstrapping? 
Raj: There is a design team that is working on the bootstrapping
	problem. Scenarios and scope will be further clarified
	therein. 

4. HA reliability problem statement
***********************************
Presenter: Ryuji Wakikawa <draft-jfaizan-mipv6-ha-reliability-01.txt>

- HA failure. Home link failure. Failure detection, how an MN detects
  failure. Current base spec is not clear. Service
  interruption. Recovery? Who initiates recovery. IPsec SA
  assoc. establishment. Correct ordering, if HA changes, new HA does
  not know the order.  
- HA reliability is in current milestones, we need a problem
  statement. 

Deng Hui: Round robin load balancing can be used, i.e. redundancy is
     built into the HA machine. Also reliability can be accomplished
     by having a multi-blade server type of machine as the HA.
Gopal. Reliability solution should be built into the
     protocol. Hardware solutions are another approach to reliability.
Raj. Reliability is a WG charter item. Once we have consensus on the
     problem statement and scope we will move to solutions. 
     The problem statement I-D will be made a WG item after obtaining
     consensus on the WG ML. 

5. Dual stack Mobile IPv6
*************************
Presenter: Hesham Soliman <draft-soliman-v4v6-mipv4-00.txt> 

- Problem has been discussed in I-D: draft-tsirtsis-dsmip-problem-02.txt
  and the discussion today is one possible solution
- Problem: MIPv4 and mipv6, IPv4 and IPv6 coexist. If MN uses MIP on
  a dual stack machine and moves. MN needs to have both. Optimisation
  overhead. When both mipv4/v6 are used handover signaling, RO signaling
  needs optimization. Fast handover/LMM signaling. 
- Proposed solution. Allow each protocol to manage mobility, mipv4 to
  handle both v4/v6 HoAs to bind to an IPv4 CoA. 
  Draft is about mipv6 as migration tool. Use tunneling to carry ipv4
  and ipv6 traffic over the same mipv6 tunnel. Extensions needed to do
  this. The details are in the draft. One binding update that binds both
  v4/v6 CoA. Also IPsec SAs.  

James: Have you implemented? 
Hesham: no.
James. It sounds complicated. IPv6 stack deals with v4
       addresses. 
Hesham: Not really.
Pascal: What happens if there are NATs? 
Hesham: We do not deal with NAT traversal.
Greg: Are we talking of static or dynamic allocations, Dynamic
      allocation of MIpv4 and static allocations for MIPv6 ? 
Hesham: Bind the HoAV(4 or,6) to my CoAV(6 or V4). (Dual is not MIPv6
	or MIPv4 it is IPv4 or IPv6) 
XYZ: Mipv6 node makes 6to4 address, would'nt that be easier? 
Hesham. We do not assume that the visited network will provide anything,
	e.g. 6to4 relay.  Create dualstack bindings in mipv6. we need
	extensions to mipv6. 
XYZ: NTT runs IPv6 worldwide network. MIPv6 HA can have tunnel server,
     v6/v4 tunnel, MN in IPv4 network. Tunnel server is known and
     exists, why not use it?  
Henrik: Mipv4/v6 to setup these tunnels makes sense. There are
	commercial deployments.  
Raj: There is a bar bof tonight at 10pm to discuss this topic further.
Pascal: Which mobility solution to use?
Raj: We need one mobility solution. It will be mipv4 or mipv6. So this
     draft is saying use only mipv6.  
Pascal: Why IETF is proposing two mobility solutions?
Raj: You have a solution for IPv4 and another one for IPv6. Its upto
     you which one you implement/deploy.

6. Issues with firewalls
************************
Presenter: Franck Le <draft-le-mip6-firewalls-00.txt>

- Issues listed in presentation.

James: Generic problem with firewalls and ESP. Solution is nsis. 
Jari: Is problem nat or firewall? The solution depends on what. There
      is nat traversal for IPsec. 
Frank: Issue is with firewalls. Its the reachability aspect.
Hesham: How come you assume BU and BAck will go thru?
Franck: We assume creating state in the firewall. Without using ESP. I
	am assuming ESP issue is resolved some other way.  

Raj: Problems described here applies to GPRS/UMTS networks as well because
     GGSN has packet filters similar to firewalls. Xiabao Chen has an
     I-D that discusses these issues. The I-D is:
     draft-chen-mip6-gprs-00.txt 
     Franck's draft and Xiabao's drafts are informational documents
     that are useful from MIP6 deployment perspective.. 

Question to WG: Firewall issues: Do they need to be documented? Maybe
	 advanced as informational RFC? Go back to ML and discuss. 

7. NAI Option
*************
Presenter: Kent Leung <draft-patel-mipv6-nai-option-01.txt>

James: There is a shared secret key between the HA and MN. We need to
       have a design team and do things bottom-up instead of
       pieces. This relates to the bootStrap option. Approximately 3
       persons have read the draft. 
Kent: Yes some issues are related to bootstrapping. 
Raj:  The proposal is to use NAI 
Kent: There is infrastructure that utilizes NAI. 
Alper: There are other identifiers, like FQDN, opaque names. 
Raj: AAA mechanisms deployed today indicate that NAI is a good option. 
Charlie: NAI in mipv4 is good because IPv4 addresses were not unique,
       but in MIPv6 they are unique. Why not use network prefix? Why
       shouldn't we take a network address and use it as an
       identifier?

8. Authentication Option for MIP6
*********************************
Presenter: Kent Leung <draft-patel-mipv6-auth-protocol-01.txt>

-  MN-HA authentication function, using NAI for identifying MN. AAA
   servers identify clients using NAI. Some mipv6 modifications are
   proposed.  

Raj: Alternate key mechanisms should not weaken security. BU is
     secured by somethingelse not by ipsec.  
James:  Key distribution. IKE for key distribution. Draft should talk
     about a specific key distribution.  
Raj:  This draft assumes shared keys but their distribution is not an issue
     for this draft.  
Gopal: Alternative authentication should talk about key distribution?
Alper: We should not require additional signaling on MIPv6 that does
     not exist. 
Charlie: Base MIPv4 replay protection. We can have better key
     distribution schemes as time goes on. So requiring key
     distribution may not be a bad idea. Key distribution can be
     handled later and or orthogonally.

9. AAA Problem Statement
************************
Presenter: Hiroyuki Ohnishi <draft-ohnishi-mip6-aaa-problem-statement-00.txt>

Raj: Integration of MIPv6 with AAA. Additionally AAA can be used for
     bootstrapping. The AAA WG decided that it is upto mipv6 WG to
     determine if a MIP6 AAA App is needed.  
Hesham: It does not look like an integration.
John: Another WG like AAA can get work from MIPv6 WG if mipv6 wants
     it. MSAAA can be done in MIPv6 and then diameter mipv6
     application  can be done at AAA WG. 
Jari: Deployments that have AAA and MIPv6 requiring new things at link
     and netwoprk layer like on 802.11 networks we need to be
     careful. 
Raj: This should be an option.
Pete: Differentiate access authentication and the use of mipv6.
Charlie: Why not use the AAA solution for MIPv4 for MIPv6 also?
Raj: Not directly mappable. Since there does not exist the FA.

10. Binding Update Backhauling      
******************************
Presenter: Wasim Haddad <draft-haddad-mipv6-bub-01.txt>

- Bub reduces signalling. BUBC message is used to agree on bub
  mode. 

Eric. In the case where the RR test is done the first time: The first
      time is it secure? Man in the middle attacks can be done. Bub has this
      problem, maybe it is  more secure but not any more secure.  
Raj. But Security relies on the esp tunnel between HA and MN. 
Jari. This is already done in the base spec.
Raj. Not enough time to discuss further.
    The proposal here is an enhancement to Route Optimization when
      two end-points are  mobile. Does this I-D address any security issue
      that is inherent within the the current RR scheme?

11. Optimizing Mobile IPv6 
**************************
Presenter: Wasim Haddad <draft-haddad-mipv6-omipv6-01.txt>

Jari: Defining optimization is great. DF RR is good, man in the middle
      will have only a limited term effect. OMIPv6 might increase the
      times of effect. 
      Jari feels that there are issues with such an approach. 
Erik. Agrees with Jari. Latency optimizations are OK but it should
      like compromise security. Completely getting rid of coti/cot
      messages not a good idea.  

Attendee: Bub and omipv6 looks same, what is the difference?
Haddad. Bub is for one end point. And it has bubc message.

---------------------------------------------------------

With time running out, Raj provided pointers to Charles Perkins' I-D
about RO with preconfigured keys. Discussion of this will be taken up
on the list.

Gopal summarized next steps for the WG.

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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 23 Apr 2004 00:16:40 +0900

Hello Jahanzeb and all.

What is the status of draft-jfaizan-mipv6-ha-reliability?
It seems there are any comments on this draft.

To WG Chairs
Is it time to make it WG doc and move on a solution?

regards,
ryuji

> Meeting minutes of Mobility for IPv6 (MIP6) WG from IETF59

  <SNIP>

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Thu, 22 Apr 2004 12:15:39 -0500

Hi Ryuji,

chairs have agreed to make it a WG draft. They are going to call for
consensus and
then things will go on from there.

JF
----- Original Message ----- 
From: "Ryuji Wakikawa" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, April 22, 2004 10:16 AM
Subject: HA nreliability Problem Statement [was Re: [Mip6] IETF59: Minutes
of MIP6 WG meeting]

---

From: Gopal Dommety <[email-masked]>
Date: Thu, 22 Apr 2004 12:17:19 -0700

Ryuji and et all,

HA reliability can be accomplished by hardware redundancy or by protocol work.
  do we have a consensus that protocol work is needed at this present time?
Do you think we should ask the people who have HA implementations to express
their short term preference?.

Thanks,
-Gopal

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Thu, 22 Apr 2004 17:00:04 -0500

I think that we need protocol work because it is the cheapest and easy to
deploy solution.

Jahanzeb Faizan

----- Original Message ----- 
From: "Gopal Dommety" <[email-masked]>
To: "Ryuji Wakikawa" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, April 22, 2004 2:17 PM
Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59:
Minutes of MIP6 WG meeting]

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 22 Apr 2004 19:17:44 -0700

> their short term preference?.
In my past job, we have developed a MIPv4 HA that is resilient to a single point failure
without the need of any protocol support from MIPv4. If we were developing
MIPv6 then, i don't know why it would not have been possible to do the same thing. Note that
any telco box has to provide high availability for all other protocols running in the box. Just not
for MIP.

-mohan

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Fri, 23 Apr 2004 12:24:42 -0500

comments below....

> MIPv6 then, i don't know why it would not have been possible to do the
same thing.

Actually in MIP6 multiple HAs are supported so there is no single point of
failure problem.
The problem lies in the mip6 protocol itself. These problems are related to
failure detection,
failure recovery, security  etc.. (discussed in our draft
http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt )

Even if we have redundant hardware these problems exists in MIP6. So until
and unless we have
protocol based solution to these problems we can not achieve reliability in
the network.

Thanks
Jahanzeb

----- Original Message ----- 
From: "Mohan Parthasarathy" <[email-masked]>
To: "Ryuji Wakikawa" <[email-masked]>; "Gopal Dommety"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, April 22, 2004 9:17 PM
Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59:
Minutes of MIP6 WG meeting]

> > > > Presenter: Ryuji Wakikawa
<draft-jfaizan-mipv6-ha-reliability-01.txt>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 23 Apr 2004 17:17:41 -0700

]

> http://www.ietf.org/internet-drafts/draft-jfaizan-mipv6-ha-reliability-01.txt )
You are talking about failing over from one home agent to another home agent - where
you are seeing as two separare entities. I was talking about a single home agent - highly scalable,
redundant, carrier grade. It supports failure detection, failure recovery etc. as part of
high availablity so that any other protocol that runs in the box will not suffer from single point failure.
When any componet  fails(control or data plane), the MN does not see any change as all the
control and data state is always kept replicated (this is what your protocol does i think) and the
 home agent is still available. This is taken care of the High-availability software running in the box. I was
 merely pointing out that this is how systems are built today. For example, look at Intels ATCA
(Advanced Telecommunication Computer architecture). Yes, you can build a protocol to do the
 "High availability" part. But i don't see a need for it as i can easily provide all the "High-availability"
 features that you described in the draft,  in the box i described above without any support from MIPv6.

-mohan

> same thing. Note that

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Sun, 25 Apr 2004 02:22:12 -0500

My comments below..

>  home agent is still available. This is taken care of the
High-availability software running in the box. I was
>  features that you described in the draft,  in the box i described above
without any support from MIPv6.

JF>

1. Any "highly-reliable" system is not 100% reliable:

I agree with you that we could have highly reliable system but think it
could not be 100% reliable. There is always
a risk factor involved. Failure could be of any kind ...catastrophic failure
for example.When we talk about HA failure
then it means that HA some how failed, does not matter how reliable it was.

2. Redundant hardware is always supported:

Is there any company which is providing 24/7 service using a single
"highly-reliable" system.
Ofcourse not....the high reliability of the system is there but still it is
going to be backed up by a redundant
system ( active/standby kind of scheme). So my point is that we cannot rely
on a single highly reliable HA.
There should be redundant HAs.

3. Protocol Reliability

We could have all kinds of reliable systems but my point is that when we
design protocols we make
these protocol independent of the underlying hardware and fully reliable and
resilient to any kind of failure
of the underlying hardware. It is done because we want to achieve
reliability in both sides i.e protocol and hardware.
If this would not be true then why IETF came up with VRRPv4 and VRRPv6 which
are now even standards despite
of having all sorts of highly reliable routers ( Cisco routers and others).
So my  concern is why we can't make mip6 reliable ?

4. What's wrong with mip6.

MIP6 provide redundant HAs support but there are problems of failure
detection, failure recovery, failover and there
are security problems too....which need to be solved.

Thanks

Jahanzeb

----- Original Message ----- 
From: "Mohan Parthasarathy" <[email-masked]>
To: "Jahanzeb Faizan" <[email-masked]>; "Ryuji Wakikawa"
<[email-masked]>; "Gopal Dommety" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 23, 2004 7:17 PM
Subject: Re: HA nreliability Problem Statement [was Re: [Mip6] IETF59:
Minutes of MIP6 WG meeting]

> ]
>
>
> > comments below....
> >
> > > In my past job, we have developed a MIPv4 HA that is resilient to a
single
> > point failure
>  home agent is still available. This is taken care of the
High-availability software running in the box. I was
> > > > HA reliability can be accomplished by hardware redundancy or by
protocol
> > work.
> > > >   do we have a consensus that protocol work is needed at this
present
> > time?
> > > In my past job, we have developed a MIPv4 HA that is resilient to a
single
> > point failure

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 26 Apr 2004 21:03:29 +0900

Hello all

Although HA reliability can be achieved by hardware, there are
issues that hardware work can not solve.

The current MIP6 specification supports multiple HAs at a home
link. However, there isn't enough specification to utilize them.
Even, there are issues related to multiple HAs (ex. section 3.5 of pb
statement draft). 

When MN registers to HA1 and suddenly loses HA1, HA1 re-registers to
new HA2. However, HA2 finds DAD failure because HA1 still defends MN's
HoA.  HA2 returns BA with an error code. What can MN do then?

I am not 100% sure, but load-balancing among HAs (section 3.6) is one
thing that hardware work can not solve?!

Hardware work is fine, but it is better to solve HA reliability by 
protocol work. As Hesham noted, a common protocol for Mipv4 and Mipv6
might be good idea.

regards,
ryuji

At Thu, 22 Apr 2004 12:17:19 -0700,

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 26 Apr 2004 09:26:57 -0700

> then it means that HA some how failed, does not matter how reliable it was.
So, you are going to design  a 100% reliable system.  I don't understand your point.
When you are designing such a system, what are your requirements on failure detection
and recovery times ? 

> There should be redundant HAs.
Active/standby is part of a single system. You are trying to provide the
high availability by exposing them as multiple home agents  whereas the one i described
is exposed as a single home agent.

> So my  concern is why we can't make mip6 reliable ?
Then, how about all other protocols that run on the HA box reliable ? You
are looking at MIP6 alone because that's what this working group is chartered to work on. 
But when we build the HA box, anything that runs on the box cannot suffer single point failures.
Hence, MIP6 is *just* another protocol that should b highly available.
Anyway, i don't think i will argue beyond this.

> are security problems too....which need to be solved.
I thought that there were multiple HAs on the home link for load balancing purposes.
Each HA serves a few MNs.

-mohan

---

From: "Jahanzeb Faizan" <[email-masked]>
Date: Tue, 27 Apr 2004 11:57:14 -0500

Hello all,

I would like to share with you my concerns and arguments regarding this consensus.

Hardware solution is not feasible.

Some people are of the opinion that HA reliability problem can be solved by hardware solution. The proposed solution is to provide hardware redundancy below the IP layer in the form of cluster/highly-reliable-one-box/active-standby kind of scheme so that to the IP layer the underlying hardware redundancy seems to be a single HA. I think this solution is not feasible due to following reasons.

1. Physically HA is nothing but a router. What makes router a HA is just an extra software component. Moreover on a single link there are usually several routers/HAs to share the load of MNs. So for a single router why we are introducing  so much complexity and using redundant hardware resources down the IP layer. I think it is not feasible.

2. Will there be any company ready to pay high cost for such routers. Absolutely none.

3. With these solutions we will make mip6 software dependent on the hardware and will restrict the companies to buy such expensive hardwares along with mip6 software for reliable services. This is totally infeasible because companies are going to deploy mip6 over their existing network and hardware.

4. By making mip6 dependent on the underlying hardware we can not achieve world wide deployment of mip6.

5. These hardware solutions are not standards.

Protocol work is the most feasible solution

1. Protocol should be independent of the underlying hardware. Does not matter what the hardware configuration is mip6 should work reliably over any hardware implementation. The problem is in the protocol and the solution should also be based on protocol.

2. Protocol solution is cheaper and easy to deploy.

3. Cisco have highly reliable routers and other hardware solutions but still they came up with protocols based on the VRRP4 and VRRP6 IETF standards. So my concern is if we can come up with VRRP4 and VRRP6 standards for the reliability of routers then why can't we come up RELIABLE MIP6....

4. If some has a hardware solution for the problem then we can not base on just one solution. There are also protocol based solutions.

Thanks for your time.

Jahanzeb Faizan

---

From: Brian Haley <[email-masked]>
Date: Tue, 27 Apr 2004 15:39:36 -0400

Jahanzeb,

Thank you for writing the draft, it has obviously attracted a lot of 
interesting comments lately.

So... taking off my IETF hat and putting on my HP hat...

Speaking for a company that has two solutions for high availability - 
NonStop servers (hardware fault-tolerant), and Clusters (single system 
image software high availability), I have to disagree with your hardware 
"consensus" statements.  We have many customers that pay big bucks for 
this stuff.

Comments follow...

Jahanzeb Faizan wrote:
> _Hardware solution is not feasible._
> __ 
> Some people are of the opinion that HA reliability problem can be solved 
> by hardware solution. The proposed solution is to provide hardware 
> redundancy below the IP layer in the form of 
> cluster/highly-reliable-one-box/active-standby kind of scheme so that to 
> the IP layer the underlying hardware redundancy seems to be a single HA. 
> I think this solution is not feasible due to following reasons.
>  
> 1. Physically HA is nothing but a router. What makes router a HA is just 
> an extra software component. Moreover on a single link there are usually 
> several routers/HAs to share the load of MNs. So for a single router why 
> we are introducing  so much complexity and using redundant hardware 
> resources down the IP layer. I think it is not feasible.

Since noone has deployed MIPv6, how do you come to this conclusion that 
there will be several routers/HAs?

> 2. Will there be any company ready to pay high cost for such routers. 

Absolutely wrong.  Customers that need that level of reliability will 
pay for it.

> 3. With these solutions we will make mip6 software dependent on the 
> hardware and will restrict the companies to buy such expensive 
> hardwares along with mip6 software for reliable services. This is 
> totally infeasible because companies are going to deploy mip6 over their 
> existing network and hardware.

 From what I know about telco companies, they are replacing/updating 
their infrastructures to support new technologies, and none are really 
looking at deploying IPv6/MIPv6 right now on a large scale.

> achieve world wide deployment of mip6.

How did you come to this conclusion?  How long does a piece of hardware 
have to be reliable for - 1 month?  6 months?  1 year?  If I can write 
really good HA software that doesn't crash my hardware I don't see why 
I'd ever need VHAR.  There's also at least one mention in the MIPv6 
draft regarding storing binding information in non-volatile storage - so 
if I can reboot in <10 seconds and re-load my binding cache, who will 
know I had a failure?

> 5. These hardware solutions are not standards.

Who are we to tell our customers how they should deploy their networks?

And this just shows you don't know one of the typical configurations in 
a telco closet - usually a pair of identical systems running in lockstep 
with very specialized software that can recover from a single-system 
hardware failure.

> _Protocol work is the most feasible solution_
> __ 
> 1. Protocol should be independent of the underlying hardware. Does not 
> matter what the hardware configuration is mip6 should work reliably over 
> any hardware implementation. The problem is in the protocol and the 
> solution should also be based on protocol.
>  

Have you done a study to prove this?  Adding another protocol adds 
complexity, which doesn't make deployment easier.  And how do you 
quantify "cheaper"?  I can buy $25 tires for my car, but when they fail 
driving down the highway at 55 and I crash I won't be a very happy 
customer...

> 3. Cisco have highly reliable routers and other hardware solutions but 
> still they came up with protocols based on the VRRP4 and VRRP6 IETF 
> standards. So my concern is if we can come up with VRRP4 and VRRP6 
> standards for the reliability of routers then why can't we come up 
> RELIABLE MIP6....
>  
> 4. If some has a hardware solution for the problem then we can not base 
> on just one solution. There are also protocol based solutions.

Yes, there is always more than one way to solve a problem, just don't 
dismiss hardware-only solutions as they work quite well.

-Brian

---

From: Nobuo Ogashiwa <[email-masked]>
Date: Wed, 28 Apr 2004 11:23:09 +0900

Hello all, 

As we mentioned in the following draft, two different HAs (that might be
different vendor's HA) might be setup in two different ISP's network.
In such case, standard protocol is needed.

http://www.mobilenetworks.org/nemo/drafts/draft-nagami-mip6-nemo-multihome-fixed-network-00.txt

Regards,

Nobuo Ogashiwa