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

Re: Updated 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.

Well, no chair hat is on for this message.


After reading Iljitsch's & Marcelo's comments, and some side conversations,
I think we would have a much easier time with this document if section 3
(motivations for mh) was simply removed. Otherwise, we will discuss
it for ever and never converge. I suggest limiting to the description
of solutions.

4.5 NAT or RFC2260 based multihoming

This last method might very well be the most commonly used method in
terms of volume. Simply because this is what most residential users
are normally referred to.

That may be true, but it hides the fact that NAT is also very commonly used by enterprise networks, including some *very* big ones. It's the really easy way to avoid advertising a large number of specifics when the same enterprise is connected to the Internet at a large number of points.

6.1 Scalability

Current IPV4 multihoming practices contribute to the significant
growth currently observed in the state held in the global
inter-provider routing system;

With an important exception - NAT based mh specifically doesn't do this (and probably explains why there has been significant growth in mh without a corresponding explosion in BGP4).

Brian