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.