[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