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

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



Hi Iljitsch,


thanks for your detailed comments...

some replies below...

El 13/06/2006, a las 16:52, Iljitsch van Beijnum escribió:

On 8-jun-2006, at 1:28, Geoff Huston wrote:

This document discusses the applicability of the Shim6 IPv6 protocol
element and associated support protocols to provide site multihoming
   capabilities in IPv6.

Comments:

"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. In particular is not strictly required that those addresses come from different isp (as it is somehow the scenario for which the shim6 was designed for). It would be possible to use the shim6 protocol in a host that has multiple interfaces with one address in each interface and all the addresses with the same prefix for instance... i guess you know all this already, but this is what the draft is trying to communicate (unsuccessfully it seems :-(

would it improve rephrasing it as:

  While the Shim6 protocol does not impose any requirements
  on the addresses involved in this process


"In the scenario illustrated in Figure 1 host H communicates with some
   remote host H'."

My understanding of using a ' to differentiate between two things is that it generally means that the two things are very similar, or represent two stages of the same thing. In this case, that doesn't apply so it's confusing. Please use another letter for the second host.


:-)

will ddo

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?

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

Again my usual dislike of empty lines to skip to the next "page" for a new heading.


next one will be a "comptact" version....

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

"   The use of CGA [RFC3972] and HBA [I-D.ietf-shim6-hba] involve
   encoding information in the lower 64 bits of locators.  This imposes
the requirement on address assignment to Shim6-capable hosts that all
   interface addresses should be able to accommodate 64-bit interface
   identifiers.  This requirement is also imposed by CGA [RFC3972]."

Not to mention RFC 3513:

" For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format."

ok, will add the reference


"4.  Shim6 Capabilities

4.1.  Fault Tolerance

4.1.1.  Establishing Communications After an Outage"

Having headers without any text under them is considered bad style.

"   managed centrally."

A single line on a new "page" is a "widow" and considered undesirable. Simarly, the following line is an "orphan":

"   So, in this configuration, the shim6 protocol is used to provide"


i guess this will be solved with the compact version...


"However, MIPv6 lacks
   of failure detection mechanisms"

Grammar.

"In this case, the shim6
   protocol wouldn�t be used"

Unicode problem??


i think it is a typo

Extra space after each sentence.

Altough I feel there are way too many RFCs already, it might make more sense to move the shim6/MIPv6 interactions to a separate document because this part just doesn't seem to feel at home here.


well, the whole part about interactions with other parts of the stack seems to belong to this document to me
but perhaps we can hear other opinions...

Inconsistent use of "Shim6" and "shim6".

"It is
   recommended that Shim6 is not used for SCTP sessions, and that path
   maintenance is provided solely by SCTP."

Hm, I suspect that there are failure modes that aren't handled well by SCTP that shim6 can handle.

i don't know...

perhaps unidirectional failures? shim6 can handle a communication with two unidirectional address pairs.... i don't know about sctp...

 And AFAIK SCTP has no security to speak of.


i don't know....

"In this case, the shim6 protocol would be associated to the
   tunnel interface"

Missing period.

"6.  Security considerations

   This section will be completed before publication is requested."

How about completing it before review is requested?


:-)

we do what we can....

" 2. Application scenarios . . . . . . . . . . . . . . . . . . . . 4 3. Address Configuration . . . . . . . . . . . . . . . . . . . . 6"

Inconsistent capitalization, happens in multiple places.

Choice of American/British spelling MAY be inconsistent, I spotted "behaviour" and "optimization".


regards, marcelo



Iljitsch