On Tue, Jun 27, 2000 at 08:32:55AM -0700, Jessica Yu wrote:
> 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.
>
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.
> 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.
>
Oh, it was definitely dismissed, but I would say not addressed
or answered.
> Inline comments below ...
>
> --- Ben Black <[EMAIL PROTECTED]> 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
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.
> 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.
>
Indeed. That's why I have been vocally supporting simply
updating RFC2260 rather than introducing a new and questionable
approach.
> >
> > > 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 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.
> >
> > > 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.
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?
> 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.
>
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
> >
> > 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 PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
