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

Re: Updated draft-ietf-multi6-v4-multihoming-01.txt

Hi Kurtis,

some comments about the draft...


- Section 1

In the third paragraph it is stated that:

"This practice has two advantages and one disadvantage for the..."

what practice are you considering?
I think you are considering the situation where a multihomed site obtains an address block from one of its providers and announces it through the other providers, but i couldn't find it stated explicitly

   multihomed network.  The first advantage is that they can obtain a
   much smaller block of address space from an ISP than from a RIR.
   (Would-be multihomers still often optimize their networks for
   qualifying for at least a /24 by adopting accepted but relatively
   wasteful address deployment strategies.)

Well, i don't know why this is a benefit for the multihomed network in particular.
I mean, i can see that this is benefit for the Internet as a whole, since addresses are used in a more efficient way, but i don't see how the multihomed site is better off.

   The second advantage is that
   even if their announcement is filtered, they are still reachable over
   the primary ISP by virtue of the aggregate announced by this ISP.
   Even when the circuit to the primary ISP is down, this often works
   because the primary ISP will generally accept the announcement over
   the secondary ISP, so traffic flows from the filtering network to the
   primary ISP and then to the secondary ISP in order to arrive at the
   multihomed network.  While this is common, it is also not universally
   true.

An implicit requirement here is that the primary ISP must peer with each one of the other ISPs, wwhich i am not sure that this is always true. I mean, there are two conditions here: first the primary ISP must peer with the other ISP and second the primary ISP must accept the announcement of shorter prefixes.

   The disadvantage is that the multihomed network must depend on the
   primary ISP for the aggregate.  If the primary ISP goes down, this
   will impact reachability to networks that filter.  And when the
   multihomed network leaves the primary ISP, they are generally
   expected to return the address space because otherwise this ISP would
   have to route traffic for a non-customer.  Most ISPs will cooperate
   with this "punching holes in an aggregate" solution to multihoming,
   but some are reluctant.

Well, another clear disadvantage is that the address block of the multihomed site belongs to the ISP, so if the multihomed site changes its primary ISP, it must renumber. An interesting point is that if the multihomed site changes any of the other isps, it don't have to renumber.

- Section 2 Terminology

Perhaps for completeness it would good to add the definition of a multihomed (end)site?

- Section 3

- Section 3.1

   By multihoming, an enterprise can insulate itself from certain
   failure modes within one or more transit providers, as well as
   failures in the network providing interconnection with one or more
   transit providers.

I fail to understand the meaning of the last part of the sentence (starting from "as well..)
Perhaps it needs some rewording?

- Section 3.2

Perhaps it would be valuable to add some more detailed description of which kind of support for load sharing is obtained with this solution?
I mean, perhaps talking about announcing more specific prefixes, AS prepending and so on and presenting the limitations of each method. IMHO this may be important when considering the capabilities of an IPv6 multihoming solution. I mean, when comparing IPv4 capabilities vs IPv6 capabilities we will need to go more in detail than just load sharing support, i guess.

- Section 3.4

Same comments that in load sharing. Current multihoming solution support some degree of policing. Perhaps explaining what level of support is provided and its limitations could be useful (like the stuff presented in section 5.3 but w.r.t policy and perhaps in a bit more of detail)

- Section 3.5

Most of the benefits presented are related to obtaining a PI address block (rather than being multihomed)
As you mention in the introduction, a site can be multihomed, but still use PA address from one of its providers, so most of these benefits will not be achieved.
imho this section is a bit misleading in this aspect.
I mean independency w.r.t. renumbering, easier migration and so on are benefits of having PI addresses and they are not benefits of being multihomed. Just happens to be that being multihomed is one of the ways of obtaining PI addresses given current RIR policies :-)
I mean, imho we need to explain the situation a bit more in detail here.

- Section 4.2

s/addressblock/address block
s/teh/the

- Section 5

The features described in this section don't really apply to all multihomed configurations described in section 4. For instance, configuration 4.5 (using NATs) don't provide feature 5.2 (transport layer survivability), Moreover, multiattached networks don't obtain full fault tolerance against all the failures described in section 3.1. Additionally NAT configuration doesn't really provide much TE capabilities AFAICS. OTOH, NAT configuration is really simple and can be adopted in unmanaged environments, while BGP based configuration doesn't seems as simple as this, so i am not sure that the simplicity benefit applies to all of the configurations in the same level.
I don't know which approach to follow with this, but i am tempted to suggest that the NAT approach and the multiattached approach are moved to a later section where they are presented as "other approaches" where their limitations and advantages are presented.

In addition, as i understand this, the features described in this section are in addition to the features presented in section 3, right? Perhaps stating this explicitly would make it clearer

- Section 5.2

I would mention in this section that becuase the number of AS in the Internet and the delayed BGP convergence that it causes, this feature is not universal in the current Internet, i.e. that there are some outages that take a long time BGP to reconverge causing come TCP connections to fail. Perhaps quoting Labovitz work here...
another limitation here (as Iljitsch has mentioned several times by now) is that the current default time setting on some commercial routers make that BGP need 3 minutes to detect an outage, so this implies that it will take more than 3 min to reroute the established communications. Bottom line is that current multihoming solution doesn't really preserves all established communications always.

- Section 5.4

   The current multihoming solution places control of traffic flow in
   the hands of the enterprise responsible for the multi-homed
   interconnections with transit providers.  A single-homed customer of
   a multi-homed enterprise may vary the demand for traffic that they
   impose on the enterprise, and may influence differential traffic load
   between transit providers; however, the basic mechanisms for
   congestion control and route propagation are in the hands of the
   enterprise, not the customer.

I fail to understand this section. I mean, here we are considering only site multihoming, so i don't see why are relevant comments about clients of the multihomed enterprise. AFAIU, a multihomed end site don't have customers, right?
The same goes for the customer/ enterprise comments in the last sentence

Regards, marcelo




El 12/07/2004, a las 11:48, Kurt Erik Lindqvist escribió:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I have today submitted draft-ietf-multi6-v4-multihoming-01.txt to the
I-D editor. As I assume I am not the only one submitting drafts today
:-) it is also at
http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt


Brian will act as WG chair for anything that relates to this draft, I
will act as editor.

While updating I have gone through all comments I have found. I have
acted on most, and disagreed with some. Some where more or less out of
scope after recent (6 months) development of the WG, so I haven't acted
on them.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQPJecKarNKXTPFCVEQKf9ACg8RY+xEWXhiZ1a+sTc4llwr65q+oAoNeW
2qZQX6T0C6UnCpSAkE32Ehx4
=lY7m
-----END PGP SIGNATURE-----