Subject: Re: I-D ACTION:draft-huston-multi6-architectures-00.txt

From: Pekka Savola <[email-masked]>
Date: Thu, 20 May 2004 11:21:02 +0300 (EEST)

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 24 May 2004 11:38:06 +0200

Hi Pekka,

A couple of questions about RFC 3178 multihoming...

El 20/05/2004, a las 10:21, Pekka Savola escribió:
[...]
>                                      However, this draft does not
>          address another major drawback of the RFC 3178 approach, that
>          it does not protect against the complete failure of one or 
> more
>          connected ISPs.
>

IMHO the problem is that RFC 3178 multihoming situation not only fails 
when the complete ISP fails, but it also fails when
- one of the access routers of the ISPs fail,
- one of the exit routers of the site fail
- one of the links between the ISPs and their upstream provider fail

While i agree that probably the complete failure of the ISP may be a 
low probability event, i guess that the above mentioned events may be 
more common.

The other reality check that i would like to do is how common is RFC 
3178? if it is not very common, what do you think are the reasons for 
its non adoption?

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 May 2004 12:45:32 +0300 (EEST)

> low probability event, i guess that the above mentioned events may be 

No, this is definitely not the case.  The first two bullet points are
only valid if site site does not have tunnels to from the other exit
routers to the other ISPs (or the tunnel is terminated at the ISP to
the same router as the physical link), right?  The third point is only
valid if the ISP has only one link to an upstream provider -- and no
self-respecting ISP has only one upstream link.
 
> 3178? if it is not very common, what do you think are the reasons for 

True enough.  I don't think there is sufficient evidence to make
conclusions of this, as the number of v6-enabled enterprises which
don't have IPv6 /32 prefixes (but which multihome w/ v4) is very
low..?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 24 May 2004 12:22:54 +0200

> the same router as the physical link), right?

Well, this is possible but this is not described in RFC 3178 and it 
imposes additional configuration, for instance of the IGP of the ISP. 
But i agree that it is possible to support this configuration, with 
some added complexity. My point was aimed to identify another possible 
cause for the non success of this solution, which could be related to 
operational complexity? I mean, tunnel management, and added features 
like the support for additional failure modes may require additional 
manual configuration, which may make the solution less attractive.

> The third point is only

Well, you are assuming that very small sites will obtain its own 
address block from the RIR, which may not hold, i guess

> don't have IPv6 /32 prefixes (but which multihome w/ v4) is very

Well, i guess this is an important issue to understand, since if rfc 
3178 multihoming is enough for some small sites (for instance), the new 
solution should be focused to satisfy the needs of the remaining sites 
(medium/big) sites, and the scalability required may be different.

In other words, understanding the reasons why rfc 3178 is not a good 
option may provide us good information for the design of the new 
solution, especially w.r.t to deployability.

regards, marcelo