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).
> 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.
> 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.
Ben
> 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/
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
