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

From: Jessica Yu <[email-masked]>
Date: Tue, 27 Jun 2000 08:32:55 -0700 (PDT)

I found it very trouble-some that you make assertions
without compelling (sometimes inaccurate) technical
arguments neither knowledge of current practice. This
is showing in the message below (see my response
inline) and the thread of discussion last year on the
same topic. 

Also, please go back and read the thread on this topic
on this list. What you pointed out about my proposal
had been either dismissed and/or answered/addressed.
It was based on that the WG decided to move forward.

Inline comments below ...
                               
--- Ben Black <[email-masked]> wrote:
> On Mon, Jun 26, 2000 at 02:19:27PM -0700, Jessica Yu
> wrote:
> > 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
> > 
> 
> This issue verges on irrelevant given current
> hardware
> (even completely ignoring improvements in hardware
> over
> time).

Are you saying that reducing the routes in the global
routing table to improve routing scalability is
irrelevant? You are deadly wrong on this. Go ask the
ISP community. Go read I-Ds including IAB's routing
workshop report on routing scalability and stability.
You may still think that memory on router is the issue
but that's not the only issue, as well known in the
operation community.

In fact, rfc2260's main motivation is to reduce
prefixes in the global routing table. 

> 
> > b) The longer prefixes (the hole) could be blocked
> by
> > certain providers resulting in no access to that
> part
> > of the Internet.
> > 
> 
> 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.

Obviously, you do not understand this. What I am
talking about is that the second connection can not be
a backup since the longer prefix will be filtered.
Your assertion of this is better than the mechanism
described in my I-D raised the question if you
understand the proposal.

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

You seem to indicate that the current v4 multihoming
practice is using rfc2260. That is just simply untrue.
The majority multihoming sites just simply advertise
one prefix. Some of those prefix are PI and some from
one of providers CIDR block with no tunnels or other
involved whatsoever. By making this assertion, it
really shows that either you do not understand what
the current practice is; or you do not understand
rfc2260 or Itojun proposal; or neither.

> Ben

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

__________________________________________________
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: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 16:27:40 -0400

Jessica,

Your work should go thru as info RFC I see no reason at all to defend
your draft any further for that goal.  You have done a good job to give
us a means to work with our ISP customers with IPv6 to set up some
pilots with IPv6 using BGP+w/v6 to begin testing this and I also will be
proposing that 3GPP look at your proposal very seriously for IMT2000.

Chairs - again there is no compelling reason past or present to prevent
this work from moving to info rfc and begin using it as a tool for the
many IPv6 pilots springing up with our customers.

I am not saying the discussion is 100% complete and I don't think it
ever will be as we evolve IPv6, but I do think the decision has been
made, and we should move on here.

regards,
/jim

---

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

In all seriousness, would someone please explain the benefits of
this approach in comparison tot he RFC2260 approach?

I have *never* seen a single example and judging by the feedback
the draft has gotten, most network operators see no value to it
whatsoever.  That alone should be a strong indication the proposal
should be closely scrutinized before acceptance for any further
circulation.

Simply voting to have a draft moved to RFC without answering
numerous, legitimate questions regarding its value would seem a
very poor method for developing quality technical documents.

Ben

---

From: Jim Bound <[email-masked]>
Date: Tue, 27 Jun 2000 23:33:43 -0400

We don't have to answer to you or anyone else.  Obviously people don't
care about your issue as I see no support for your proposed wall against
the aggregation draft.  I think its in the decision of the chairs now.
As far as no network operators care I called two ISP network operators
today and both will pilot jessica's proposal simply to see if
implementors can make it work.  They like I feel no duty to respond to
"you".  Got it!!!!

regards,
/jim

---

From: Vijay Gill <[email-masked]>
Date: Tue, 27 Jun 2000 23:46:39 -0400

> the aggregation draft.  I think its in the decision of the chairs now.

Incorrect. There has bave been questions about the proposed value of this
I-D.

> implementors can make it work.  They like I feel no duty to respond to

A better metric would probably be asking some CUSTOMERS.  Speaking as a
customer, I'd just get two separate lines with two address blocks from
each provider to ensure against _autonomous system wide isp failure_,
before I'd trust an bit of data to this scheme. This is much more common
than people seem to realize, having been in midst of several on a global
scale. Including some interesting area wide failures TODAY (see thread on
nanog).

Wearing my provider hat, I _assure_ you we can barely get standard point
to point circuits up amongst ourselves, much less co-ordinate setup of
selective routing. Special casing does not scale.

MBONE and 6BONE are set up as special cases with engineers working on
them, but trying to get something on this scale for several thousand
customers just isn't going to work.

/vijay

> /jim

Vijay Gill                         |The (paying) customer is always right.
[email-masked], [email-masked]  |                  - Piercarlo Grandi
http://umbc.edu/~vijay             | Eagles may soar, but weasels don't get
These are my opinions only.        | sucked into jet engines.

---

From: Ben Black <[email-masked]>
Date: Tue, 27 Jun 2000 20:51:13 -0700

> inline) and the thread of discussion last year on the

I witnessed a lot of contention, but certainly no resolution.
I also saw no evidence of any inaccuracies on my assertions.
Given that I am in fact a network operator quite familiar with
current practice and other network operators in similar positions 
have been agreeing with my concerns, I don't see how you
reached this conclusion.

> It was based on that the WG decided to move forward.

Oh, it was definitely dismissed, but I would say not addressed
or answered.

> irrelevant? You are deadly wrong on this. Go ask the

No, I am not saying that.  What I *am* saying is that the
terror of a few years ago that the routing table would grow
beyond hardware limits and cause some sort of meltdown has
proven quite false.  Moore's law is still alive and well and
giving us continuing increases in hardware capacity in excess
of the increase in routing table size.  Expending significant
effort on *decreasing* the table size would seem counter to
all trends in router development.

> prefixes in the global routing table. 

Indeed.  That's why I have been vocally supporting simply
updating RFC2260 rather than introducing a new and questionable
approach.

> described in my I-D raised the question if you

I understand that completely and that was exactly my point.
Your proposal gives extremely limited benefit, if any.  If
we are to assume that more specific prefixes will be filtered,
then the RFC2260 system offers the better alternative.

> practice is using rfc2260. That is just simply untrue.

Correct, current practice indicates little concern for table
growth beyond what is convenient.  What does this tell us about
the amount of effort we are expending on a "solution" to this
alleged problem?

> rfc2260 or Itojun proposal; or neither.

There is a third possibility which is that you simply are not
understanding the points I have made.  Judging by the comments
from other operators, I would assert it is not due to a lack of
clarity on my part.  Let me state my points again:

1) Fears of routing table growth are greatly exaggerated.
2) Even assuming routing table growth is the horror some seem to think,
	proposals to address the problem should be similar to those put
	forth (and never used) for IPv4 and should offer definite benefits
	over existing approaches.
3) Your draft is not similar to any for IPv4 and, once again, does not
	show any benefit whatsoever over the RFC2260-based approach.
4) There has not been a scenario presented in which your approach is a
	clear benefit.

Ben

---

From: Ben Black <[email-masked]>
Date: Tue, 27 Jun 2000 20:53:46 -0700

Is this to be a "my network operators are bigger than yours" exchange?
I believe those in support of this proposal are actually obligated to
respond if they wish the draft to move forward.  If those in support of 
this proposal never speak up with the details of their support, how is
this a working group at all?

Ben

---

From: Jeff Williams <[email-masked]>
Date: Tue, 27 Jun 2000 23:26:14 -0700

Vijay and all,

  I agree Vijay.  It seems obvious that Jim Bound here seems th have
a personal dispute with Ben and seems to be touting the ICANN
line here.  Nothing unusual there though....

> These are my opinions only.        | sucked into jet engines.

Regards,
--
Jeffrey A. Williams
Spokesman INEGroup (Over 112k 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-1800 x1894 or 9236 fwd's to home ph#
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208

---

From: Jim Bound <[email-masked]>
Date: Wed, 28 Jun 2000 09:13:15 -0400

>Incorrect. There has bave been questions about the proposed value of this

No it is correct.  True the "Chairs" and authors have to respond and 
I should have made that distinction, I or other WG members do NOT HAVE to 
respond to you or anyone else.  Again Got It!!!!

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 28 Jun 2000 09:23:29 -0400

I am touting nothing about ICANN and have no personal issues with
anyone or Ben.  Do not make another assumption about me again on a public 
mail list or I will have one of my family attorneys call you, as you are
in the U.S.

regards,
/jim

---

From: Jim Bound <[email-masked]>
Date: Wed, 28 Jun 2000 09:20:18 -0400

Don't blame the working group blame me.  I have heard your arguments and
I have heard Jessica's responses.  There is nothing to add.  I think
Jessica's proposal should be moved forward and be left to the market to
make determination if it is useful.  If rfc2260 can be informational so
can this.  Its that simple.  But my point is I don't "have" to respond
to you but CAN TELL the chairs I support this being moved forward.

regards,
/jim

---

From: Vijay Gill <[email-masked]>
Date: Wed, 28 Jun 2000 14:02:52 -0400

> respond to you or anyone else.  Again Got It!!!!

Relax Jim.  Don't take it so personally.

/vijay