Subject: a response to "A Simple Solution for IPv6 Multihoming"

From: Ben Black <[email-masked]>
Date: Tue, 7 Sep 1999 02:54:26 -0700

I'm not familiar with the workings of the IPng group, so please let me
know if this violates any procedural or etiquette boundaries.  I've
just finished reading several of the IPv6 drafts and hoped my thoughts 
on one recently submitted draft might be of use.

IPv6 multihoming is a thorny problem and I don't pretend to have a
solution.  I don't know that there is one possible as the network layer.

Ben

--

The IPv6 address allocation and routing hierarchy defined in [AGGR]
and [ARCH] poses serious difficulties for implementation of multihomed 
networks.  Rather than the usual practice of allocating a single
prefix, or set of prefixes for multiple networks, network operators
must either home to a single provider or allocate multiple prefixes
for the same set of nodes.  The draft "A Simple Solution for IPv6
Multihoming" [SMPL] profers an approach to achieving multihomed
networks within the constraints of the IPv6 route aggregation
hierarchy.

Unfortunately, the fundamental assumptions regarding the purposes of
multihoming lead the author of the document astray.  The main goals
of multihoming are: redundancy in the face of link and/or network
failure, load balancing, and performance improvement.  Of these, only
load balancing is directly addressed, and even then with limited
success.  Similarly, although improving performance by connecting
directly to networks which are common destinations is effective, the
document does not provide options for accessing content providers
accessible through other networks.

A selection of quotes from the document will help in clarifying its
shortcomings as a solution to multihoming within the existing,
documented IPv6 routing framework.

From section 2 (Proposal):

                           ISP-3 ---- ISP-4
                             |      /  |
                             |    /    |
                             |  /      |
                           ISP-1 ---- ISP-2
                    link-1   \          /  link-2
                              Customer-A

   A multi-homed customer will designate a primary ISP and receive IP
   address from its primary ISP's IPv6 aggregation block. In this
   example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A
   to the customer. Customer-A will advertise addr-1-A to ISP-1 and
   ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to
   ISP-1 only. ISP-1 will, of course, advertise its own aggregation
   Addr-1 to the entire Internet.

It is clear from this description that the only redundancy provided
with this solution is for the customer links (link-1 and link-2) and
not for the ISPs themselves.  Specifically, if ISP-1 suffers from a
failure within the POP to which link-1 terminates, whether as an
isolated failure or a more extensive failure within ISP-1, then
Customer-A is no longer able to maintain connectivity despite their
possession of a perfectly good alternate path through ISP-2.  From an
engineering perspective, no robustness has been gained through this
multihoming which could not be gained more simply with multiple links
to ISP-1.

From section 2 (Proposal):

   For inbound traffic to Customer-A, traffic will first be forwarded to
   ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will
   then forward the traffic destined to Customer-A via its connection to
   ISP-2 and/or its direct link to customer-A, according to certain
   polices. Most common policy would be the use of the shortest exit. By
   using both connections to forward traffic to Customer-A, load sharing
   is achieved.

From this statement it is unclear exactly how inbound load balancing
is to be achieved.  Is the author suggesting use of the (rather
troublesome) concept of eBGP multipath?  In the topology described in
the diagram above, implementation of a load sharing mechanism across
link-1 and link-2 would be a decidedly non-trivial matter.  Again,
given the lack of redundancy outlined above, it would be far more
efficient for Customer-A to simply purchase multiple links to ISP-1.

Additionally, Customer-A must now depend heavily on the connectivity
between ISP-1 and ISP-2.  Often, links to multiple providers are
purchased specifically to avoid traffic crossing these (often
congested) peerings.

From Section 4 (Concerns):

      - The primary ISP of a multihoming customer (such as ISP-1 in the
      example) would need to do more work in terms of distributing the
      traffic among other connected ISPs and the customer link.  This
      can be done using BGP policy (BGP community) and using shortest
      exit. It will also carry more traffic for the customer. However,
      this is a value added service to the customer and the primary ISP
      can charge more fees for such services.

Stating that the primary ISP "would need to do more work" is putting
the problem a bit lightly.  The addition of references to BGP policies 
and BGP communities does little to clarify how exactly the author
believes traffic could effectively be distributed.

From Section 4 (Concerns):

      - The primary ISP is the sole interface for the multihomed
      customer to the Internet other than the ISPs the customer has
      directly connection with. Outages such as one between ISP-1 and
      ISP-4 would impact the reachability from customers of ISP-4 to
      Customer-A even though ISP-2 still has good connection to ISP-4.
      However, if the primary ISP is a good quality ISP, this sort of
      situation should happen rarely. The reason is that it's common
      practice that an ISP, especially good quality ISP, has multiple
      connections to other big ISPs at different geographical locations.
      Good quality ISPs also have robust network design to prevent any
      failure to impact the whole network. Choosing a good quality and
      robust ISP as primary ISP is a good practice.

This is really the crux of the problem with the solution put forth in
the document.  The assumption that a given ISP will never have
failures, or that rare failures are acceptable to customers who
multihomed for redundancy, is simply not valid from an engineering
perspective.  If the primary goal of multihoming were load sharing,
this solution would provide one, potentially very complicated,
answer.  However, the issue of multihoming for redundancy is totally
ignored, drawing into question the need for a second ISP in the
equation at all.  Why not simply purchase additional bandwidth from
the same ISP?

From Section 4 (Concerns):

   It is desirable to have solution which provides perfect redundancy
   and, at the same time, simplicity to scale management and operation.
   In the absence of a perfect solution, the trade-off needs to be made.
   The author believes that it is very important that the solution has
   to be simple and manageable. Manageability should be the top
   consideration.

If manageability of the solution is to be the top consideration, the
response put forward does not measure up.  In the name of avoiding
routing table growth the author has suggested adding significant
complexity to the configuration and management of multihomed customers
without showing any benefit for the effort.

An area not addressed at all in the document is that of multihoming
for access to networks attached to a given ISP, rather than access to
that ISP.  For example, using the diagram above, if Customer-A
purchased connectivity to ISP-2 because ISP-2 had better connectivity
to ISP-4, then the offered multihoming solution is of no use.  ISP-4
will never see reachability to Customer-A via ISP-2.

The primary lesson of the draft proposal is that the proposed, forced
aggregation hierarchy places sever restrictions upon the engineering
of reliable, high poerformance networks.  To multihome effectively, a
network operator must somehow qualify as a "long-haul provider" or
other entity appropriate for allocation of its own address space.  In
this author's  opinion, the current IPv6 addressing architecture
creates an environment which provides scalability of the global
routing table at the expense of any real hope for redundancy through
multihoming.

Solutions which avoid the use of multihoming with a single address
space are possible and offer more hope for a robust network than those 
currently proposed.

REFERENCES

   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
             Aggregatable Global Unicast Address Format", RFC 2374, July
             1998.

   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
             RFC 2373, July 1998.

   [SMPL]    Yu, J., "A Simple Solution for IPv6 Multihoming",
             draft-yu-simple-ipv6multihoming-00.txt, August 1999.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Otel Florian-Daniel <[email-masked]>
Date: Tue, 7 Sep 1999 17:32:36 +0200 (MET DST)

Hello everybody,

I have a rather delicate question to ask (maybe a little bit
off-topic) so appologies in advance if that is the case. I'm intrested
if someone can tell me where i can find some information
about _official_ vendor support for IPv6. I'm intrested especially about
cisco and Microsoft.

Thanks in advance,

Florian.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 1999 13:54:08 -0500

Ben,

I can't see anything in your arguments that suggests any realistic,
deployable alternative to the current proposal, unless you can explain 

> space are possible and offer more hope for a robust network than those

   Brian

---

From: Ben Black <[email-masked]>
Date: Mon, 13 Sep 1999 13:27:41 -0700

I think the only viable solution, in the face of the constraints placed
on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260
and further detailed for IPv6 by itojun.  The "current" proposal is not
viable at all, despite some minor similarities with RFC2260.

Although it would be rather involved, I can see application of tunnel
networks overlayed on a large scale as a solution allowing an ISP to
provide backup for another ISP.  I don't really think it is attractive
because of the significantly higher complexity and administrative
overhead compared to RFC2260 and itojun's proposal.

Ben

-- 
 --b

---

From: Jeff Williams <[email-masked]>
Date: Mon, 13 Sep 1999 14:40:40 +0100

Ben, Brian and all,

  I am in agreement with Ben here.  Althoughh we have had great
success with our "Interface Facility" I think Ben is essentially
correct here.  The need for multihoming is here for awhile anyway.

> > > solution.  I don't know that there is one possible as the network layer.

Regards,

--
Jeffrey A. Williams
Spokesman INEGroup (Over 95k members strong!)
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [email-masked]
Contact Number:  972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 1999 17:43:17 -0500

OK, there is clearly a problem with the way this has been
written up. Those of us who attended the second design team meeting
on this before Oslo were, I think, pretty clear that the RFC 2260
approach was a required part of the total solution (i.e. in my
mind at least, the "simple solution" is by no means a
complete proposal). 

Thanks for the clarification

  Brian

---

From: Peter Tattam <[email-masked]>
Date: Tue, 14 Sep 1999 10:23:26 +1000 (EST)

I know I have said this over and over, but I am very concerned that the Ipv6
team may be painting themselves into a corner over this issue.  None of the
proposed solutions to Ipv6 multihoming sit easy with me.  The issue is
primarily a conceptual one based on the assumption that aggregation and CIDR
are the best way to deal with the size & complexity of the internet.  I know
there have been many hand waving solutions put forth and they have all been
generally discounted by the notion that "the devil is in the details".  What I
believe we are facing here is a crisis in the design of the Internet similar to
that faced by hardware designers of computers back in the '70s. Around that
time, there were many innovations like paged virtual memory, and filing systems
that being progressed from fixed file size allocation to dynamic sized
allocation and so forth.  Those innovations were often brought out either
through serious academic research or by private research within companies that
had sufficient clout in the industry to forge a direction.

I wish some computer scientists would add their weight to this problem, because
I believe the answer may lay there.   Let us not ignore the lessons that
history has shown us.   Some of us in key industry positions recognize that
there is a problem and while accusations have been made that certain prominent
ones have been stalling Ipv6, it may well not be without cause.

For me personally, I believe the answer lies in considering the default free
zone as a cloud and using alternative routing techniques like route labelling 
to propagate data, thus allowing *all* addresses to be relatively portable.  It
is regretable that a lot of work has gone into dynamic renumbering of sites,
but the reality may be that not too many people outside the Ipv6 scene will
want the facility of rapid site renumbering.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 1999 08:27:58 -0500

Peter,

I submit that you are asking for magic.

The reason we need aggregatable addresses is that we simply don't
know any other routing system that scales to a few billion nodes
and to backbone trunks at WDM speeds for packet-switched networks.

> to propagate data, thus allowing *all* addresses to be relatively portable.

This certainly sounds like magic to me.

   Brian

---

From: Peter Tattam <[email-masked]>
Date: Wed, 15 Sep 1999 01:13:12 +1000 (EST)

> > to propagate data, thus allowing *all* addresses to be relatively portable.

I made a slight error.  I should have said all sites, but you get the idea.

> This certainly sounds like magic to me.

I could quote a well known science fiction writer's comment on magic...

>    Brian

Curiously, the concepts being raised have not necessarily originated by myself.
Other's have come to vaguely similar conclusions independently.  When scientifc
breakthroughs occur, they often spontaneously occur in independent camps.

While I don't predict a breakthrough in the immediate future, the possibility
of some new technique or algorithm being born that could manage such a cloud
*may* still eventuate.  It might seem like magic to us at this point in time,
but then, I have seen so many revolutions in computer science over the past 20
years that I could not even have imagined.  One small example of this would be
the latest techniques in audio compression using adaptive psycho acoustic
modelling which enables compression of CD quality audio to 128Kbps.  This would
have been unimaginable say 10(?) years ago.  Even the possibility of digital
audio recording onto hard disk systems on a home system was unimaginable 20
years ago due to the sheer cost of doing it.

You will have to pardon me, I am not a conventional thinker.  I dare to dream
and try to be a visionary.  I may be living in fantasy land, but when my
intuition grabs hold of something it is often hard to let go.  I will continue
to cogitate on the problem to see where it leads.  I certainly may not have the
solution yet, but I sense I could be heading in the right direction.  

I might be bold enough to add that I am also a spiritual person, and that I
have relied on divine inspiration on many occasions during my working life. 
There have been many occasions where I have been totally stumped for days, even
weeks in resolving extremely stubborn and elusive bugs in some of the real time
operating systems that I have built.  A quiet prayer has often resulted in
major breakthroughs in such situations which when I reflect upon later make me
realize that there was *no* way possible to resolve that bug on purely
analytical grounds, or using my own intellect.  I now treat such activity as
normal, and even essential for me to achieve the desired quality of my software
& have learned to trust that inspiration when it is needed. Perhaps this is one
of those times.  That others share the restlessness over the current issue
indicates that there may indeed be a higher intelligence prompting the issue.

I will leave you with a quote which I am not sure where was derived from.
The quote was on the wall of the electronics workshop at my previous
employment, the University of Tasmania, Psychology department.

"The impossible we do at once, miracles take a little longer"

That was the climate which was expected of me as the norm in my formative years
as a computer programmer. 

Peter

---

From: "Robert J. Rockell" <[email-masked]>
Date: Tue, 14 Sep 1999 12:10:56 -0400 (EDT)

I'll be the first to admit that the "simple solution" is one that has some
policy to work out, but I want to point out that it does add to the otehr
proposed solutions.

RFC2260 has two management holes that may be big from the operatioal
standpoint of a TLA>

1. When a route gets injected from a downstream due to their other
provider's link going down, how does the provider(s) who accept the
non-aggregate know when the other provider gets the line back up?  This one
is important, as the control of aggregation is removed from the people who
need to DO the aggregating, the core.

2. How can we implement in such a way that we KNOW that the downstream will
"play nice", and act per 2260? Backbone providers will need to have some way
to ensure that the downstream is only doing this during an outage. We know
that this is sometimes not the case today, with other issues (otherwise we
woudl all do AS filtering for EBGP...; it is easier after all).

#3 while RFC2260, section 5.2 attempts to look at this, I think there will be
some major design limitations asscociated. (details excluded).

The "simple solution" proposal minimizes the management woes of #1 and #2.
It at least sets expectations that a backbone designer can work with, and
attempt to implement in a way that is scalable. Although there are
management problems with the "simple solution" as well, I think it deserves
some sort of trial, perhaps on the 6bone. 

The possibility of an efficient community-tagging policy is one way that the
simple solution can work, and still provide some scalability (though not as
much as we all would like, perhaps).

Now the problem, with the "simple solution" instead of #1 and #2 above, becomes:

-how do we know that the other provider is only announcing this route back
to us, and not to everyone, breaking aggregation?

I would argue that this is less to worry about than above, in that I would
put more trust into the BGP policy of a backbone provider than a downstream
to aggregate and export the correct routes at the right locations. The
problem, however, still remains; management of one's own TLA;
it just shifts a bit.

In regards to Ben's comments, I would argue that load-balancing is not
addressed, but the redundancy is.  If the subnet (to use a
soon-to-be-outdated-term) of the TLA is announced back to the TLA,
redundancy is there with the "simple solution", but the load-balancing
becomes problematic.  One can no longer use AS padding, for instance, for
multi-homing load-balancing. The redundancy is there; the routing just gets
messy. If a t-1 goes down, then the packets will go to the other provider,
albeit via the primary provider, so long as a peering between the two exists
(which in itself is a whole other issue).
However, if the whole backbone goes down, then the redundancy would be
removed (but if a whole backbone goes down today, we all feel it, regardless
of where we home; remember the various "internet drains" that occured over
the last couple of years; I won't mention AS numbers). 

As I haven't seen any implementations of 2260 working, and this one actually
is something that can be set up, I would like to test this. If anyone who
has 6bone transit woudl be interested in testing, I say we give it a whirl,
and see how it scales in the small picture, before we cast it away for the
big picture totally.

I apologize in advance if these opinions are redundant, or I missed
something here, but I am afraid we may be throwing somethign aside which may
at the very least provide more insight into how to tackle this most
difficult and important problem of the protocol.

Also, in regards to how this can be done ( deploy the "simple solution"; I
don't know if this is the right place, but I believe it is possible, even
with limited implementations of IPv6 that we have, to make this work, if we
ignore some scaling problems that aren't there yet on the 6bone).

Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833
Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?

On Mon, 13 Sep 1999, Brian E Carpenter wrote:

->OK, there is clearly a problem with the way this has been
->written up. Those of us who attended the second design team meeting
->on this before Oslo were, I think, pretty clear that the RFC 2260
->approach was a required part of the total solution (i.e. in my
->mind at least, the "simple solution" is by no means a
->complete proposal). 
->
->Thanks for the clarification
->
->  Brian
->
->Ben Black wrote:
->> 
->> I think the only viable solution, in the face of the constraints placed
->> on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260
->> and further detailed for IPv6 by itojun.  The "current" proposal is not
->> viable at all, despite some minor similarities with RFC2260.
->> 
->> Although it would be rather involved, I can see application of tunnel
->> networks overlayed on a large scale as a solution allowing an ISP to
->> provide backup for another ISP.  I don't really think it is attractive
->> because of the significantly higher complexity and administrative
->> overhead compared to RFC2260 and itojun's proposal.
->> 
->> Ben
->> 
->> On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote:
->> > Ben,
->> >
->> > I can't see anything in your arguments that suggests any realistic,
->> > deployable alternative to the current proposal, unless you can explain
->> > in concrete detail what this means:
->> >
->> > > Solutions which avoid the use of multihoming with a single address
->> > > space are possible and offer more hope for a robust network than those
->> > > currently proposed.
->> >
->> >    Brian
->> >
->> > Ben Black wrote:
->> > >
->> > > I'm not familiar with the workings of the IPng group, so please let me
->> > > know if this violates any procedural or etiquette boundaries.  I've
->> > > just finished reading several of the IPv6 drafts and hoped my thoughts
->> > > on one recently submitted draft might be of use.
->> > >
->> > > IPv6 multihoming is a thorny problem and I don't pretend to have a
->> > > solution.  I don't know that there is one possible as the network layer.
->> > >
->> > > Ben
->> > >
->> > > --
->> > >
->> > > The IPv6 address allocation and routing hierarchy defined in [AGGR]
->> > > and [ARCH] poses serious difficulties for implementation of multihomed
->> > > networks.  Rather than the usual practice of allocating a single
->> > > prefix, or set of prefixes for multiple networks, network operators
->> > > must either home to a single provider or allocate multiple prefixes
->> > > for the same set of nodes.  The draft "A Simple Solution for IPv6
->> > > Multihoming" [SMPL] profers an approach to achieving multihomed
->> > > networks within the constraints of the IPv6 route aggregation
->> > > hierarchy.
->> > >
->> > > Unfortunately, the fundamental assumptions regarding the purposes of
->> > > multihoming lead the author of the document astray.  The main goals
->> > > of multihoming are: redundancy in the face of link and/or network
->> > > failure, load balancing, and performance improvement.  Of these, only
->> > > load balancing is directly addressed, and even then with limited
->> > > success.  Similarly, although improving performance by connecting
->> > > directly to networks which are common destinations is effective, the
->> > > document does not provide options for accessing content providers
->> > > accessible through other networks.
->> > >
->> > > A selection of quotes from the document will help in clarifying its
->> > > shortcomings as a solution to multihoming within the existing,
->> > > documented IPv6 routing framework.
->> > >
->> > > >From section 2 (Proposal):
->> > >
->> > >                            ISP-3 ---- ISP-4
->> > >                              |      /  |
->> > >                              |    /    |
->> > >                              |  /      |
->> > >                            ISP-1 ---- ISP-2
->> > >                     link-1   \          /  link-2
->> > >                               Customer-A
->> > >
->> > >    A multi-homed customer will designate a primary ISP and receive IP
->> > >    address from its primary ISP's IPv6 aggregation block. In this
->> > >    example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A
->> > >    to the customer. Customer-A will advertise addr-1-A to ISP-1 and
->> > >    ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to
->> > >    ISP-1 only. ISP-1 will, of course, advertise its own aggregation
->> > >    Addr-1 to the entire Internet.
->> > >
->> > > It is clear from this description that the only redundancy provided
->> > > with this solution is for the customer links (link-1 and link-2) and
->> > > not for the ISPs themselves.  Specifically, if ISP-1 suffers from a
->> > > failure within the POP to which link-1 terminates, whether as an
->> > > isolated failure or a more extensive failure within ISP-1, then
->> > > Customer-A is no longer able to maintain connectivity despite their
->> > > possession of a perfectly good alternate path through ISP-2.  From an
->> > > engineering perspective, no robustness has been gained through this
->> > > multihoming which could not be gained more simply with multiple links
->> > > to ISP-1.
->> > >
->> > > >From section 2 (Proposal):
->> > >
->> > >    For inbound traffic to Customer-A, traffic will first be forwarded to
->> > >    ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will
->> > >    then forward the traffic destined to Customer-A via its connection to
->> > >    ISP-2 and/or its direct link to customer-A, according to certain
->> > >    polices. Most common policy would be the use of the shortest exit. By
->> > >    using both connections to forward traffic to Customer-A, load sharing
->> > >    is achieved.
->> > >
->> > > >From this statement it is unclear exactly how inbound load balancing
->> > > is to be achieved.  Is the author suggesting use of the (rather
->> > > troublesome) concept of eBGP multipath?  In the topology described in
->> > > the diagram above, implementation of a load sharing mechanism across
->> > > link-1 and link-2 would be a decidedly non-trivial matter.  Again,
->> > > given the lack of redundancy outlined above, it would be far more
->> > > efficient for Customer-A to simply purchase multiple links to ISP-1.
->> > >
->> > > Additionally, Customer-A must now depend heavily on the connectivity
->> > > between ISP-1 and ISP-2.  Often, links to multiple providers are
->> > > purchased specifically to avoid traffic crossing these (often
->> > > congested) peerings.
->> > >
->> > > >From Section 4 (Concerns):
->> > >
->> > >       - The primary ISP of a multihoming customer (such as ISP-1 in the
->> > >       example) would need to do more work in terms of distributing the
->> > >       traffic among other connected ISPs and the customer link.  This
->> > >       can be done using BGP policy (BGP community) and using shortest
->> > >       exit. It will also carry more traffic for the customer. However,
->> > >       this is a value added service to the customer and the primary ISP
->> > >       can charge more fees for such services.
->> > >
->> > > Stating that the primary ISP "would need to do more work" is putting
->> > > the problem a bit lightly.  The addition of references to BGP policies
->> > > and BGP communities does little to clarify how exactly the author
->> > > believes traffic could effectively be distributed.
->> > >
->> > > >From Section 4 (Concerns):
->> > >
->> > >       - The primary ISP is the sole interface for the multihomed
->> > >       customer to the Internet other than the ISPs the customer has
->> > >       directly connection with. Outages such as one between ISP-1 and
->> > >       ISP-4 would impact the reachability from customers of ISP-4 to
->> > >       Customer-A even though ISP-2 still has good connection to ISP-4.
->> > >       However, if the primary ISP is a good quality ISP, this sort of
->> > >       situation should happen rarely. The reason is that it's common
->> > >       practice that an ISP, especially good quality ISP, has multiple
->> > >       connections to other big ISPs at different geographical locations.
->> > >       Good quality ISPs also have robust network design to prevent any
->> > >       failure to impact the whole network. Choosing a good quality and
->> > >       robust ISP as primary ISP is a good practice.
->> > >
->> > > This is really the crux of the problem with the solution put forth in
->> > > the document.  The assumption that a given ISP will never have
->> > > failures, or that rare failures are acceptable to customers who
->> > > multihomed for redundancy, is simply not valid from an engineering
->> > > perspective.  If the primary goal of multihoming were load sharing,
->> > > this solution would provide one, potentially very complicated,
->> > > answer.  However, the issue of multihoming for redundancy is totally
->> > > ignored, drawing into question the need for a second ISP in the
->> > > equation at all.  Why not simply purchase additional bandwidth from
->> > > the same ISP?
->> > >
->> > > >From Section 4 (Concerns):
->> > >
->> > >    It is desirable to have solution which provides perfect redundancy
->> > >    and, at the same time, simplicity to scale management and operation.
->> > >    In the absence of a perfect solution, the trade-off needs to be made.
->> > >    The author believes that it is very important that the solution has
->> > >    to be simple and manageable. Manageability should be the top
->> > >    consideration.
->> > >
->> > > If manageability of the solution is to be the top consideration, the
->> > > response put forward does not measure up.  In the name of avoiding
->> > > routing table growth the author has suggested adding significant
->> > > complexity to the configuration and management of multihomed customers
->> > > without showing any benefit for the effort.
->> > >
->> > > An area not addressed at all in the document is that of multihoming
->> > > for access to networks attached to a given ISP, rather than access to
->> > > that ISP.  For example, using the diagram above, if Customer-A
->> > > purchased connectivity to ISP-2 because ISP-2 had better connectivity
->> > > to ISP-4, then the offered multihoming solution is of no use.  ISP-4
->> > > will never see reachability to Customer-A via ISP-2.
->> > >
->> > > The primary lesson of the draft proposal is that the proposed, forced
->> > > aggregation hierarchy places sever restrictions upon the engineering
->> > > of reliable, high poerformance networks.  To multihome effectively, a
->> > > network operator must somehow qualify as a "long-haul provider" or
->> > > other entity appropriate for allocation of its own address space.  In
->> > > this author's  opinion, the current IPv6 addressing architecture
->> > > creates an environment which provides scalability of the global
->> > > routing table at the expense of any real hope for redundancy through
->> > > multihoming.
->> > >
->> > > Solutions which avoid the use of multihoming with a single address
->> > > space are possible and offer more hope for a robust network than those
->> > > currently proposed.
->> > >
->> > > REFERENCES
->> > >
->> > >    [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
->> > >              Aggregatable Global Unicast Address Format", RFC 2374, July
->> > >              1998.
->> > >
->> > >    [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
->> > >              RFC 2373, July 1998.
->> > >
->> > >    [SMPL]    Yu, J., "A Simple Solution for IPv6 Multihoming",
->> > >              draft-yu-simple-ipv6multihoming-00.txt, August 1999.
->> > >
->> > > --------------------------------------------------------------------
->> > > IETF IPng Working Group Mailing List
->> > > IPng Home Page:                      http://playground.sun.com/ipng
->> > > FTP archive:                      ftp://playground.sun.com/pub/ipng
->> > > Direct all administrative requests to [email-masked]
->> > > --------------------------------------------------------------------
->> 
->> --
->>  --b
->--------------------------------------------------------------------
->IETF IPng Working Group Mailing List
->IPng Home Page:                      http://playground.sun.com/ipng
->FTP archive:                      ftp://playground.sun.com/pub/ipng
->Direct all administrative requests to [email-masked]
->--------------------------------------------------------------------
->

---

From: Bradley Reynolds <[email-masked]>
Date: Tue, 14 Sep 1999 12:28:00 -0400 (EDT)

> and to backbone trunks at WDM speeds for packet-switched networks.
the function of address aggregation is independent of this imposed
aggregation hierarchy.  simply take away the brain damaged aggregation
mandates and allow service providers to aggregate their address space
as deemed appropriate.  until the multihoming problem is fixed, i don't
understand further progress in the ipv6 wg.  

BR

---

From: [email-masked]
Date: Wed, 15 Sep 1999 01:32:43 +0900

>RFC2260 has two management holes that may be big from the operatioal

	RFC2260 comes with two proposal, section 5.1 and 5.2.

	Your points (1 and 2) are about section 5.1 of RFC2260.  I believe
	this is not very suitable to IPv6.  My draft (draft-itojun-ipv6-2260-00)
	tries to understand section 5.2 of RFC2260, in context of IPv6.
	Please take a look and give me comments so that we can talk about
	it better in Tokyo interim meeting.

itojun

---

From: Bradley Reynolds <[email-masked]>
Date: Tue, 14 Sep 1999 13:23:48 -0400 (EDT)

> addressed, but the redundancy is. 

try again

you want to advertise a prefix through diverse administrative domains so
that issues in one administrative domain will not affect your
reachability.

this 'simple solution' is no solution for said redundancy issue.  it is
not even a hack or a kludge (both of those seem to fix the problem, even
if  they are ugly)

there are two seperate issues in your post.  1. possible deficiencies in  
2260 2. something related to the yu id.

possible deficiencies in 1 do not make 2 any more acceptable.

BR

---

From: Ben Black <[email-masked]>
Date: Tue, 14 Sep 1999 11:43:56 -0700

Just to set our terms up front:

	The "simple solution" is Jessica Yu's draft.
	The "complex solution" RFC2260/itojun proposal.

Since I don't believe Yu's draft actually solves any problems, I don't
really agree with these definitions, but they will allow less confusion
about which draft I mean below.

> RFC2260 has two management holes that may be big from the operatioal

[ points 1 and 2 deleted because they are not relevant to the complex solution]

> some major design limitations asscociated. (details excluded).

Unfortunately, it is just those excluded details which are relevant here.

> to us, and not to everyone, breaking aggregation?

The other problem becomes:

- why am I paying for this second link when I can't send traffic over it if
  my primary ISP fails?

> difficult and important problem of the protocol.

A key point you may have missed from the simple solution:

"A multi-homed customer will designate a primary ISP and receive IP
address from its primary ISP's IPv6 aggregation block."

What this means is that, since the *single* prefix used by the customer can
only be advertised by the *primary* ISP into the global backbone, if that ISP
has a failure (AS0, sun spots, fiber cut, whatever), the customer is 
completely unreachable, even though they have a viable, alternate path through
their secondary ISP.  If only they had address space from that ISP.  Which
they do in the complex solution.

This doesn't even begin to address the problem of homing to more than 2
providers.
 
> ignore some scaling problems that aren't there yet on the 6bone).

Sure, you could deploy it, but realize the simple solution is 50% of the
complex solution.  Add a second prefix and a second tunnel and it is
magically upgraded to a system which actually *can* survive the failure of
an upstream.

Ben

-- 
 --b

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 1999 16:45:09 -0500

Peter,

Sure, if someone makes a breakthrough that will be great. I haven't
seen it yet though, and people have been looking for many years.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Sep 1999 16:42:45 -0500

Bradley Reynolds wrote:
> as deemed appropriate.  

Can you please explain this? Where is the document that describes
how aggregation is done without aggregatable addresses?

  Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Sep 1999 15:14:30 -0700

>seen it yet though, and people have been looking for many years.

I would add that if a breakthrough happens we should be able to use it to
route the IPv6 aggregatable addresses and then start assigning addresses
under some new scheme.  We should not hold up the current work waiting for
a breakthrough.

I hope a breakthrough does happen.  Route aggregation has lots of problems
(we can make a long list), but it is the only thing we have available today
that we are reasonably confident has the needed scaling properties.

Bob

---

From: Bradley Reynolds <[email-masked]>
Date: Tue, 14 Sep 1999 19:08:30 -0400 (EDT)

> how aggregation is done without aggregatable addresses?
hmm.. core bgp tables are growing linearly and i haven't seen
a document describing an IPv4 aggregation hierarchy.  how can that be?

BR

---

From: Peter Tattam <[email-masked]>
Date: Wed, 15 Sep 1999 15:11:33 +1000 (EST)

> seen it yet though, and people have been looking for many years.

I put my thinking cap on last night..

I have a very simple proposal which I would humbly ask be given serious
consideration.  I did raise a version of it before with Jim but he felt it
would get the thumbs down.  This is not exactly the same, but draws also on
ideas from Dan's proposal, so some of the credit I owe to Dan.

My proposal goes thus.

1. Keep the existing CIDR allocation exactly as it is. (not the routing
policy, this is dealt with later).

2. sacrifice one bit of the flow label to define a routing label.  This would
leave 31 bits available for a routing ID.

3.  Use sparingly those 31 bits for a heiarchical routing tree.

4a.  Have an extension to the DNS system which defines the *current* mapping of
the hostname to routing ID.  It is a host's responsibilty to place the correct
routing ID in the packet prior to transmission.  This is no different in
security level to existing DNS practice.  The DNS would need interaction to
reflect the dynamic nature of routing cloud changes.  DDNS is I believe
suitable for this purpose.

4b. An alternative to DDNS would be multiple RRs combined with stale
route detection to trigger automatic replacement of the routing ID at the
originating host.

5.  The non-site routing cloud then uses this routing ID for interdomain
routing instead of the regular dest address.  Current practice as used in the
6bone for aggregation.

I believe I can sufficiently flesh out a full implementation of this on paper
if there is enough interest, but I won't bother if the cost of sacrificing one
bit of flow label, altering routing practice, and extending Ipv6 stacks to
cope with the changes are impractical.

Peter

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 1999 09:35:22 -0500

Peter,

Please don't treat this as a brush-off; I don't consider
myself competent in this area.

One recommendation of the July IAB workshop is that work
on a "next generation" routing system on should be pursued
in the IRTF routing research group (i.e. by people with
routing clue). I think your idea fits there, not here.

  Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Sep 1999 16:30:19 -0700 (PDT)

> leave 31 bits available for a routing ID.

NIT: the flow label is 20 bits - not 32.
(4 bits version, 8 bits traffic class, 20 bits flow label).

But one of the fundamental issues is that you only propose a routing
label for the destination. This implies:
 - non-site routers that need to send ICMP errors (e.g. for path mtu discovery
   or just regular unreachable messages) do not know the source routing
   label. Are they supposed to do a DNS lookup to somehow determine this?
 - the destination doesn't know the source routing label. This implies that
   either the stack (TCP before returning the SYN|ACK) or the (UDP)
applications
   need to do some magic DNS lookup to map from the source IP address to
   the source routing label. I'm sure this can be done. But if nothing else
   it introduces a new class of denial of service attacks.
   For instance you can send UDP packets with bogus IP source addresses
   to the IKE/isakmp port and tie up some amount of resources waiting
   for the DNS lookup to time out.

IMHO as long as we have a datagram model we need to have both a source
and destination "routing label" in the packet.

Once you have that there are the issues about the security implications
of using the source routing label for return traffic as outlined in
draft-ietf-ipngwg-esd-analysis-04.txt.
Some people argue that those issues can be removed if we require IPsec
(AH or ESP) on all IP packets.

> 4a.  Have an extension to the DNS system which defines the *current* mapping
> of the hostname to routing ID.  It is a host's responsibilty to place the
> correct routing ID in the packet prior to transmission.  This is no
> different in security level to existing DNS practice.  The DNS would need
> interaction to reflect the dynamic nature of routing cloud changes.  DDNS is
> I believe suitable for this purpose.

How would the host know to ask the DNS for a new routing label?
Are you assuming ICMP unreachable messages will trigger this?
What if unreachables are discarded as is done in many IPv4 firewalls today?

  Erik

---

From: Peter Tattam <[email-masked]>
Date: Thu, 16 Sep 1999 18:24:53 +1000 (EST)

Thank you for giving it the time.  My answers interspersed.

> (4 bits version, 8 bits traffic class, 20 bits flow label).

Oops. <Red face> Sorry about that.  The idea remains essentially the same.  19
bits is still possible given aggressive conservation of bits, and also given
that the A-S number is currently still being kept artificially at 16 bits. At
the expense of losing routing heirachy, the A-S number could be encoded here,
but I have not yet considered this.  A few months ago I also scratchpadded a
binary tree style of dynamic address aggregation management which could be used
to get the most efficient use of bits.  A later I-D also proposed something
there too.   As the basic idea is to keep core routing tables relatively
bounded, I think it would still pass the test.  As it is a scarce resource, it
would be subject to economic explotiation if not regulated correctly.  A-S
numbers have escaped so far, but this could not be guarenteed in the future.

>    for the DNS lookup to time out.

True...  might I be permitted to change references of "DNS" to "Router Label
Lookup Protocol" for the continued purpose of this discussion.  I also
neglected to consider lookups based on address rather than name, but the
concept remains virtually the same.  If we need two addresses, then we would
have to a) steal bits from somewhere else, b) extend the header or c) use
option headers?.  Neither of these is desirable..

a) steal bits from the addresses...  breaks TCP/UDP checksum model.

b) not possible because that would have far too wide reaching implications.

c) possible, but adds extra bulk.

A thought occurs to me that one would then also lose the benefit of the dynamic
updates necessary to support multihoming if this happened.  The RLLP would need
to be designed in such a way that a) it only works on a restricted part of the
IPv6 address, and b) returns a undefined answer rapidly.  To do this would
probably require caching substantial parts of routing map tree, but since we
are talking non-router technology, this might scale better with technology
advances.

> and destination "routing label" in the packet.

Granted for the reasons you outlined.  

> (AH or ESP) on all IP packets.

The message I am getting is that anything that separates end point indentifiers
from routing identifiers will always have security implications like hijacking
and man in the middle attacks.  Is this axiomatic?

> What if unreachables are discarded as is done in many IPv4 firewalls today?

Very good point.  It could be solved by mandating that the routing cloud honour
these unreachable messages and doing the lookups at the edge of the clouds
rather than the hosts.  This would then degenerate to the classic route
labelling solutions which have already been discussed.  Doing lookups at the
edges also solve the need for srce & dest routing labels. However I would have
to concede that it would be too expensive to do this lookup for each packet. 
It is convenient to push this load back to the hosts & DNS-like servers for
this very reason. 

I can't help thinking that a similar issue also might affect source address
selection procedures.  Is this the case?

>   Erik

As the fundamental objection to route labelling ideas centres on security
aspects, I will probably not pursue this area of research much further, and
rather focus on ways to make the aggregated multihomed solution work for
long lived TCP/UDP sessions.  However, I believe that such solutions will fail
the security tests without manadatory AH/ESP to manage it.

Thanks for your thoughts.

Peter

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Sep 1999 09:29:21 -0700 (PDT)

> The message I am getting is that anything that separates end point
> indentifiers from routing identifiers will always have security implications
> like hijacking and man in the middle attacks.  Is this axiomatic?

We definitely have hijacking and man in the middle issues with IPv4 today.
The point is that decoupling routing from identification creates a new place
that an attacker can take advantage of. I also don't think we fully understand
the issues. At some level you can view separate identifiers and locators
as packets with a two-element source route (containing the source routing
label and the destination routing label in your terminology) and automatic
source route reversal.

> Very good point.  It could be solved by mandating that the routing cloud
> honour these unreachable messages and doing the lookups at the edge of the
> clouds rather than the hosts.  This would then degenerate to the classic
> route labelling solutions which have already been discussed.  Doing lookups
> at the edges also solve the need for srce & dest routing labels. However I
> would have to concede that it would be too expensive to do this lookup for
> each packet.  It is convenient to push this load back to the hosts &
> DNS-like servers for this very reason. 
> 

I'm not sure what similarity you are referring to.
One possible similarity is that when using multihoming to get higher 
availability there is a tradeoff between the hosts selecting source and
destination address (and independently from each other discover what
prefixes work) and having the routing fabric detect failed paths.
But I don't know if that was what your were thinking about.

> long lived TCP/UDP sessions.  However, I believe that such solutions will
> fail the security tests without manadatory AH/ESP to manage it.

I'd agree that for the general case of session survivability you need
authentication during the recovery i.e. when the session switches to using
the new addresses.
But it appears that when indentifiers and locators are separated
the *all* or *most* of the packets need to be authenticated to avoid
creating security holes not present in the current architecture.

   Erik

---

From: "Robert J. Rockell" <[email-masked]>
Date: Thu, 16 Sep 1999 17:14:33 -0400 (EDT)

Not directly aimed at the last response, more generally to the thread as a
whole.

Let me apologize for the brain fart that assumed that 2260, 5.1 is what we
was referred to as the part of the RFC that seems promising. I'll be the
first to admit that I am not on the "in crowd" on this lately. However, I
fear that 5.2, while technically feasible, will be a major work-around,
rather than a solution.  

How many of you would build a tunnel through one provider, over the MAE, to
another provider, to that other provider's border router, for failure. The
reason more people are multi-homed these days has to DO with the peering
points, as much as for redundancy. I worry that, while this solution presents
an alternative, is not necessarily a viable one. 

I am not trying to insight any philosophies on peering, or the motivation
for why we multi-home. I do want to make the point that the solution that
IPv6 comes up with that we adopt has to:

1. work as good as today, or people won't buy it.(this is IMPORTANT).

2. be easy, so administrator's can comprehend it.

While I will buy that we have #2 here, I don't know that we are quite there
with #1. 

I also do not mean to defend the "simple" solution when it appears that most
people have already cast it off, but I do see some form of #1 here,
argueably more or less than that of the 2260, or any 2260-based, approaches.

I have read the threads up to the current, and reply to this, simply to
extend this trhead, and not to say that I haven't read the new points
regarding ISP isolation. 

Again, I think that ISP isolation, as the point made below, is very rare.
Furtehrmore, ISP isolaion, with tunnel-based appraches, would have the same
effect... If the world can't see it, you can't see it, so I don't see how
the aggreation via the "simple solution" or the tunnel-based solution have
a different set of constraints. You still have to get to your other provider
(through a tunnel or natively) somehow.

Scalability: This one, I would argue both have problems. The "simple
solution" pushes the scalability problems back to the providers, in that
they would need to learn to use communities, etc, to filter routes to
certain people. While a pain to implement with most current policy based
routing implementations, I don't know that this is undoable.

It was mentioned that 3 or more  providers would be a problem, as complexity
increases non-linearly with number of providers per downstream increases.
That just means you have N statements in your route-map (apologies for being
cisco-centric in my syntax). As policy implementations get better, I can see
this being easy to implement.

if x : tag AS:x
if y : tag AS:y
if z : tag AS:z

at Z's peering, community-filter 
permit AS:z
permit <your communities>
deny any

Not the easiest thing, but since this is important stuff, I like the bulk of
the responsibility being on the providers (they ARE the ones who suffer when
it all breaks, after all).

The tunnelled solutions (all of them) push the scalability back to the
downstream which is multi-homed.  As a provider, we are filtering the heck
out of downstreams anyways... Now we just make their work harder.

From a business standpoint (which we have to think about) customers
generally want everything possible done for them. That is why they pay a LOT
of money for Internet service. I would tend to favor pushing the scalability
problems back towards the people who are equipped to handle them
(providers). 

Again, sorry for the confusion earlier.

Thanks
Rob Rockell

On Tue, 14 Sep 1999, Ben Black wrote:

->Just to set our terms up front:
->
->	The "simple solution" is Jessica Yu's draft.
->	The "complex solution" RFC2260/itojun proposal.
->
->Since I don't believe Yu's draft actually solves any problems, I don't
->really agree with these definitions, but they will allow less confusion
->about which draft I mean below.
->
->On Tue, Sep 14, 1999 at 12:10:56PM -0400, Robert J. Rockell wrote:
->> I'll be the first to admit that the "simple solution" is one that has some
->> policy to work out, but I want to point out that it does add to the otehr
->> proposed solutions.
->> 
->> RFC2260 has two management holes that may be big from the operatioal
->> standpoint of a TLA>
->> 
->
->[ points 1 and 2 deleted because they are not relevant to the complex solution]
->
->> 
->> #3 while RFC2260, section 5.2 attempts to look at this, I think there will be
->> some major design limitations asscociated. (details excluded).
->> 
->
->Unfortunately, it is just those excluded details which are relevant here.
->
->> The "simple solution" proposal minimizes the management woes of #1 and #2.
->> It at least sets expectations that a backbone designer can work with, and
->> attempt to implement in a way that is scalable. Although there are
->> management problems with the "simple solution" as well, I think it deserves
->> some sort of trial, perhaps on the 6bone. 
->> 
->> The possibility of an efficient community-tagging policy is one way that the
->> simple solution can work, and still provide some scalability (though not as
->> much as we all would like, perhaps).
->> 
->> Now the problem, with the "simple solution" instead of #1 and #2 above, becomes:
->> 
->> -how do we know that the other provider is only announcing this route back
->> to us, and not to everyone, breaking aggregation?
->> 
->
->The other problem becomes:
->
->- why am I paying for this second link when I can't send traffic over it if
->  my primary ISP fails?
->
->> I would argue that this is less to worry about than above, in that I would
->> put more trust into the BGP policy of a backbone provider than a downstream
->> to aggregate and export the correct routes at the right locations. The
->> problem, however, still remains; management of one's own TLA;
->> it just shifts a bit.
->> 
->> 
->> In regards to Ben's comments, I would argue that load-balancing is not
->> addressed, but the redundancy is.  If the subnet (to use a
->> soon-to-be-outdated-term) of the TLA is announced back to the TLA,
->> redundancy is there with the "simple solution", but the load-balancing
->> becomes problematic.  One can no longer use AS padding, for instance, for
->> multi-homing load-balancing. The redundancy is there; the routing just gets
->> messy. If a t-1 goes down, then the packets will go to the other provider,
->> albeit via the primary provider, so long as a peering between the two exists
->> (which in itself is a whole other issue).
->> However, if the whole backbone goes down, then the redundancy would be
->> removed (but if a whole backbone goes down today, we all feel it, regardless
->> of where we home; remember the various "internet drains" that occured over
->> the last couple of years; I won't mention AS numbers). 
->> 
->> As I haven't seen any implementations of 2260 working, and this one actually
->> is something that can be set up, I would like to test this. If anyone who
->> has 6bone transit woudl be interested in testing, I say we give it a whirl,
->> and see how it scales in the small picture, before we cast it away for the
->> big picture totally.
->> 
->> I apologize in advance if these opinions are redundant, or I missed
->> something here, but I am afraid we may be throwing somethign aside which may
->> at the very least provide more insight into how to tackle this most
->> difficult and important problem of the protocol.
->>
->
->A key point you may have missed from the simple solution:
->
->"A multi-homed customer will designate a primary ISP and receive IP
->address from its primary ISP's IPv6 aggregation block."
->
->What this means is that, since the *single* prefix used by the customer can
->only be advertised by the *primary* ISP into the global backbone, if that ISP
->has a failure (AS0, sun spots, fiber cut, whatever), the customer is 
->completely unreachable, even though they have a viable, alternate path through
->their secondary ISP.  If only they had address space from that ISP.  Which
->they do in the complex solution.
->
->This doesn't even begin to address the problem of homing to more than 2
->providers.
-> 
->> Also, in regards to how this can be done ( deploy the "simple solution"; I
->> don't know if this is the right place, but I believe it is possible, even
->> with limited implementations of IPv6 that we have, to make this work, if we
->> ignore some scaling problems that aren't there yet on the 6bone).
->> 
->
->Sure, you could deploy it, but realize the simple solution is 50% of the
->complex solution.  Add a second prefix and a second tunnel and it is
->magically upgraded to a system which actually *can* survive the failure of
->an upstream.
->
->
->Ben
->
->> On Mon, 13 Sep 1999, Brian E Carpenter wrote:
->> 
->> ->OK, there is clearly a problem with the way this has been
->> ->written up. Those of us who attended the second design team meeting
->> ->on this before Oslo were, I think, pretty clear that the RFC 2260
->> ->approach was a required part of the total solution (i.e. in my
->> ->mind at least, the "simple solution" is by no means a
->> ->complete proposal). 
->> ->
->> ->Thanks for the clarification
->> ->
->> ->  Brian
->> ->
->> ->Ben Black wrote:
->> ->> 
->> ->> I think the only viable solution, in the face of the constraints placed
->> ->> on advertisement of IPv6 aggregates, is similar to that proposed in RFC2260
->> ->> and further detailed for IPv6 by itojun.  The "current" proposal is not
->> ->> viable at all, despite some minor similarities with RFC2260.
->> ->> 
->> ->> Although it would be rather involved, I can see application of tunnel
->> ->> networks overlayed on a large scale as a solution allowing an ISP to
->> ->> provide backup for another ISP.  I don't really think it is attractive
->> ->> because of the significantly higher complexity and administrative
->> ->> overhead compared to RFC2260 and itojun's proposal.
->> ->> 
->> ->> Ben
->> ->> 
->> ->> On Mon, Sep 13, 1999 at 01:54:08PM -0500, Brian E Carpenter wrote:
->> ->> > Ben,
->> ->> >
->> ->> > I can't see anything in your arguments that suggests any realistic,
->> ->> > deployable alternative to the current proposal, unless you can explain
->> ->> > in concrete detail what this means:
->> ->> >
->> ->> > > Solutions which avoid the use of multihoming with a single address
->> ->> > > space are possible and offer more hope for a robust network than those
->> ->> > > currently proposed.
->> ->> >
->> ->> >    Brian
->> ->> >
->> ->> > Ben Black wrote:
->> ->> > >
->> ->> > > I'm not familiar with the workings of the IPng group, so please let me
->> ->> > > know if this violates any procedural or etiquette boundaries.  I've
->> ->> > > just finished reading several of the IPv6 drafts and hoped my thoughts
->> ->> > > on one recently submitted draft might be of use.
->> ->> > >
->> ->> > > IPv6 multihoming is a thorny problem and I don't pretend to have a
->> ->> > > solution.  I don't know that there is one possible as the network layer.
->> ->> > >
->> ->> > > Ben
->> ->> > >
->> ->> > > --
->> ->> > >
->> ->> > > The IPv6 address allocation and routing hierarchy defined in [AGGR]
->> ->> > > and [ARCH] poses serious difficulties for implementation of multihomed
->> ->> > > networks.  Rather than the usual practice of allocating a single
->> ->> > > prefix, or set of prefixes for multiple networks, network operators
->> ->> > > must either home to a single provider or allocate multiple prefixes
->> ->> > > for the same set of nodes.  The draft "A Simple Solution for IPv6
->> ->> > > Multihoming" [SMPL] profers an approach to achieving multihomed
->> ->> > > networks within the constraints of the IPv6 route aggregation
->> ->> > > hierarchy.
->> ->> > >
->> ->> > > Unfortunately, the fundamental assumptions regarding the purposes of
->> ->> > > multihoming lead the author of the document astray.  The main goals
->> ->> > > of multihoming are: redundancy in the face of link and/or network
->> ->> > > failure, load balancing, and performance improvement.  Of these, only
->> ->> > > load balancing is directly addressed, and even then with limited
->> ->> > > success.  Similarly, although improving performance by connecting
->> ->> > > directly to networks which are common destinations is effective, the
->> ->> > > document does not provide options for accessing content providers
->> ->> > > accessible through other networks.
->> ->> > >
->> ->> > > A selection of quotes from the document will help in clarifying its
->> ->> > > shortcomings as a solution to multihoming within the existing,
->> ->> > > documented IPv6 routing framework.
->> ->> > >
->> ->> > > >From section 2 (Proposal):
->> ->> > >
->> ->> > >                            ISP-3 ---- ISP-4
->> ->> > >                              |      /  |
->> ->> > >                              |    /    |
->> ->> > >                              |  /      |
->> ->> > >                            ISP-1 ---- ISP-2
->> ->> > >                     link-1   \          /  link-2
->> ->> > >                               Customer-A
->> ->> > >
->> ->> > >    A multi-homed customer will designate a primary ISP and receive IP
->> ->> > >    address from its primary ISP's IPv6 aggregation block. In this
->> ->> > >    example, ISP-1 is the primary ISP of customer-A and assigns Addr-1-A
->> ->> > >    to the customer. Customer-A will advertise addr-1-A to ISP-1 and
->> ->> > >    ISP-2 respectively. ISP-2 will advertise Addr-1-A to ISP-1 and to
->> ->> > >    ISP-1 only. ISP-1 will, of course, advertise its own aggregation
->> ->> > >    Addr-1 to the entire Internet.
->> ->> > >
->> ->> > > It is clear from this description that the only redundancy provided
->> ->> > > with this solution is for the customer links (link-1 and link-2) and
->> ->> > > not for the ISPs themselves.  Specifically, if ISP-1 suffers from a
->> ->> > > failure within the POP to which link-1 terminates, whether as an
->> ->> > > isolated failure or a more extensive failure within ISP-1, then
->> ->> > > Customer-A is no longer able to maintain connectivity despite their
->> ->> > > possession of a perfectly good alternate path through ISP-2.  From an
->> ->> > > engineering perspective, no robustness has been gained through this
->> ->> > > multihoming which could not be gained more simply with multiple links
->> ->> > > to ISP-1.
->> ->> > >
->> ->> > > >From section 2 (Proposal):
->> ->> > >
->> ->> > >    For inbound traffic to Customer-A, traffic will first be forwarded to
->> ->> > >    ISP-1 since it advertises Addr-1 which includes Addr-1-A. ISP-1 will
->> ->> > >    then forward the traffic destined to Customer-A via its connection to
->> ->> > >    ISP-2 and/or its direct link to customer-A, according to certain
->> ->> > >    polices. Most common policy would be the use of the shortest exit. By
->> ->> > >    using both connections to forward traffic to Customer-A, load sharing
->> ->> > >    is achieved.
->> ->> > >
->> ->> > > >From this statement it is unclear exactly how inbound load balancing
->> ->> > > is to be achieved.  Is the author suggesting use of the (rather
->> ->> > > troublesome) concept of eBGP multipath?  In the topology described in
->> ->> > > the diagram above, implementation of a load sharing mechanism across
->> ->> > > link-1 and link-2 would be a decidedly non-trivial matter.  Again,
->> ->> > > given the lack of redundancy outlined above, it would be far more
->> ->> > > efficient for Customer-A to simply purchase multiple links to ISP-1.
->> ->> > >
->> ->> > > Additionally, Customer-A must now depend heavily on the connectivity
->> ->> > > between ISP-1 and ISP-2.  Often, links to multiple providers are
->> ->> > > purchased specifically to avoid traffic crossing these (often
->> ->> > > congested) peerings.
->> ->> > >
->> ->> > > >From Section 4 (Concerns):
->> ->> > >
->> ->> > >       - The primary ISP of a multihoming customer (such as ISP-1 in the
->> ->> > >       example) would need to do more work in terms of distributing the
->> ->> > >       traffic among other connected ISPs and the customer link.  This
->> ->> > >       can be done using BGP policy (BGP community) and using shortest
->> ->> > >       exit. It will also carry more traffic for the customer. However,
->> ->> > >       this is a value added service to the customer and the primary ISP
->> ->> > >       can charge more fees for such services.
->> ->> > >
->> ->> > > Stating that the primary ISP "would need to do more work" is putting
->> ->> > > the problem a bit lightly.  The addition of references to BGP policies
->> ->> > > and BGP communities does little to clarify how exactly the author
->> ->> > > believes traffic could effectively be distributed.
->> ->> > >
->> ->> > > >From Section 4 (Concerns):
->> ->> > >
->> ->> > >       - The primary ISP is the sole interface for the multihomed
->> ->> > >       customer to the Internet other than the ISPs the customer has
->> ->> > >       directly connection with. Outages such as one between ISP-1 and
->> ->> > >       ISP-4 would impact the reachability from customers of ISP-4 to
->> ->> > >       Customer-A even though ISP-2 still has good connection to ISP-4.
->> ->> > >       However, if the primary ISP is a good quality ISP, this sort of
->> ->> > >       situation should happen rarely. The reason is that it's common
->> ->> > >       practice that an ISP, especially good quality ISP, has multiple
->> ->> > >       connections to other big ISPs at different geographical locations.
->> ->> > >       Good quality ISPs also have robust network design to prevent any
->> ->> > >       failure to impact the whole network. Choosing a good quality and
->> ->> > >       robust ISP as primary ISP is a good practice.
->> ->> > >
->> ->> > > This is really the crux of the problem with the solution put forth in
->> ->> > > the document.  The assumption that a given ISP will never have
->> ->> > > failures, or that rare failures are acceptable to customers who
->> ->> > > multihomed for redundancy, is simply not valid from an engineering
->> ->> > > perspective.  If the primary goal of multihoming were load sharing,
->> ->> > > this solution would provide one, potentially very complicated,
->> ->> > > answer.  However, the issue of multihoming for redundancy is totally
->> ->> > > ignored, drawing into question the need for a second ISP in the
->> ->> > > equation at all.  Why not simply purchase additional bandwidth from
->> ->> > > the same ISP?
->> ->> > >
->> ->> > > >From Section 4 (Concerns):
->> ->> > >
->> ->> > >    It is desirable to have solution which provides perfect redundancy
->> ->> > >    and, at the same time, simplicity to scale management and operation.
->> ->> > >    In the absence of a perfect solution, the trade-off needs to be made.
->> ->> > >    The author believes that it is very important that the solution has
->> ->> > >    to be simple and manageable. Manageability should be the top
->> ->> > >    consideration.
->> ->> > >
->> ->> > > If manageability of the solution is to be the top consideration, the
->> ->> > > response put forward does not measure up.  In the name of avoiding
->> ->> > > routing table growth the author has suggested adding significant
->> ->> > > complexity to the configuration and management of multihomed customers
->> ->> > > without showing any benefit for the effort.
->> ->> > >
->> ->> > > An area not addressed at all in the document is that of multihoming
->> ->> > > for access to networks attached to a given ISP, rather than access to
->> ->> > > that ISP.  For example, using the diagram above, if Customer-A
->> ->> > > purchased connectivity to ISP-2 because ISP-2 had better connectivity
->> ->> > > to ISP-4, then the offered multihoming solution is of no use.  ISP-4
->> ->> > > will never see reachability to Customer-A via ISP-2.
->> ->> > >
->> ->> > > The primary lesson of the draft proposal is that the proposed, forced
->> ->> > > aggregation hierarchy places sever restrictions upon the engineering
->> ->> > > of reliable, high poerformance networks.  To multihome effectively, a
->> ->> > > network operator must somehow qualify as a "long-haul provider" or
->> ->> > > other entity appropriate for allocation of its own address space.  In
->> ->> > > this author's  opinion, the current IPv6 addressing architecture
->> ->> > > creates an environment which provides scalability of the global
->> ->> > > routing table at the expense of any real hope for redundancy through
->> ->> > > multihoming.
->> ->> > >
->> ->> > > Solutions which avoid the use of multihoming with a single address
->> ->> > > space are possible and offer more hope for a robust network than those
->> ->> > > currently proposed.
->> ->> > >
->> ->> > > REFERENCES
->> ->> > >
->> ->> > >    [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
->> ->> > >              Aggregatable Global Unicast Address Format", RFC 2374, July
->> ->> > >              1998.
->> ->> > >
->> ->> > >    [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
->> ->> > >              RFC 2373, July 1998.
->> ->> > >
->> ->> > >    [SMPL]    Yu, J., "A Simple Solution for IPv6 Multihoming",
->> ->> > >              draft-yu-simple-ipv6multihoming-00.txt, August 1999.
->> ->> > >
->> ->> > > --------------------------------------------------------------------
->> ->> > > IETF IPng Working Group Mailing List
->> ->> > > IPng Home Page:                      http://playground.sun.com/ipng
->> ->> > > FTP archive:                      ftp://playground.sun.com/pub/ipng
->> ->> > > Direct all administrative requests to [email-masked]
->> ->> > > --------------------------------------------------------------------
->> ->> 
->> ->> --
->> ->>  --b
->> ->--------------------------------------------------------------------
->> ->IETF IPng Working Group Mailing List
->> ->IPng Home Page:                      http://playground.sun.com/ipng
->> ->FTP archive:                      ftp://playground.sun.com/pub/ipng
->> ->Direct all administrative requests to [email-masked]
->> ->--------------------------------------------------------------------
->> ->
->
->-- 
-> --b
->