Re: Updated draft-ietf-multi6-v4-multihoming-01.txt
Kurt Erik Lindqvist <[email protected]>
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-22, at 11.30, Brian E Carpenter wrote: >> 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. I agree with this (obviously). If someone _disagrees_, please let me know. I guess we will ask this question in San Diego as well. >> 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. Ok, I guess I should add that. >> 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). Ok, and for consistency I should add a comment on this. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQEhyaarNKXTPFCVEQI2uwCfUcF7w+GK0Ix+pwEF3lXO5HPEGxoAoLVT 8llMXLuyjMFYAJV4G0bje0sW =i/na -----END PGP SIGNATURE-----