What makes it inappropriate at this time is the lack of a clear
definition of *when* this solution is more appropriate than others.
If it only provides a subset of the functionality, has minimal
redundancy benefits, increases management overhead, and doesn't
have a clearly met set of goals, why should it be put forth as an
RFC giving people the impression it has somehow been blessed as
a good idea?
Ben
On Wed, Jun 28, 2000 at 04:10:23PM -0500, Brian E Carpenter wrote:
> 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]
--------------------------------------------------------------------
