[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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? 

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

meaningless

   Current IPv4 multihoming practices
   have been added on to the CIDR architecture [1],

Anyone who is familiar with why CIDR exists doesn't need to read this document, anyone who needs to read this document won't be helped by this reference in the introduction.

   Multihoming is a mechanism by which enterprises can currently satisfy
   a number of high-level requirements,

meaningless, list them

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.

   The preferred way to multihome in IPv4 is to announce an independent
   block of address space over two or more ISPs using BGP.

The type of address block is a detail that isn't important at this stage in my opinion.

   Until the
   mid-1990s this was relatively easy to accomplish,

More information without added value.

 as the maximum
   generally accepted prefix length in the global routing table was a /
   24, and little justification was needed to receive a /24.  However,
   in 1995 the growth of the global routing table became a problem once
   again, and as a result some providers decided to start filtering
   prefixes it accepted from peers based on prefix length.  This broke
   the expectation that a multihomed network announcing a /24,
   regardless of where in the IPv4 address space this /24 was taken
   from, would be globally reachable.

Detail detail detail

   This practice has two advantages and one disadvantage for the
   multihomed network.  The first advantage is that they can obtain a
   much smaller block of address space from an ISP than from a RIR.

Detail...

   (Would-be multihomers still often optimize their networks for
   qualifying for at least a /24 by adopting accepted but relatively
   wasteful address deployment strategies.)

Detail for the detail

   The second advantage is that
   even if their announcement

We don't even know what an "announcement" is (yet?)...

   Most ISPs will cooperate
   with this "punching holes in an aggregate" solution to multihoming,
   but some are reluctant.

More detail.

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

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

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

So a multihomed customer has the option of manually rerouting when there is a failure that isn't detected by BGP. That's certainly true.

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

We're talking about multihoming benefits. This has little to do with exchange failure, which a BGP reset isn't.

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.

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

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.

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

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.

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