[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on mipv6 application to multihoming [Re: Move forward]
Hi Pekka,
Thank for your comments, they are very welcomed.
>
> Some jetlagged comments.
>
> substantial:
> ------------
>
Initial comment: the idea of the draft is to assess if MIPv6 can be used
unmodified to support multi-homing. A possible conclusion of this
analysis could be that it is not possible, but i am not sure that this
is clear yet.
> ==> The problem is that this mechanism only "works" (for some definition of
> works)
Preserves established sessions perhaps?
> for sessions that are broken over 140 seconds
This is an upper bound. I mean it can be reduced but it can not be
increased. In order to reduce it all that it is needed is to increase
the frequency of HoTI CoTI message exchange. This would indeed increase
the overhead, and cost benefit analysis should be performed in order to
obtain an optimal choice. What it can not be done is to have a longer
detection period. But if i understand correctly you do not have a
problem with this.
Mechanism that provide a faster response to failures have to be included
once that other problems have been solved (like the next one)
> (ie. connection is not
> aborted before that), with the upper bound of 420 seconds.
This is the real problem IMO.The alternative address can only be used
for a limited period (420 secs). Then you have to
perform the RR procedure again to obtain new valid authorization data
that is to be used for extending the lifetime of the new address. THis
is a major problem since you can not perform the RR procedure because
the HoA is no longer available. The solution for this would be to extend
the lifetime of the binding but this may have security implications. you
have previously worked in MIPv6 security, right? could you comment about
the security concerns of extending this timer?
> On top of that,
> quite a bit of signalling is performed just in case that a link might go
> down.
e2e failure detection implies traffic exchange. It is important to
discuss whether this overhead is acceptable or not. However this is not
strictly related with the usage of MIP but with host based solutions
IMO. I have studied an alternative for this in
http://www.it.uc3m.es/marcelo/mhExtHdr.txt
But it did present some other issues though...
>
> Needless to say, this doesn't seem to be all that useful, the tradeoffs
> would seem to be quite overwhelming: especially the 140 seconds; I'd say
> the outage of 10-20 seconds is the most that's acceptable for most
> connections to stay properly alive.
Great. THis part can be solved, i think. Higher frequency would provide
this with an acceptable cost, i think. Specially when piggybacking is
included in MIPv6. As i said earlier, if this is deemed acceptable, the
message exchange for failure detection needs to be reasonably tuned.
Moreover, probably adaptive mechanisms are needed to provide a
reasonably good performance. But i think this can be done (once that
other issues are solved, specially the 420 secs timer)
>
> ==> however, I appreciate thinking the whole thing through.. however, as
> it is, the doc is quite heavy to read as it's full of gritty details
> (which are nice when you want to get down to it, and verify it), but more
> focus should be given to the big picture..
>
> ==> there is a need for a shorter overview before section 4.3
>
Ok, i'll try to do this
> ==> sect 4.3 must be split into smaller pieces
>
> In the application scenario, according to [3],
>
> Site Exit Anycast Addresses for ISPA is
> PA:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAA)
>
> Site Exit Anycast Addresses for ISPB is
> PB:Site:FFFF:FFFF:FFFF:FFFF:FFFF (Hereafter SEAAB)
>
> Then, MHH will try first to send a first packet with:
>
> ==> these values seem to be irrelevant, remove.
> Btw, how does a node know the
> prefix length of his site? Not an easy problem, unless it's guessing..
>
Good point!!!
An option is to consider that it is always a /48, but i don't thik this
is a good approach.
Another possibility is to assign the site exit routers anycast address
of every subnet to the corresponding exit router and propagate it within
the site as a host route. So hosts will address packets to its own
subnet exit site router anycast address, which will be routed to the
correspondent exit router.
Since the explanation is not so clear i will put an example
+----+ +----+
|R1 | |R2 |
|P1::| |P2::|
+----+ +----+
P1:Subnet1:Router1 | P2:Subnet2:Router2 |
-------------------------------------
P1:Subnet1:Router3 |
P2:Subnet2:Router3 |
+----+
|R3 |
+----+
P1:Subnet3:Router3 |
P2:Subnet4:Router3 |
-----------------------------------
P1:Subnet3:Host |
P2:Subnet4:Host |
+----+
|Host|
+----+
So Addresses P1:Subnet1:FFFF:FFFF:FFFF:FFFF and
P1:Subnet3:FFFF:FFFF:FFFF:FFFF are assigned to R1.
P1:Subnet3:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
route to R1
Addresses P2:Subnet2:FFFF:FFFF:FFFF:FFFF and
P2:Subnet4:FFFF:FFFF:FFFF:FFFF are assigned to R2.
P2:Subnet4:FFFF:FFFF:FFFF:FFFF is announced within the site as a host
route to R2
So when Host sends a packet whose source address contains the prefix P1,
it includes a routing header with P1:Subnet3:FFFF:FFFF:FFFF:FFFF which
is deduced from its own prefix.
Not very nice, but i guess this would work, don't you?
> editorials:
> -----------
>
will fix, thanks.
Thanks again for your feedback, regards, marcelo
> Application of the MIPv6 protocol to the multi-homing problem
>
> ==> uppercase the first chars of the most words
> ==> same goes for the section titles
>
> This note attempts to describe how to apply the MIPv6 protocol to
>
> ==> s/MIPv6/Mobile IPv6 (MIPv6)/
>
> 1. Introduction
>
> ==> split the section; too long paragraphs are difficult to read
> ==> actually, a lot of paragraphs should be split up
>
> 1- A path failure detection mechanism, that enables end-hosts to
>
> ==> s/,//
>
> 4.2.3 Required capability #1
>
> ==> reqs should be listed in order or numbered differently
>
> alternative ISP is to be used for coursing packets. Source address
>
> ==> I'm not sure what you mean by "coursing" but I suggest using another :-)
> (many other places..)
>
> the second message. IF this is the case, a BU message is sent,
>
> ==> s/IF/If/
>
> Finally, this solution does not requires that multi-homed sites to
>
> ==> s/requires that/require/
>
> References
>
> [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
> IPv6", Internet Draft, Work in progress, May 2002.
>
> ==> split the refs
> ==> s/J. Arkko/Arkko, J./ (same everywhere)
--
marcelo bagnulo <marcelo@it.uc3m.es>
uc3m