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

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

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



	Iljitsch,

my apologies for the late reply. I managed to get ill and be alone in 
the office and rebuilding networks to get IPv6 to i.root - all at once. 
So the last week was a bit "exciting".....

On 2004-07-14, at 21.24, Iljitsch van Beijnum wrote:

> On 14-jul-04, at 9:29, Kurt Erik Lindqvist wrote:
>
>>> - the introduction talks about all kinds of details without
>>> illuminating the big picture
>
>> Care to be a bit more specific?

What you have written as a response puzzles me a bit. Many of the 
paragraphs you mention as "details" are more less the same ones as you 
have listed in your mail to the list on 3 May 2003 commenting on the 
- -00 draft. Actually, the introduction and your suggested text in the 
mail was so similar after Vijay had started rewriting the draft that I 
thought your comment had been addressed with the new text.

I won't comment on all the analysis because the above, but I want to 
address

>    Multihoming is an important component of service for many 
> enterprises
>    which are part of the Internet.
>
> meaningless

As per Brian's mail, we have had off-list discussions that led to the 
belief that maybe we should strip this document of chapter 3 and all 
references as to why people want to multihome.

>    and is widely used in the IPv4 network today.
>
> Actually that's not true. There are around 15k ASes in use world wide, 
> and most of these are ISPs or similar. This leaves only around 5000 - 
> 10000 BGP-type multihomers world wide.

Hmm. From Philip Smith's reports

Total ASes present in the Internet Routing Table:                 17594
Origin-only ASes present in the Internet Routing Table:           15254
Origin ASes announcing only one prefix:                            7148
Transit ASes present in the Internet Routing Table:                2340
Transit-only ASes present in the Internet Routing Table:             70

I don't remember the definitions of each of the classes in the report, 
but I read this as there are at least ~15k potential multihomers.


>>> - definition for multihomed isn't very good as this also catches
>>> organizations which use one isp for part of their network and another
>>> for another part
>
>> Yes? Is this a problem?
>
> Of course. If I connect my office X to ISP A and office Y to ISP B but 
> don't connect the offices together, that's not multihoming. This is 
> why talking about "enterprises" is dangerous. ("Organization" has the 
> same problem though.) "Site" or "network" would be better. And of 
> course an explicit mention that the ISP connections are shared by the 
> same users/systems.

Actually the problem is that neither the definition nor what you write 
above gives away if this method leads to a growth in the number of 
routes. I could come up with a (although stretched) example of an 
enterprise that have sites A and B that are connected to ISP IA and ISP 
IB respectively. I have one /24 PI space that both ISPs announces. A 
and B have no direct connection between them, but have a 
IP-Sec/GRE/MPLS tunnel between them. Am I multihomed? If you think this 
is a wired example, it's done. Actually some large VPN customers of 
mine at KPNQwest did it this way.

>>> - a bgp peer reset isn't a routing protocol failure
>
>> Is "Failures signaled by routing protocols" better wording?
>
> The problem is not with the wording but with the example. BGP detects 
> reachability failures. There are a few corner cases but those don't 
> belong in a document like this.

As discussed in a private conversation between you, me and Pekka - this 
text needs to rewritten.


>>> 4.1 and 4.2
>>> - difference between pa addresses and pa addresses is unclear. what's
>>> meant here is the difference between having your own block and
>>> shooting holes in an isp's block
>
>> PA and PA are the same :-) I assume you mean PI and PA.
>
> No, what I mean is having your own PA block and having an address 
> block that is part of someone else's PA block. PI is different from 
> both.

Aha, then I understand you. Ok, agreed.

>>> - who cares? only confuses the issue
>
>> I disagree. This is a used multihoming mechanism that is different 
>> from
>> all the others.
>
> There is no legitimate reason to not use an AS number when 
> multihoming. I can't seem to find an RFC that says you can't do it, 
> but sourcing prefixes with an inconsistent origin AS is certainly 
> frowned upon.

It's certainly also done.

>
>>> 4.5
>>> - this is so different from the other types of multihoming that it's
>>> impossible to discuss it along with those. move this to a different
>>> section. and don't forget that nat in and of itself doesn't do
>>> anything for multihoming. also this isn't mentioned anywhere else so
>>> it's mostly a red herring.
>
>> I would disagree for the above reason.
>
> You need to talk about this separately as none of the rest of the 
> document applies to this type of multihoming.

That might be true :-)

>>> - this is a very bad practice as it inflates the (global) routing
>>> table and certainly not the only way to influence INBOUND traffic, 
>>> not
>>> to mention outbound traffic. also, rfc 1998 is a very good reference
>>> here
>
>> It doesn't say it's good practice. It says it is used.
>
> Yes, and people also use tinfoil for fuses. So should they talk about 
> that in electrical engineering texts?

Actually solid pieces of iron is more common where I am from. But then 
the "application" might not be entirely legal either :-) But the result 
taste ok, and you will normally not get blind...

But as for the including this. Yes, I think the textbook should include 
this. If is is in common use, it should be described. That is not the 
same as saying that it is good.


>> I am not really sure in what way you want 1998 referenced?
>
> RFC 1998 provides a cleaner mechanism to do something similar to what 
> you're describing.

Yes, but I would almost like to argue that 1998 is less used. But you 
are right, if we are to include all methods, we should include this as 
well.

>
>>> - it is never really explained how multihoming is actually done (in a
>>> way that someone who doesn't already do it understands)
>
>> I don't really understand what you mean here. What is it that you 
>> think
>> should be explained better?
>
> This is what I say on my website about what multihoming is: 
> http://www.bgpexpert.com/#multi
>
> I'm not suggesting reusing this text but certainly something conveying 
> this information but written for an IETF audience would be useful in 
> the introduction.

Ok, see comments above on the introduction text.

BTW, would you agree to remove chapter 3 and the references to 
motivations for multihoming.

- - kurtis -

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

iQA/AwUBQQEgz6arNKXTPFCVEQJUfQCeNyuxp6/BrcKSD4dQP2ufVrhpemUAoO/k
nZqN8vjpbEnlMWvEZBgp96fe
=S+C1
-----END PGP SIGNATURE-----