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

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 12-jul-04, at 11:48, Kurt Erik Lindqvist wrote:

> http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt

Ok, I'm not going to repeat everything that Marcelo said, but I agree 
with pretty much all of it. Apart from that:

- no mention of what "multihoming" is in the abstract, multi6 is 
mentioned but only the long title, this won't help people looking for 
the wg very much
- enterprises enterprises, why not say "organizations" at least once in 
a while?
- the introduction talks about all kinds of details without 
illuminating the big picture
2.
- 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
- "A "multi-attached" enterprise is one with more than one point of 
layer-3 interconnection to a single transit provider." Huh? How is this 
different from being multihomed?
3.1
- a bgp peer reset isn't a routing protocol failure
- multihoming doesn't necessarily protect a customer against isp igp 
failure as it is likely that bgp will continue to function in such a 
case
- a bgp peer reset isn't an exchange failure
3.2
- load sharing limitations aren't explained
3.4
- why talk about load sharing here?
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
4.3
- who cares? only confuses the issue
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.
5.1
- grammar
- i think many people wouldn't agree that this is straightforward
5.2
- i partially agree with Marcelo: there are times when sessions don't 
survive. however, this is rare in practice
5.3
- 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
6.1
- why avoid 32 bit AS numbers??? this draft has been around for years.
references
- 7: this was later published as rfc 3221, which makes for a better 
reference imo

general
- it is never really explained how multihoming is actually done (in a 
way that someone who doesn't already do it understands)

Wouldn't starting from scratch be simpler than trying to fix this 
document?