[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt
El 19/06/2006, a las 0:45, Iljitsch van Beijnum escribió:
On 14-jun-2006, at 9:02, marcelo bagnulo braun wrote:
"While the Shim6 protocol does not impose any requirements on the
disposition of the locators involved in this process"
I don't understand what the authors are getting at here. I would
strongely suggest actually mentioning the requirements that aren't
imposed.
the point being made in the sentence is that it would be enough that
one of the peers has multiple addresses in order to be able to use
the shim6 protocol, no matter what those addresses are.
Well, don't tell me that, put it in the draft! :-)
ok, will try to rewrite this more clearly
"The Shim6 protocol has other potential applications beyond site
multi-homing. For example, since Shim6 is a host-based protocol,
it
can also be used to support session mobility between interfaces
on a
multi-homed host."
I disagree because shim6 isn't built to support jumping to a
previously unknown address, it is assumed that the addresses to be
used after a failure are known before the failure.
well, you could send an UPDATE message from the new location with the
new locator and the validation information for it included in the
UPDATe message itself. There is no fundamental reason why this cannot
be done (we would need to see the actual details of the protocol for
this in any case...)
The trouble is that if you say this, people are going to assume that
this is acutally a good idea, and be upset if it turns out that all
kinds of stuff that is important for mobility isn't in the shim.
well, i think we can remove this paragraph. In any case, the clear
explanation of what can and cannot be done is included in the mip shim
interaction section...
" The Shim6 protocol is defined only for IPv6. However, there is
no
fundamental reason why a Shim6-like approach could not support
IPv4
addresses as locators, either to provide multi-homing support to
IPv4-numbered sites"
We're already running out of IPv4 addresses with ONE address per
host...
fundamental reason from the protocol prespective... do you want us to
change something here?
Personally, I prefer to just say nothing in these cases. If you open
the can of worms, you have to deal what's inside. On the other hand,
people may wonder why it's shim_6_ so a good explanation of why this
is troublesome with IPv4 might be useful. This includes the fact that
the addresses are too short for CGA/HBA, burning up more addresses and
possible NAT trouble
well, i think it would be useful to support v4 locators (and locators
only, i am not suggesting in any way to use v4 ulids...)
so, i would prefer to keep some mention to v4 locators in the document
however, i am ok with including a paragraph explaining the limitations
of such approach, such as that no v4 ulids are supported and that nat
traversal would require quite more work.
There is an additional thing that I noted but didn't bring up in my
previous message:
" One possibility would be to use MIPv6 capabilities, by simply
changing the CoA used as the tunnel endpoint. However, MIPv6 lacks
of failure detection mechanisms that would allow the MN and/or the
HA
to detect the failure and trigger the usage of an alternative
address. Shim6 provides such failure detection protocol, so one
possibility would be re-use the failure detection function from the
shim6 failure detection protocol in MIPv6. In this case, the shim6
protocol wouldn�t be used to create shim6 context and provide
fault tolerance, but just the failure detection functionality would
be re-used."
Does this imply we should try to make the reachability/failure
detection protocol more general so it can work even if there is no
shim6?
i think this is already somehow the case... but i would like to make a
more detailed analysis of this and see if the failure detection protcol
can be easily used in hip (i guess so) and in mip (i hope so) :-)
regards, marcelo