Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation"

From: Jessica Yu <[email-masked]>
Date: Mon, 26 Jun 2000 14:19:27 -0700 (PDT)

So now, we changed topic to multihoming to two ISPs
with hole-punching, right? This is what we do today
with two issues:

a) increase the size of the global routing table since
it can not be aggregated, and

b) The longer prefixes (the hole) could be blocked by
certain providers resulting in no access to that part
of the Internet.

I think this mechanism works today in IPv4 and there
is no reason why can not be used for Ipv6. However, it
does not hurt to have other mechanism which allow
better aggregation available if there are concerns
about the scaling and routability issues listed above.

Speaking as a person who had worked for ISPs and dealt
with operations for many many years, I submit there
are entities who would like to have the arrangement as
described in the ID.

Thanks!

                                     --Jessica

--- Vijay Gill <[email-masked]> wrote:
> On Mon, 26 Jun 2000, Jessica Yu wrote:
> 
> Jessica,
> 
> 
> > The tail circuits to the customer have the
> opportunity to go through
> > diverse infrastructure (e.g. fiber) which would
> increase reliability.
> 
> So would they if I just went to two different ISP's
> and got them to punch
> a hole in their aggregate for the netblock assigned
> to me from the first
> ISP. [paragragh X]
> 
> > Instead of going to different POPs from the same
> ISP,
> > the customer will be able to go to the close POPs
> of
> > two ISPs. Therefore, the distance for the 2nd tail
> > circuit can be shorter resulting money saving.
> 
> See Paragraph X.
> 
> > The customer can reach part of the Internet (at
> least
> > customers of ISP2) without relying on ISP1. 
> 
> See Paragraph X.
> 
> This also buys me the additional safety of being
> shielded from complete
> failure of one of the upstream ISPs.  With network
> connectivity now
> becoming fundamental to doing business, I submit
> that there isn't a single
> sensible company who would rely upon this draft
> under discussion for a
> critical need.  Instead most of them would
> immediately try and go for
> Paragraph X.  Speaking as an operator, when clients
> are throwing $n
> million contracts at you, there is a powerful
> incentive to accomodate
> them.
> 
> /vijay
> 
> 

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
--------------------------------------------------------------------
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: Mon, 26 Jun 2000 14:36:51 -0700

> it can not be aggregated, and

This issue verges on irrelevant given current hardware
(even completely ignoring improvements in hardware over
time).

> certain providers resulting in no access to that part

No access to certain parts of the net during failure.
This would seem to be a feature superior to your proposal
in that you can access parts of the net beyond simply
your direct peers.

> about the scaling and routability issues listed above.

Agreed, and I would add that those mechanisms should be
as consistent as possible with the approaches in IPv4 unless
there is a compelling technical reason for a previously
unused mechanism.  The Itojun proposal, based on the 
existing RFC2260 approach, meets those requirements.  Your
proposal introduces a new mechanism which lacks a compelling
technical case.  It is for these reasons that I am arguing it
not be moved further along the track.

Ben

---

From: Jim Bound <[email-masked]>
Date: Mon, 26 Jun 2000 21:16:09 -0400

Chairs,

I stongly support this draft moving forward.

regards,
/jim

---

From: Ben Black <[email-masked]>
Date: Mon, 26 Jun 2000 18:37:21 -0700

Pending any description of how this draft provides *any*
technical benefit (for example, what situations it covers
which cannot be accomplished for efficiently and effectively
with the RFC2260-based proposal), I am strongly against
this draft moving forward.

Ben

---

From: [email-masked] (Niels M�ller)
Date: 27 Jun 2000 16:46:32 +0200

> this draft moving forward.

I'm I bystander here, but as far as I can see, it appears that some
people like the approach, and really want to try it out. Then it ought
to be a good thing to have it published so that both people
implementing it and people shooting it down can have a clear
description to refer to. After all, we're talking about an
_informational_ rfc, not standards track.

Regards,
/Niels

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jun 2000 11:21:05 -0500

On the basis that this draft is helpful in certain circumstances, 
I support its publication.

It doesn't invalidate the 2260-like approach, which I agree is 
better in other circumstances. Having multiple solutions is good.

  Brian Carpenter

---

From: Ben Black <[email-masked]>
Date: Tue, 27 Jun 2000 17:11:33 -0700

> people like the approach, and really want to try it out. Then it ought

Actually, I am looking for any indication that there is, in fact,
*anyone* who wants to use this approach.  So far, all my requests for
an application of this approach which isn't *better* handled with
another, existing method have gone unanswered.

> description to refer to. After all, we're talking about an

I do not see why an informational RFC is needed just as a point of
reference for a debate.  The draft is just fine for that purpose.
An informational RFC in this context should be documentation of
a potential approach offering benefits to the network operator
not offered by other approaches.

So, I once again ask that someone provide a reasonable scenario
in which the approach in the J. Yu draft offers benefits over the
RFC2260/Itojun approach.

Ben