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

From: Kurt Erik Lindqvist <[email-masked]>
Date: Mon, 12 Jul 2004 11:48:29 +0200

I have today submitted draft-ietf-multi6-v4-multihoming-01.txt to the 
I-D editor. As I assume I am not the only one submitting drafts today 
:-) it is also at 
http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt

Brian will act as WG chair for anything that relates to this draft, I 
will act as editor.

While updating I have gone through all comments I have found. I have 
acted on most, and disagreed with some. Some where more or less out of 
scope after recent (6 months) development of the WG, so I haven't acted 
on them.

- - kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 12 Jul 2004 13:52:06 +0200

> Brian will act as WG chair for anything that relates to this draft, I 

The plan is to try to reach consensus on any open issues during the
San Diego meeting, so please let's hear what issues exist.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Jul 2004 17:17:53 +0200

Hi Kurtis,

some comments about the draft...

- Section 1

In the third paragraph it is stated that:

    "This practice has two advantages and one disadvantage for the..."

what practice are you considering?
I think you are considering the situation where a multihomed site 
obtains an address block from one of its providers and announces it 
through the other providers, but i couldn't find it stated explicitly

    multihomed network.  The first advantage is that they can obtain a
    much smaller block of address space from an ISP than from a RIR.
    (Would-be multihomers still often optimize their networks for
    qualifying for at least a /24 by adopting accepted but relatively
    wasteful address deployment strategies.)

Well, i don't know why this is a benefit for the multihomed network in 
particular.
I mean, i can see that this is benefit for the Internet as a whole, 
since addresses are used in a more efficient way, but i don't see how 
the multihomed site is better off.

    The second advantage is that
    even if their announcement is filtered, they are still reachable over
    the primary ISP by virtue of the aggregate announced by this ISP.
    Even when the circuit to the primary ISP is down, this often works
    because the primary ISP will generally accept the announcement over
    the secondary ISP, so traffic flows from the filtering network to the
    primary ISP and then to the secondary ISP in order to arrive at the
    multihomed network.  While this is common, it is also not universally
    true.

An implicit requirement here is that the primary ISP must peer with 
each one of the other ISPs, wwhich i am not sure that this is always 
true. I mean, there are two conditions here: first the primary ISP must 
peer with the other ISP and second the primary ISP must accept the 
announcement of shorter prefixes.

    The disadvantage is that the multihomed network must depend on the
    primary ISP for the aggregate.  If the primary ISP goes down, this
    will impact reachability to networks that filter.  And when the
    multihomed network leaves the primary ISP, they are generally
    expected to return the address space because otherwise this ISP would
    have to route traffic for a non-customer.  Most ISPs will cooperate
    with this "punching holes in an aggregate" solution to multihoming,
    but some are reluctant.

Well, another clear disadvantage is that the address block of the 
multihomed site belongs to the ISP, so if the multihomed site changes 
its primary ISP, it must renumber. An interesting point is that if the 
multihomed site changes any of the other isps, it don't have to 
renumber.

- Section 2 Terminology

Perhaps for completeness it would good to add the definition of a 
multihomed (end)site?

- Section 3

- Section 3.1

    By multihoming, an enterprise can insulate itself from certain
    failure modes within one or more transit providers, as well as
    failures in the network providing interconnection with one or more
    transit providers.

I fail to understand the meaning of the last part of the sentence 
(starting from "as well..)
Perhaps it needs some rewording?

- Section 3.2

Perhaps it would be valuable to add some more detailed description of 
which kind of support for load sharing is obtained with this solution?
I mean, perhaps talking about announcing more specific prefixes, AS 
prepending and so on and presenting the limitations of each method. 
IMHO this may be important when considering the capabilities of an IPv6 
multihoming solution. I mean, when comparing IPv4 capabilities vs IPv6 
capabilities we will need to go more in detail than just load sharing 
support, i guess.

- Section 3.4

Same comments that in load sharing. Current multihoming solution 
support some degree of policing. Perhaps explaining what level of 
support is provided and its limitations could be useful (like the stuff 
presented in section 5.3 but w.r.t policy and perhaps in a bit more of 
detail)

- Section 3.5

Most of the benefits presented are related to obtaining a PI address 
block (rather than being multihomed)
As you mention in the introduction, a site can be multihomed, but still 
use PA address from one of its providers, so most of these benefits 
will not be achieved.
imho this section is a bit misleading in this aspect.
I mean independency w.r.t. renumbering, easier migration and so on are 
benefits of having PI addresses and they are not benefits of being 
multihomed. Just happens to be that being multihomed is one of the ways 
of obtaining PI addresses given current RIR policies :-)
I mean, imho we need to explain the situation a bit more in detail here.

- Section 4.2

s/addressblock/address block
s/teh/the

- Section 5

The features described in this section don't really apply to all 
multihomed configurations described in section 4. For instance, 
configuration 4.5 (using NATs) don't provide feature 5.2 (transport 
layer survivability), Moreover, multiattached networks don't obtain 
full fault tolerance against all the failures described in section 3.1. 
Additionally NAT configuration doesn't really provide much TE 
capabilities AFAICS. OTOH, NAT configuration is really simple and can 
be adopted in unmanaged environments, while BGP based configuration 
doesn't seems as simple as this, so i am not sure that the simplicity 
benefit applies to all of the configurations in the same level.
I don't know which approach to follow with this, but i am tempted to 
suggest that the NAT approach and the multiattached approach are moved 
to a later section where they are presented as "other approaches" where 
their limitations and advantages are presented.

In addition, as i understand this, the features described in this 
section are in addition to the features presented in section 3, right? 
Perhaps stating this explicitly would make it clearer

- Section 5.2

I would mention in this section that becuase the number of AS in the 
Internet and the delayed BGP convergence that it causes, this feature 
is not universal in the current Internet, i.e. that there are some 
outages that take a long time BGP to reconverge causing come TCP 
connections to fail. Perhaps quoting Labovitz work here...
another limitation here (as Iljitsch has mentioned several times by 
now) is that the current default time setting on some commercial 
routers make that BGP need 3 minutes to detect an outage, so this 
implies that it will take more than 3 min to reroute the established 
communications. Bottom line is that current multihoming solution 
doesn't really preserves all established communications always.

- Section 5.4

    The current multihoming solution places control of traffic flow in
    the hands of the enterprise responsible for the multi-homed
    interconnections with transit providers.  A single-homed customer of
    a multi-homed enterprise may vary the demand for traffic that they
    impose on the enterprise, and may influence differential traffic load
    between transit providers; however, the basic mechanisms for
    congestion control and route propagation are in the hands of the
    enterprise, not the customer.

I fail to understand this section. I mean, here we are considering only 
site multihoming, so i don't see why are relevant comments about 
clients of the multihomed enterprise. AFAIU, a multihomed end site 
don't have customers, right?
The same goes for the customer/ enterprise comments in the last sentence

Regards, marcelo

El 12/07/2004, a las 11:48, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 	
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
>
> iQA/AwUBQPJecKarNKXTPFCVEQKf9ACg8RY+xEWXhiZ1a+sTc4llwr65q+oAoNeW
> 2qZQX6T0C6UnCpSAkE32Ehx4
> =lY7m
> -----END PGP SIGNATURE-----
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 12 Jul 2004 21:35:19 +0200

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

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 Jul 2004 09:12:16 +0200

Hi!

> through the other providers, but i couldn't find it stated explicitly

I think that is what the second paragraph describes? I guess you are 
saying that it should be more clear....:-)

> the multihomed site is better off.

Hmm. True. This should refer to an advantage with the model, not for 
the network.

> true. I mean, there are two conditions here: first the primary ISP 
> must peer with the other ISP and second the primary ISP must accept 
> the announcement of shorter prefixes.

Agreed. Will add or try to re-write. I will post some proposed text 
here first.

> multihomed site changes any of the other isps, it don't have to 

True. I should add something on this as well.

> Perhaps for completeness it would good to add the definition of a 

I guess I agree.

> Perhaps it needs some rewording?

I refers to the physical network. Point-2-point links, peering point 
etc.

> IMHO this may be important when considering the capabilities of an 
> IPv6 multihoming solution. I mean, when comparing IPv4 capabilities vs 
> IPv6 capabilities we will need to go more in detail than just load 
> sharing support, i guess.

Ok, agreed.

> support is provided and its limitations could be useful (like the 
> stuff presented in section 5.3 but w.r.t policy and perhaps in a bit 
> more of detail)

I kind o agree, but then we need to be clear that we only describe 
methods that are direct results of the way the prefixes are announced. 
So that we ignore other features of BGP.

> As you mention in the introduction, a site can be multihomed, but 
> still use PA address from one of its providers, so most of these 
> benefits will not be achieved.
> multihomed. Just happens to be that being multihomed is one of the 
> ways of obtaining PI addresses given current RIR policies :-)

Hmm, I sort of see what you are saying but I am not sure how to 
describe it. I will think it over a bit and propose text.

> s/addressblock/address block

Thanks!

> full fault tolerance against all the failures described in section 
> 3.1. Additionally NAT configuration doesn't really provide much TE 
> to a later section where they are presented as "other approaches" 
> where their limitations and advantages are presented.
>

Yes. There is nothing in the document that says that all reasons that 
can be used for requiring multihoming in section 4 needs to apply to 
section 5. Section 3 is to list the high level reasons as to why 
someone might want to do multihoming, section 4 lists the possible ways 
of doing multihoming, and section 5 lists what features you _can_ have 
from multihoming as done today. If you think this needs to be made 
clearer I will try and do that.

> doesn't really preserves all established communications always.

Well. Hmm. I kind of agree. Will add.

> I fail to understand this section. I mean, here we are considering 
> only site multihoming, so i don't see why are relevant comments about 

I agree that this needs to be rewritten. What I read it as saying is 
that within an enterprise, needs for load-control will rise from 
different entities varying need for bandwidth to different destinations 
over time. But customer is not a very good description.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 14 Jul 2004 09:29:03 +0200

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?

> illuminating the big picture

Care to be a bit more specific?

> organizations which use one isp for part of their network and another 

Yes? Is this a problem?

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

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

Is "Failures signaled by routing protocols" better wording?

> failure as it is likely that bgp will continue to function in such a 

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

> - load sharing limitations aren't explained

No. Agreed.

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

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

> - who cares? only confuses the issue

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

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

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.

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

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

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 

Ok, will change.

> 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 

I don't think so...

- - kurtis -

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Jul 2004 21:24:39 +0200

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

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

More detail.

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

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

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

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

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

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

> I disagree. This is a used multihoming mechanism that is different from

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.

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

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jul 2004 11:30:46 +0200

> Brian will act as WG chair for anything that relates to this draft, I 

Well, no chair hat is on for this message.

After reading Iljitsch's & Marcelo's comments, and some side conversations,
I think we would have a much easier time with this document if section 3
(motivations for mh) was simply removed. Otherwise, we will discuss
it for ever and never converge. I suggest limiting to the description
of solutions.

> 4.5  NAT or RFC2260 based multihoming
> 
>    This last method might very well be the most commonly used method in
>    terms of volume.  Simply because this is what most residential users
>    are normally referred to.  

That may be true, but it hides the fact that NAT is also very commonly
used by enterprise networks, including some *very* big ones. It's the really
easy way to avoid advertising a large number of specifics when the same
enterprise is connected to the Internet at a large number of points.

> 6.1  Scalability
> 
>    Current IPV4 multihoming practices contribute to the significant
>    growth currently observed in the state held in the global
>    inter-provider routing system; 

With an important exception - NAT based mh specifically doesn't do this
(and probably explains why there has been significant growth in mh without
a corresponding explosion in BGP4).

     Brian

---

From: Jeff Williams <[email-masked]>
Date: Thu, 22 Jul 2004 05:00:42 -0700

Brian and all,

  Well really all this won't matter all that much as IPv8 and IPv9 work
very smoothly with NAT's as well as ENUM.

> a corresponding explosion in BGP4).

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 Jul 2004 12:23:22 +0200

(chair-hat on)

> very smoothly with NAT's as well as ENUM.

I suggest you take _that_ discussion to the multi8 and multi9 lists.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 23 Jul 2004 16:33:42 +0200

> it for ever and never converge. I suggest limiting to the description

I agree with this (obviously). If someone _disagrees_, please let me 
know. I guess we will ask this question in San Diego as well.

> enterprise is connected to the Internet at a large number of points.

Ok, I guess I should add that.

> a corresponding explosion in BGP4).

Ok, and for consistency I should add a comment on this.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 23 Jul 2004 16:29:31 +0200

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

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

>    which are part of the Internet.

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.

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

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

> belong in a document like this.

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

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

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

> document applies to this type of multihoming.

That might be true :-)

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

> RFC 1998 provides a cleaner mechanism to do something similar to what 

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.

> this information but written for an IETF audience would be useful in 

Ok, see comments above on the introduction text.

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

- - kurtis -