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

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

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

>
> - 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

Ok, agreed.

> - enterprises enterprises, why not say "organizations" at least once 
> in a while?

Actually I used organizations in the text I had written. Then realized 
that Pekka had posted the suggestion to use sites, and then saw that 
enterprise was used before. Reading the text I decided that I thought 
enterprise was a good word to use. I have no strong feeling one way or 
the other though. Do the native English speakers have any view?

> - the introduction talks about all kinds of details without 
> illuminating the big picture

Care to be a bit more specific?

> 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

Yes? Is this a problem?

> - "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?

It's to a single upstream compared to multiple upstreams.

> 3.1
> - a bgp peer reset isn't a routing protocol failure

Is "Failures signaled by routing protocols" better wording?

> - 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

Well, it doesn't protect it automatically but you could manually route 
around it for the time being.

> - a bgp peer reset isn't an exchange failure

While I agree, I think it does describe what is happening in the text :

" Exchange failure, such as a BGP reset on an inter-provider
       peering."

> 3.2
> - load sharing limitations aren't explained

No. Agreed.

> 3.4
> - why talk about load sharing here?

I can try and come up with a better name for what is described. But I 
would argue it is a form of load-sharing.

> 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. Ok, will try 
and come up with better text.

> 4.3
> - who cares? only confuses the issue

I disagree. This is a used multihoming mechanism that is different from 
all the others.

> 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.

> 5.1
> - grammar

Thanks!

> - i think many people wouldn't agree that this is straightforward

I think it is straightforward in the ways mentioned. That is not to say 
it is easy though.

> 5.2
> - i partially agree with Marcelo: there are times when sessions don't 
> survive. however, this is rare in practice

Yes, but I agree with Marcello that the limitations should be noted.

> 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

It doesn't say it's good practice. It says it is used. I am not really 
sure in what way you want 1998 referenced?

> 6.1
> - why avoid 32 bit AS numbers??? this draft has been around for years.
> references

I have no view on way or the other. I can remove that if needed.

> - 7: this was later published as rfc 3221, which makes for a better 
> reference imo

Ok, will change.

>
> general
> - 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?

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

I don't think so...

- - kurtis -

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

iQA/AwUBQPTgw6arNKXTPFCVEQKHEwCfd7KTPQg3PpRvT3qsD2XjYAC60WAAniUo
TN+aKQLEjiZAs4fFtYyEuf28
=Q0yH
-----END PGP SIGNATURE-----