OK, here are detailed technical arguments which have not been
addressed:
>From Section 4 (Concerns):
- The primary ISP is the sole interface for the multihomed
customer to the Internet other than the ISPs the customer has
directly connection with. Outages such as one between ISP-1 and
ISP-4 would impact the reachability from customers of ISP-4 to
Customer-A even though ISP-2 still has good connection to ISP-4.
However, if the primary ISP is a good quality ISP, this sort of
situation should happen rarely. The reason is that it's common
practice that an ISP, especially good quality ISP, has multiple
connections to other big ISPs at different geographical locations.
Good quality ISPs also have robust network design to prevent any
failure to impact the whole network. Choosing a good quality and
robust ISP as primary ISP is a good practice.
This is really the crux of the problem with the solution put forth in
the document. The assumption that a given ISP will never have
failures, or that rare failures are acceptable to customers who
multihomed for redundancy, is simply not valid from an engineering
perspective. If the primary goal of multihoming were load sharing,
this solution would provide one, potentially very complicated,
answer. However, the issue of multihoming for redundancy is totally
ignored, drawing into question the need for a second ISP in the
equation at all. Why not simply purchase additional bandwidth from
the same ISP?
>From Section 4 (Concerns):
It is desirable to have solution which provides perfect redundancy
and, at the same time, simplicity to scale management and operation.
In the absence of a perfect solution, the trade-off needs to be made.
The author believes that it is very important that the solution has
to be simple and manageable. Manageability should be the top
consideration.
If managability of the solution is to be the top consideration, the
response put forward does not measure up. In the name of avoiding
routing table growth the author has suggested adding significant
complexity to the configuration and management of multihomed customers
without showing any benefit for the effort.
An area not addressed at all in the document is that of multihoming
for access to networks attached to a given ISP, rather than access to
that ISP. For example, using the diagram above, if Customer-A
purchased connectivity to ISP-2 because ISP-2 had better connectivity
to ISP-4, then the offered multihoming solution is of no use. ISP-4
will never see reachability to Customer-A via ISP-2.
Now, if everyone is done threatening legal action, perhaps we could
return to the business of network engineering.
Ben
On Wed, Jun 28, 2000 at 07:13:33AM -0700, Jessica Yu wrote:
> By the way, unless there are technical arguments and
> credible facts in your responses, I am not going to
> send more messages.
>
> --Jessica
>
> --- Jessica Yu <[EMAIL PROTECTED]> wrote:
> >
> > This has already been answered in the thread of
> > discussion on this topic a while back. Please go
> > back
> > to read the thread before you make any more
> > inaccurate
> > and irresponsible assertions.
> >
> > You said most network operators see no value. Where
> > did you get this? Who are the most operators? Please
> > be more responsible when you make assertions.
> >
> >
> > --Jessica
> >
> > --- Ben Black <[EMAIL PROTECTED]> wrote:
> > > 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
> > >
> > > On Tue, Jun 27, 2000 at 04:27:40PM -0400, Jim
> > Bound
> > > wrote:
> > > > 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
> > > >
> > >
> >
> --------------------------------------------------------------------
> > > 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]
> > >
> >
> --------------------------------------------------------------------
> >
> >
> > __________________________________________________
> > 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]
--------------------------------------------------------------------
