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