Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-tsirtsis-dsmip-problem-0 0.txt

From: Soliman Hesham <[email-masked]>
Date: Sun, 24 Aug 2003 08:03:11 -0400

> > George and I think it's worth solving because of the 
 > > problems listed in the draft. If you try to deploy 
 > > MNs on a large scale, using a wireless network, the 
 > > problems in the draft become quite serious. There
 > > are two ways to avoid them with current standards:
 > > 
 > > - Avoid IPv6 deployment
 > > - Move to IPv6-only networks
 > > 
 > > The latter is not going to happen this decade. I'm
 > > sure we don't want the first bullet to happen either.
 > 
 > The draft lists several problems, some of which I don't 
 > agree with, some 
 > of which I think can be solved with other approaches, and 
 > some of which I 
 > agree may be potential issues but which I don't see really 
 > huge problems.
 > 
 > I think these separate problems have to be teased out from 
 > one big lump 
 > leading to your conclusion.
 > 
 > >  > I guess I don't understand the problem, then.
 > > 
 > > => I'm happy to help. If you can pick on specific sections
 > > in the problem statement draft that might help us 
 > > move forward.
 > 
 > I had a closer look at parts of it, and I'll be sending some 
 > comments 
 > shortly.

=> I'll look forward to your specific comments then.

 > > If the MN generates a 6-to-4 address then an IPv6 node contacted
 > > it using that address after the MN has left the home network, how
 > > does the HA forward those IPv6 packets to the MN? 
 > 
 > Easily.  Note that those are *NOT* IPv6 packets.  They're 
 > proto-41 IPv4 
 > packets :-).
 > 
 > It's double encapsulation, but hey.. it works and is trivial!

=> As I described earlier, double encapsulation is one 
option, there are others. The aim is not necessarily 
to provide a trivial solution at all cost (it's obviously
your aim but not mine). If you read the mipv4 solution
(draft-tsirtsis) you can see that it's possible, but there
is a need for a more BW-efficient solution.

 > 
 > > The same goes for traffic sent from the MN using 
 > 2002:HADDR_v4::/48. 
 > 
 > Works equally well, as above.

=> No it doesn't. How does the MN reverse tunnel to the
HA? MIPv4 does not assume reverse tunnelling.

 > > => You could replace 2002:.... with any other prefix because as 
 > > I explained above it doesn't do anything for us. 
 > 
 > Yes, it fixes the problem altogether, see above.

=> Not the reverse part.

 > > It doesn't setup
 > > a tunnel between the MN and the HA in any way.
 > 
 > For some weird reason, you keep having this fixation that 
 > tunnel MUST BE 
 > between MN and the HA.  There is *NO* reason for that.  The 
 > tunnel can be 
 > to whatever box in the network, as long as it provides IPv6 support.
 > 
 > However, it could very easily be the HA too, just by being 
 > the 6to4 relay 
 > or the (somehow) configured tunnel's endpoint.  But that's 
 > certainly *not* 
 > a requirement. 

=> I don't understand how you assume that 6-to-4 provides
bidirectional communication... This is why I think the HA
is a good TEP because it's there, doesn't assume 6-to-4
relays, and doesn't assume that the CNs have 6-to-4 addresses.

 > > if you're saying that you could have a configured tunnel inside
 > > the HA to tunnel IPv6 to the MN's IPv4 _home_ address which then
 > > gets tunneled to the MN's IPv4 care-of address (the MIP part)
 > > then yes this is possible and it is explained in the draft
 > > that George announced on the list.
 > 
 > Yes, that's exactly the possibility.  It needs to go to the problem 
 > statement (if you keep considering there being a problem) to 
 > be taken 
 > seriously.

=> I don't think the problem statement should consider solutions.
In fact, perhaps we need to change the recommendations section
to indicate that a gradual transition based on existing standards
is needed without being more specific. 

 > 
 > > But there is a more 
 > > BW effifcient scenario that would require some assistance 
 > > from the FA. Both options are explained in the solutions
 > > draft (MIPv4 one) that George sent to the MIP mailing list.
 > 
 > Bandwidth efficiency is just ONE trade-off here.  

=> Ah, one important trade-off! If you ask anyone deploying
or working with a WWAN how important BW is, they'll
choose it over simplicity anytime.

    What I'd 
 > like is that
 > the problem statement would list all the issues so that the 
 > readers could
 > have better idea of the tradeoffs.

=> I'll look forward to specific comments ;) 

 > 
 > Actually, maybe the document should be called "goals" or 
 > "requirements", 

=> If it were a requirements doc we would call it so, but 
we were asked to describe the problem, that's why it's 
a problem statement. 

 > not a problem statement, because "problem statement" doesn't 
 > give enough 
 > coverage on other tradeoffs of finding a solution.

=> It's not meant to. It's a problem statement. By all means,
others are welcome to look into requirements ...etc

 > > => This is a binary transition mechanism :) 
 > > You're basically saying that "today V4 is used, tomorrow
 > > we will have dual stack networks and we can retire MIPv4."
 > > Hmmm...not that simple unfortunately because there is more
 > > than one network and there is a different "tomorrow" for each
 > > of those networks. So what is going to happen is that we will
 > > have v4-only and dual stack networks at the same time. 
 > > 
 > > Also, we can't just "retire" MIPv4 unless there is a flag
 > > day. So we can phase it out. From the two solutions drafts
 > > that we have (second one coming soon), you could conclude
 > > that we assumed the following scenario:
 > > 
 > > 1. Use MIPv4 (present)
 > > 2. Extended MIPv4 to allow for IPv6 home address (near future)
 > > 3. Extended MIPv6 to allow for v4 home addresses (future)
 > > 
 > > 2) and 3) can coexist (i.e. in different MNs). 
 > > That's a more likely transition IMHO. 
 > 
 > Sure, but there are multiple problems in your problem 
 > statement.  I agree 
 > with about one of them (to an extent :-) -- the double signalling.
 > 
 > It's all about tradeoffs.  As long as things work to some 
 > extent, we can 
 > accept a bit more overhead, a bit more unoptimized 
 > connectivity, etc.

=> Who is "we"? Different operators have different requirements
for different types of networks. Optimised signalling over
a wireless link is crucial. Optimised mobility is not an option, 
it's a must for any serious wireless operator. Minimal overhead 
is also a must and won't be tolerated by a WWAN operator. 

Hesham

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Aug 2003 17:04:28 +0300 (EEST)

> is a need for a more BW-efficient solution.

Obviously, the problem statement should elaborate why double encapsulation 
does not solve the problem.

> HA? MIPv4 does not assume reverse tunnelling.

It has worked just fine for me w/ Dynamics 
(http://www.cs.hut.fi/Research/Dynamics/), AFAIR.

Are you saying that mobile nodes do not tunnel back to the HA themselves, 
just (optionally) rely on the FA's doing it?

> relays, and doesn't assume that the CNs have 6-to-4 addresses.

If you're worried about bidir communication, all you have to do is to give 
the HA also a 6to4 address: then 6to4 gives you bidirectionality as well.
 
> is needed without being more specific. 

You don't have to consider solutions.  What I'm saying is that it would be
useful to try to phrase the _problem statement_ so that it excludes
certain solutions you do not consider appropriate (instead of just
silently rejecting them).  I.e., this seems to indicate that the problem 
statement is not worded as well as it could be.

> choose it over simplicity anytime.

You may have different WWAN's in mind, but I disagree.  For example 802.11 
deployments have ample capacity, and it is much more important to have 
simple solutions which require no upgrades to network components or mobile 
nodes.
 
> we were asked to describe the problem, that's why it's 

Requirements can also describe a problem, but additionally those give a 
better idea how to evaluate solutions to the problem.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings