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