[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