Ben,
You observe that Jessica's proposal does not resolve all cases
of failover. True. This was obvious from the first draft. We
all agree.
Why does this make it inappropriate to publish the document,
as a solution for certain types of failover?
Brian
Ben Black wrote:
>
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
