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

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

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



	Hi!

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

I think that is what the second paragraph describes? I guess you are 
saying that it should be more clear....:-)

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

Hmm. True. This should refer to an advantage with the model, not for 
the network.

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

Agreed. Will add or try to re-write. I will post some proposed text 
here first.

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

True. I should add something on this as well.

> - Section 2 Terminology
>
> Perhaps for completeness it would good to add the definition of a 
> multihomed (end)site?

I guess I agree.

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

I refers to the physical network. Point-2-point links, peering point 
etc.

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

Ok, agreed.

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

I kind o agree, but then we need to be clear that we only describe 
methods that are direct results of the way the prefixes are announced. 
So that we ignore other features of BGP.

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


Hmm, I sort of see what you are saying but I am not sure how to 
describe it. I will think it over a bit and propose text.

> - Section 4.2
>
> s/addressblock/address block
> s/teh/the

Thanks!

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

Yes. There is nothing in the document that says that all reasons that 
can be used for requiring multihoming in section 4 needs to apply to 
section 5. Section 3 is to list the high level reasons as to why 
someone might want to do multihoming, section 4 lists the possible ways 
of doing multihoming, and section 5 lists what features you _can_ have 
from multihoming as done today. If you think this needs to be made 
clearer I will try and do that.

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

Well. Hmm. I kind of agree. Will add.

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

I agree that this needs to be rewritten. What I read it as saying is 
that within an enterprise, needs for load-control will rise from 
different entities varying need for bandwidth to different destinations 
over time. But customer is not a very good description.


- - kurtis -

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

iQA/AwUBQPTc06arNKXTPFCVEQIBbACgm6hYVKrbyRsEJgsD8yk/VRlPD2AAnRY0
YGVE/GDHvV8PBFMlNOzM0MC+
=8Tgi
-----END PGP SIGNATURE-----