[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-huston-multi6-architectures-00.txt
Hi,
A few comments of my own. Currently, the document should be better
titled "Architectural Approaches for Ensuring Connection Survivability
with Multihoming in IPv6", because that's what it's mostly about.
Oh, it does discuss how address selection affects inbound traffic,
etc., but that's probably not sufficient to satisfy the multihoming
goals.
So, I'm a bit fearful that we've been lately forgetting that
multi-addressing + address agility very probably DOES NOT solve the
multi6 problems adequately (for certain kind of sites at least -- it
should be sufficient for some others, though). Those other issues
should be explicitly taken into consideration here as well.
Otherwise, a very good document, if a bit too focused on a certain
class of multihoming solutions.
semi-substantial
----------------
The simplest formulation of the multi-homing environment is indicated
in Figure 1.
==> well, really, it isn't. The simplest formulation is a site
consisting of a single host, right?
The question is how that scenario should be handled by the
architecture. I don't find it too interesting myself, so one could
just s/simplest/simple/ and add a sentence to state why the degenerate
site case is not interesting for the architecture.
The environment of multi-homing is one that is intended to provideM
sufficient support to local hosts so as to allow local hosts toM
exchange IP packets with remote hosts, such that this exchange ofM
packets is to be seamlessly supported across dynamic changes inM
connectivity.
==> again, this is just one reason for multihoming, fulfilling only
certain redundancy requirements. Traffic engineering? Easy (or no)
renumbering? etc.
This may become a serious problem if we just take too deep focus on
connection survivability and forget everything else.
4. Approaches to Multi-HomingM
M
There appear to be four generic forms of architectural approaches toM
this problem, namely:M
==> note that the subject of the bulletpoints and the following
subsections don't match exactly. It was not clear whether it was the
intent. In any case, the subsection titles should probably be beefed
up a bit to be more descriptive of the content of the subsection.
o RoutingM
Use the IPv4 multi-homing approachM
==> the last statement is an oversimplification. There are slightly
different ways than (exactly) the v4 multihoming if we take a routing
route -- e.g., with geographically allocated prefixes. Fundamentally
this often leads to the routes ending up in the DFZ or a subset of it,
but it's still not the exact v4 mh approach.
o New Protocol ElementM
Insertion of a new element in the protocol stack that manages aM
persistent identity for the sessionM
o Modify a Protocol ElementM
Modify the Transport or IP protocol stack element in the host inM
order to support dynamic forwarding locator changeM
==> the difference of these approaches should be clearer at first, as
there is obvious overlap with 'insertion in the protocol stack', and
'modifying the [IP] protocol stack' -- or did the latter refer to the
L3 element?
==> I also wonder about the usefullness of this semantical difference,
as it seems likely that even if you added a new protocol element,
there would likely have to be changed in the adjacent protocol
elements, requiring modifications..
Even though the multi-homedM
sitines to be reachable via ISP B, packets directed to the site usingM
ISP A's prefix will be discarded by ISP A as the destination isM
unreachable.
==> this assumes that there is no connection other connection between
ISP A and the site, if the link goes down. This is not necessarily
the case, as can be seen from RFC3178 ("multihoming at site-exit
routers").
Normative ReferencesM
==> please add the refereces you made (and others) to here as well..
The draft primary focuses on the specification of this "superior"M
approach, largely ignoring some pertinent questions such as: WillM
residential and enterprise-level IPv6 routers reall support anycastM
routing?M
==> that's a confusing question. It asumes anycast routing would be
somehow different from unicast routing. It doesn't need to be, so
there is very little magic here.. and in this particular case where
all you want to auto-discover the address of the site exit router for
prefix X (there is only one of them), it's more of a single address
like well-known unicast than real anycast.
==> s/reall/really/
However, this draft does notM
address another major drawback of the RFC 3178 approach, thatM
it does not protect against the complete failure of one or moreM
connected ISPs.M
==> I think this is something where one should make a reality check.
How often is it that the _whole_ ISP fails? Pretty much _never_,
unless you count 1-man small ISPs which don't even have redundant
connectivity and routers (and we shouldn't care about this).
IMHO, the complete failure of one or more connected ISPs is not a
practically interesting scenario, especially for smaller sites (where
these kind of approaches are the most interesting in any case).
A.6.3 Related Multi-Homing drafts, Status unknownM
==> is there a reason why most of these are already mentioned in
previous subsections, and are listed again here? Suggest removing
from here..
editorial
---------
o aspects of a split between end-point-identifier and forwardingM
locator,M
==> IMHO, 'routing locator' is better than forwarding locator.
destination address. This would direct the pact to the local hostM
==> 'pact' -- typo?
equivalent address for teh local multi-homed host hat transits theM
==> s/teh/the/, s/hat/that/ ?
considerations of the use of Network Address Translators ([NATM
Considerations] contains much of this material.M
==> kill extra '(' ?
identifier to also be a valid locator. This would impliy theM
==> s/impliy/imply/
The next issue if that of the difference between the initial
sessionM
==> s/if/is/
a third party referral structure (such as the DNS), or dynmicallyM
==> s/dyn/dyna/
The author acknowledges the exensive contribution of MargaretM
==> s/ex/ext/
The essential characteristic of HIP is it use of opportunisticM
==> s/it/its/
basis of the persistent identity. The transport session cab be
agileM
==> s/cab/can/
o Layer 3.5 (Above IP, below TransportM
==> s/port/port)/
o Layer 3 (Inserted in the upper part of IP, below IPSEC andM
fragementation / reassemblyM
==> s/frage/frag/
neighbor reachability to avoid sending unncecessary ND packets.M
==> s/unnce/unne/
WIMP session is established, the IPv6 FlowID is used to hold anM
==> s/ID/ Label/
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings