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

[Soliman Hesham <H.Soliman@flarion.com>]

 > > 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