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

From: Jessica Yu <[email-masked]>
Date: Wed, 15 Sep 1999 11:24:59 -0400

Hi, Ben:

Thanks for spending time looking into the proposal. 

Looks like your main issue is the mendatory route aggregation for IPv6. 
You should raise this to IPv6 WG.  My proposal just try to work out
a solution for multihoming given this constrain. It's not an endorsement 
of such restriction.

Your other issues with my proposal are addressed point-by-point below 
which are inbedded in the message.  Some of them seems to be based on 
incorrect understanding of the proposal and some of them are due to the 
lack of more detailed explanation of current common routing practice
among ISPs. For the latter, I will put more detailed explanation in to 
the writing, I should not assume that everyone would familar these 
mechanisms.

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

	Aggregation and allowing no more specific prefixes advertising 
	into the global routing table is a contrain imposed by the IPv6 
	WG as one of the design of IPv6 routing architecture. Because of 
	this constrain, multihoming routing becomes a hard problem and 
	needs solution. Therefore, my proposal, of course, has to work 
	under this contrain.  

	Do you have any suggestion of maitaining the scaling of the global 
	routing table but not by imposing the restrict aggregation?  If not,
	we still have to work under the assumption.

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

	I'd argue that the realistic goal of multihoming are 
	a) Redundancy and b) load sharing. The simple multihoming
	proposal (SMPL) addressed both. 

	'performance improvement' you used here is a vague term, 
	redundancy and load sharing are performance improvement.
	If you mean the improve throughput or goodput of the traffic
	from/to a multihomed site, this is not a realistic goal to
	achieve via multihoming. 

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

	This is not correct. If the POP to which link-1 connects goes 
	down, the connectivity to Customer-A will still remain and
	link-2 will be used.

	This is because even the POP is down, ISP-1 will still
	advertising Addr-1 which including the address of Customer-A
	to the Internet (ISP-1 will still advertise its block). So
	traffic destinted to Customer-A will still be sent to ISP-1.
	Since ISP-2 advertises the specific address of Customer-A to
	ISP-1, so ISP-1 will just forward the traffic to ISP-2 which
	will further forward traffic to Customer-A vis link-2.

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

	No, I am not suggesting the use of eBGP multipath. The method
	is the same as the common mechanism used by ISPs today to deal
	with forwarding traffic to routes learned from multiple network
	points i.e. to use IGP metric to find the closest exit to forward 
	the traffic.  It could use to ISP-2 or could use its direct link 
	to Customer-A. 

	I assumed that the reader would be familiar with the mechanism
	since it's so commonly used.  But maybe I can not assume this
	and in next revision, I should put more details to explain it. 
 
>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.

	Unless the traffic are sourced and destined within the multihoming 
	site and its directly connected ISPs (e.g. from customer-A to src/dst
	behind ISP-1 or ISP-2), the traffic has to go through links between 
	ISPs.  This is the case today.  

	Even without the SMPL, in today's network, a multihomed site
	just can not dictate how the traffic goes back to it.  It's
	all depends a other ISPs' routing policy.  Looks at the 
	picture, even not using the SMPL, it does not gaurantee
	that ISP4 will use ISP-2 to send traffic to customer-A,
	it may well be sending the traffic via its link to ISP-1. 

	I also think it's wrong to assume that the links between
	ISPs are by default congested. It was more so the case when
	all ISPs exchange traffic at NAPs (i.e. Public exchange point).
	There are a lot of private links between ISPs at multiple 
	locations and the situation is different now.	 

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

	Again, these are common practice which are already in place.
	I should not have assumed the everyone would familiar with
	it.  I will give more detailed explanation to it. 

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

	Since noboday can gaurantee absolutely and 100% no outage,
	the measure of 'rarely happen' is really quite a good measure.
	
	Even with today's practice, nobody can ganrantee that the two
	ISPs the multihoming site connecting to, will not go down at the
	same time thus leave the site with no connection.  But one
	can say, it rarely happen so we will have two ISP connections instead
	of 3 or 4 or more.

	Also, if the alternatives to SMPL is to have multiple address 
	assigned to all my hosts (could hundread thousands) or complcated
	tunnels,etc. My feeling (based on my network operationa and engieering
	experience) the chances of my connectivity will be impacted due 
	operation error, misconfigurations, etc. woulud be much more high 
	than use of SMPL.  

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

	As mentioned above, the routing aggregation is a given
	contrain that this proposal works under.  The simplicity
	I am mentioned here is more in compare of other proposals
	in terms of complicated tunnel and mulit addressing for
	every single host in a multihoming site.  Compare to
	that, this proposal is highly scalable and managable.

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

	Again, as mentioned above, even without the SMPL, in today's 
	network, a multihomed site just can not dictate how the traffic 
	goes back to it.  It's all depends a other ISPs' routing policy.  
	ISP-4 may well have the policy of sending traffic to ISP-1
	instead of using its link of ISP-2. There are many reasons which 
	led ISP-4 do that.  In short, ISP-4 will look into the interets
	of itself rather Customer-A's interests, especially Customer-A
	is not even directly pay for ISP-4.  

	If someone expects the incomming traffic will take the path it
	wished, then he or she needs to be more realistic. Likewise,
	one should not ask a multihoming proposal address this. 

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

	Looks like you have an issue of the mendetory aggregation for
	IPv6. You should raise this to IPv6 WG for this. My proposal
	just works under contrain of this assumption.  It's not an
	endorsement of such restriction. 

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

						--Jessica
--------------------------------------------------------------------
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: Ben Black <[email-masked]>
Date: Wed, 15 Sep 1999 12:06:49 -0700

> 	needs solution. Therefore, my proposal, of course, has to work 

Thank you for paraphrasing exactly what I said in the quoted paragraph.

> 	we still have to work under the assumption.

Yes, realize that the routing table has sustained linear growth, while
computing power has increased exponentially.  This argues for using
existing aggregation and multihoming mechanisms.

> 	from/to a multihomed site, this is not a realistic goal to

Nonsense.  If I am sending a large amount of traffic to ISP-A, but I only
have connectivity to ISP-B and ISP-B has poor connectivity to ISP-A, then
adding connectivity directly to ISP-A will improve the performance, as
measured by such factors as latency, packet loss, etc.

> 	will further forward traffic to Customer-A vis link-2.

Your eggs are still all in the ISP-1 basket.  Even the best ISPs have
wide-scale failures.  Your later assertion that this is reasonable
and acceptable is contrary to the redundancy goals you agreed with
for multihoming.

> 	the traffic.  It could use to ISP-2 or could use its direct link 

Why would there be more than route to the destination in ISP-1s IGP?  ISP-1
would pick the *single* best path in BGP and use that *single* path when
sending traffic to the customer.  Are you suggesting that the IGP would
see multiple paths to the same destination even though BGP only saw one?
Or are you suggesting that BGP would carry multiple routes to the same
destination?

> 	ISPs.  This is the case today.  

Except that today if there is poor connectivity between a pair of given ISPs
the result is that you have poor reachability to one of those ISPs.  In the
configuration you describe, the result is poor *global* reachability in
the case of failure of a *single* ISP.

> 	it may well be sending the traffic via its link to ISP-1. 

The point is that *both* of the paths to the customer are *usable*.  In
the current system of multihoming, if ISP-1 failed, all traffic would
flow through ISP-2.  The issue is now how well the customer can control
reachability to their own network, but whether there is reachability at
all in the case of upstream failure.

> 	locations and the situation is different now.	 

No, the situation is not different now.  Private peerings are quite often
congested and neither ISP involved in a private peering has any reason
to change that.

> 	it.  I will give more detailed explanation to it. 

Please do.

> 	the measure of 'rarely happen' is really quite a good measure.

But irrelevant since you must rely entirely on a single ISP, despite the
fact that you have more than 1 connection.

> 	can say, it rarely happen so we will have two ISP connections instead

Yes, and people do exactly that.  But using the technique described in
your draft, adding those additional ISPs would provide no benefit.

> 	operation error, misconfigurations, etc. woulud be much more high 

My feeling, also based on my network operations and engineering experience,
is that I would rather rely on a slightly more complicated configuration
which allows arbitrary increases in connectivity to provide additional
redundancy than on a system that is "simple" but allows almost no
redundancy and absolutely no scaling.

> 	that, this proposal is highly scalable and managable.

You are half right.
 
> 	is not even directly pay for ISP-4.  

Yes, but ISP-4 will *never* send traffic *directly* to ISP-2 even though
there is connectivity to the customer via ISP-2.  Even if ISP-4 loses 
connectivity to ISP-1.

> 	one should not ask a multihoming proposal address this. 

No, I expect a multihoming proposal to provide a realistic level of
redundancy.  SMPL does not meet this requirement.

> 	endorsement of such restriction. 

I do indeed have an issue with the aggregation policies.  However, working
within them, I believe the RFC2260/itojun proposal provides value as
a mechanism for improving reachability for a customer network and SMPL
does not.

-- 
 --b

---

From: Bradley Reynolds <[email-masked]>
Date: Wed, 15 Sep 1999 15:54:24 -0400 (EDT)

comments below

> 	we still have to work under the assumption.
this is not germane to your document, but seems like ipv4 is working
fine without such a restriction.

> 	will further forward traffic to Customer-A vis link-2.
you need to be explicitly clear as to how traffic passes from ISP-1 to
ISP-2.  if this is a tunnel through isp 3 and 4, the load sharing 
is worthless.  if it is a direct connection, then you are implying 
multiple direct conenctions (not in this figure) because of ISP-2 is
connected to ISP-1 at the failed pop, suddenly we have no reachability for
this prefix.

> 	the traffic.  It could use to ISP-2 or could use its direct link 
it works ok for large networks.  because large networks have multiple
distributed interconnects.  when you are looking at two paths
to forward data to a given network, figuring out how to space 
them IGP wise on your backbone to obtain some sort of 'balance'
is a joke.  the complexityy of this problem becomes unacceptable when
you are trying to manage multiple customers under this scenario who all
want favourable IGP spacing based on traffic flows on your network.  

if you start interconnecting multiple times with ISP-2, you are in
terrible shape because igp metric decisions will favor the path to isp-2
more often than your own internal path.  

> 	and in next revision, I should put more details to explain it. 
yeah, explain how it works in this scenario to achieve load balancing.
i am not able to see it.

> 	ISPs.  This is the case today.  
you are making a logical fallacy there.   the traffic has to go through 
links between ISPs but not over links between the two ISPs customer-a is
multihomed to.  the issue is that ISP-1 is now providing
free transit to ISP-2 fo rthat multihomed customer.  that is just silly.
and to contend that isp-2 should be paying isp-1 because a customer
desires to multihome to isp-2 is also silly.

> 	it may well be sending the traffic via its link to ISP-1. 
however, it does say that when isp-1 goes away, isp4 will use isp2

> 	it.  I will give more detailed explanation to it. 

we understand how bgp path selection works.  we understand how traffic
flows across large backbones.  what we don't understand is how you
can have any kind of simple balance in egress traffic
bnetween isp-2 and isp-1s links to customer-a.  when you introduce
this scenario, you are tying gordian knot of complexity into 
interconnections between providers.  

you are also missing another point.  when you multihome, there should 
be no 'primary ISP'. primary isp introduces single points of failure
whether on the technical side the administrative side.

> 	can say, it rarely happen so we will have two ISP connections instead
you are putting forth a hastily described scenario where a provider
multihomes to isp-1 and isp-2.  what happens when a provider wants to
multihome to isp-1 isp-2 isp-3 and isp-4.  suddenly things become 
extremely complex.  the point of redundancy is to engineer out as many
single points of failure as possible.  this proposal introduces _more_
single points of failure than we are used to under the current operational
deployment of ipv4 and its associate routing protocols.  this is not a
debate of the ipv6 addressing architecture, but a statement that this
draft does not solve the ipv6 multihoming problem.

> 	operation error, misconfigurations, etc. woulud be much more high 

i belive this document has no operational sanity check.  and if it does, i
would like to hear the opinions of the operators who are favouring this
scenario when compared to the current ipv4 multihoming scenario.  i would
be interested in hearing their justifications

> 	that, this proposal is highly scalable and managable.

compared to unmanagable things, this draft is less unmagable?
scalability and managability are not relative terms unless we have
exhauseted all possible scenarios for multihoming.

> 	is not even directly pay for ISP-4.  

i don't think you understand that isp-4 has multiple AS paths to
customer-a today.  it is advantageous to have traffic flowing through
diverse administrative domains.  that is why diverse as-path is an
advantage.

> 	one should not ask a multihoming proposal address this. 

again, this is a logical fallacy.  you are assuming that since one
person cannot have as much granularity as they desire on multihomed links,
they should be happy to only have one AS path.  

> 	endorsement of such restriction. 

it absolutely does not work under that restriction.

BR

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 1999 17:30:15 -0500

> fine without such a restriction.

I find this pretty rich, being addressed to one of the authors
of the CIDR proposal that saved the Internet routing tables
from exponential growth a few years ago. IPv4 has survived
only because of exactly such a restriction.

  Brian

---

From: Bradley Reynolds <[email-masked]>
Date: Wed, 15 Sep 1999 22:36:35 +0000 (GMT)

> only because of exactly such a restriction.
how many times do i have to explain that it does not MANDATE
aggregation.  you are free to deaggregate.

BR

---

From: Quality Quorum <[email-masked]>
Date: Wed, 15 Sep 1999 19:24:12 -0400 (EDT)

> only because of exactly such a restriction.

It does not matter anymore (or it will not matter soon) due to 
recent tech advances - so, it seems to me that there is no reason 
to discuss any proposal from this angle. 
 
>   Brian

Thanks,

Aleksey

---

From: Jessica Yu <[email-masked]>
Date: Thu, 16 Sep 1999 11:36:45 -0400

Hi, Bradley:

I'd like to respond your message point-by-point but I felt that I
most of my answer would be similar to the loooong message I responsed
to Ben's message that I just sent out.  So let me be brief here:

a. There is no tunnel whatsoever involved in this proposal.  ISP-1
   learn specific route of customer-A from ISP-2 and can send 
   traffic destined to Customer-A via its link to ISP-2. NO tunnels.
 
b. In multihome case today, a site can achieve the most is load sharing
   not load balancing (in terms of inbound traffic since the site just 
   has no control), it can load balancing when sending outbound traffic
   with or without SMPL.  So we talk about load sharing.  Shortest out 
   routing achieves load sharing.

c. I think whether there should be a manadate aggregation for IPv6 is
   a good topic itself to discuss on the list.

Thanks!

						--Jessica

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Sep 1999 09:44:39 -0500

Quality Quorum wrote:
> recent tech advances - 

Please tell us *exactly* what this means and how it works.

  Brian

---

From: Ben Black <[email-masked]>
Date: Thu, 16 Sep 1999 16:09:40 -0700

Level-compressed tries are an effective mechanism for reducing the size
of a routing table, but they do not reduce the size of a BGP table
significantly as they are not applicable to the numerous attributes
associated with a given prefix.

On Thu, Sep 16, 1999 at 07:06:51PM -0400, Quality Quorum wrote:
> 
> 
> On Thu, 16 Sep 1999, Brian E Carpenter wrote:
> 
> > Quality Quorum wrote:
> > > 
> E.g. look at the following paper by Nick McKeown:
> 
> http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf
> 
> One can build 3 level device described there with 24,4 and 4 bits
> per level. Then one would need only 48M of 25-bit words in order to
> handle ALL class A, B and C routes plus 1M of longer routes. 
> 
> It is not that much for SRAM implementation, and once announced 167MHz 
> SDRAM will become available (so uncorrelated row read will fall under
> 50ns), it will be possible to build ideal look up device running at
> OC-192 dirt cheap.
> 
> BTW, I suspect that this is not the only available solution, which could
> be scaled that high.
> 
> In other words, it seems like we can disregard the necessity of
> aggregation as a primary requirement to any scheme being discussed. -
> this is a point I was trying to make.
> 
> >   Brian
> 
> Thanks,
> 
> Aleksey
> 

-- 
 --b

---

From: Quality Quorum <[email-masked]>
Date: Thu, 16 Sep 1999 19:06:51 -0400 (EDT)

Thanks,

Aleksey

---

From: [email-masked]
Date: Fri, 17 Sep 1999 14:37:05 +0900

>Is that clear now?

	I think so, thanks for clarification.
	I checked  draft-ietf-ngtrans-harden-01.txt and it says like this:

>>All pTLAs MUST NOT advertise prefixes longer than a given pTLA
>>delegation (currently /24 or /28) to other pTLAs unless special peering
>>arrangements are implemented. When such special peering aggreements are in
>>place between any two or more pTLAs, care MUST be taken not to leak the more
>>specifics to other pTLAs not participating in the peering aggreement. pTLAs
>>which have such agreements in place MUST NOT advertise other pTLA more
>>specifics to downstream pNLAs or leaf sites, as this will break the
>>best-path routing decision.

itojun

---

From: Steve Deering <[email-masked]>
Date: Thu, 16 Sep 1999 22:23:24 -0700

At 12:30 PM +0900 9/17/99, [email-masked] wrote:
>	If it is in a single ISP, it is okay to exchange non-aggregated
>	routes.  I believed that, in DFZ, there will be only 8192 routes
>	(for TLA ISPs) will be exchanged (RFC2374 3.2).  Am I correct?

itojun,

The architecture is designed to work when only TLA and subTLA prefixes
are exchanged among [sub]TLA ISPs and exchanges (a maximum of 2 * 8192
prefixes).  However, a TLA ISP may *choose* to exchange longer prefixes
with one or more other TLA ISPs, by private agreement among those ISPs.

>	I believe it is safer to design multihoming proposals, without
>	using non-aggregated route advertisements.  Otherwise the proposal
>	will have less use.

Yes, the multihoming mechanisms must work in the case that routes are
aggregated, because we cannot assume or require that all ISPs will
exchange and maintain non-aggregated routes for all (or any) multi-
homed sites.

>	To clarify, "other ISP" cannot inject the route to DFZ (again
>	RFC2374 3.2).

The DFZ does not exist apart from the TLA ISPs, so a TLA ISP does not
in reality inject a route "to the DFZ", but rather injects a route into
other TLA ISPs (and/or exchanges).  If some TLA ISPs agree to accept
longer prefixes from some other TLA ISPs, that's OK.  That's a private
matter between those ISPs.  The IPv6 architecture neither requires it
nor forbids it.

Is that clear now?

Steve

---

From: Peter Tattam <[email-masked]>
Date: Fri, 17 Sep 1999 15:30:47 +1000 (EST)

On Fri, 17 Sep 1999 [email-masked] wrote:

> 	I'm not objecting anything, just need a clarification or two.
> 
> >IPv6 does *not* mandate route aggregation!
> >  - An ISP is free to carry IPv6 prefixes of any value and any length in
> >    its routing tables.
> 
> 	If the above is correct, for a multihoming technology proposal,
> 	- to be usable with site exit links toward different TLA ISP
> 	  (TLA ISP A and TLA ISP B), the proposal should not rely on
> 	  non-aggregated route advertisement.
> 	- if the proposal is for use within one TLA ISP, is may use
> 	  non-aggregated route advertisement.
> 
> >  - If a customer obtains an IPv6 site prefix from one ISP, and can
> >    convince other ISPs to carry that prefix in their routing tables,
> >    nothing in the IPv6 protocol, routing architecture, or working
> >    group utterances forbids that from happening.
> 
> 	RFC2374 3.2).  Therefore, when site exit link toward primary ISP
> 	goes down, the site will be reachable only from peers directly
> 	connected to "other ISP".
> 
> itojun

Correct me if I am wrong, but I recall that A-S numbers are also currently
limited to 16 bits (artificially?).   Will this also have an impact on the
current solutions that are at the front of the pack? i.e. it may limit the
total number of ISP that can be multihomed in a global context.  Presumably if
the multihoming proposals are agreed on, then will this A-S limitation will be
removed by extending BGP somewhat?

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: Steve Deering <[email-masked]>
Date: Thu, 16 Sep 1999 22:52:42 -0700

> >>best-path routing decision.

Yes, that's consistent with what I said.

Steve

---

From: Quality Quorum <[email-masked]>
Date: Thu, 16 Sep 1999 23:12:06 -0400 (EDT)

On Thu, 16 Sep 1999, Ben Black wrote:

> Sorry, I meant to include LC-trie URLs, not to say the URL you included
> referenced them.  Here are the URLs I intended:
> 
> http://www.nada.kth.se/~snilsson/public/papers/router/index.html
> http://www.nada.kth.se/~snilsson/public/papers/router2/index.html
> 
> Apologies for the confusion.  There are obviously many ways to skin this
> particular cat, which argues for a close re-evaluation of the assumptions
> behind the current IPv6 aggregation constraints.

And a new stuff keeps coming in.

This was precisely my point: reevaluation of some basic IPV6
requirements may prove to be fruitful.

Thanks,

Aleksey

---

From: [email-masked]
Date: Fri, 17 Sep 1999 12:30:20 +0900

itojun

---

From: Ben Black <[email-masked]>
Date: Thu, 16 Sep 1999 18:35:11 -0700

On Thu, Sep 16, 1999 at 09:14:56PM -0400, Quality Quorum wrote:
> I do not think that this comment is applicable to this work, 
> however, it seems like further discussion in this direction
> is a way beyond scope of IPng.
> 
> > 
> > > 

-- 
 --b

---

From: Quality Quorum <[email-masked]>
Date: Thu, 16 Sep 1999 21:14:56 -0400 (EDT)

Thanks,

Aleksey

---

From: Steve Deering <[email-masked]>
Date: Thu, 16 Sep 1999 18:21:01 -0700

At 11:24 AM -0400 9/15/99, Jessica Yu wrote:
>  into the global routing table is a constraint imposed by the IPv6 
>  WG as one of the design of IPv6 routing architecture.

Jessica and everyone else:

The above-quoted statement is incorrect.  Unfortunately, this misconception
seems to have taken firm hold here recently.

  - If routing technology improves to the point where the the routing
    system can successfully route independently to every site or every
    subnet or every node in the future Internet, that would be wonderful,
    and there is nothing in the design of IPv6 that would prevent it
    from taking advantage of that capability.

What *is* true is that the IPv6 address architecture is designed to
make route aggregation *possible*.  The reason is that current and
at least near-term IP routing technology depends vitally on route
aggregation to handle an internet anywhere near the size of today's
Internet, not to mention tomorrow's.  We did not and do not wish to
make IPv6's success contingent on solving the flat routing problem.

We are working on new multihoming mechanisms *not* because we have
forbidden global advertisement of individual site or customer prefixes.
If the ISPs are willing and able to offer that service for IPv6
prefixes, then customers are certainly free to use that service.
Rather, we are working on new multihoming mechanisms because we want
to be prepared to handle the case where the number of multihomed sites
exceeds the ability or willingness of the ISPs to carry the prefixes
of those sites globally, or where such carriage is offered only at a
price that is prohibitive for many customers.

And even if new routing technology comes along to make it cheap and
easy to route individually to many millions of sites, some of the
mechanisms we are exploring will -- if they work out -- improve support
for multihomed *hosts*, even if they are not needed to support
multihomed sites.  That alone would be a valuable advance in the
state of the art.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Sep 1999 09:47:16 -0500

Sure, we can build big fast lookup engines.

That is not the problem, unfortunately. The problem is convergence
time of the route table computations, which is a distributed
computing problem. I'm not an expert on this, but people who are 
experts assure me of this. Is there anyone here who can expand on this?

  Brian

---

From: Magnus Ahltorp <[email-masked]>
Date: 18 Sep 1999 02:17:51 +0200

> handle ALL class A, B and C routes plus 1M of longer routes. 

[...]

> this is a point I was trying to make.

Aggregation is not only a way to make the routing tables smaller, it
is also a way to push many routing decisions from the DFZ to the TLA
routers and below. A small mumber of routes in the DFZ will the tables
quite stable. This is not the case if every site in the world is going
to be in the routing table, instead, the routing table will change all
the time, making the routers spend a lot of time updating the tables.

Fast route lookup algorithms are necessary, not to allow for bigger
routing tables, but to allow an insane amount of packets per second.

Magnus Ahltorp
Department of Teleinformatics
Royal Institute of Technology
Stockholm, Sweden