[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-shim6-applicability-01.txt

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!  :-)


would it improve rephrasing it as:



  While the Shim6 protocol does not impose any requirements
  on the addresses involved in this process
No. People have to guess what you mean, which is pretty much impossible because red stripes on the sides aren't required either. Either remove this bit or say what you're referring to.
In general, the document seems to assume understanding of inter- domain routing. It is not explained what a locator is except that on second use it says "locator (address)" which implies that the two are the same thing. ULID isn't explained.
ok, we can add a definition section and include those two... is there any other term that you think should be there? 

No, but I didn't specifically look for that...


"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.
" 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
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?