Ben,
You are not listening. Nobody said it was superior. It is one choice among
several. We like choice.
Brian
Ben Black wrote:
>
> Please note that I specifically said "more appropriate", not
> just "at all appropriate". Your draft describes a set of
> scenarios where it is applicable, but does not explain how it
> is superior in any way to other approaches, such as RFC2260.
>
> Ben
>
> On Thu, Jun 29, 2000 at 07:33:20AM -0700, Jessica Yu wrote:
> > --- Ben Black <[EMAIL PROTECTED]> wrote:
> > > What makes it inappropriate at this time is the lack
> > > of a clear
> > > definition of *when* this solution is more
> > > appropriate than others.
> >
> > This is again another inaccurate assertion. In section
> > 4 of my I-D (attached below), it clearly documented in
> > what situations this approach is more suitable.
> >
> > At this point, I am not even sure if you read my draft
> > or not. You have been making so many inaccurate
> > assertions and unfound claims that I do not think what
> > you are saying is credible any more.
> >
> > --Jessica
> >
> > 4. Conclusions
> >
> > It wouldn't be hard to understand that even those
> > enterprises desire
> > multiple Internet connections may have different
> > criterias and
> > resource constrains for implementing such
> > connection. Some may
> > require absolute redundancy while most may only
> > desire reasonable
> > redundancy. This document offers a viable
> > multihoming solution for an
> > enterprise to choose based on its particular
> > requirements and
> > constrains. The multihoming mechanism described in
> > this document is
> > applicable to various multihoming scenarios, the
> > most suitable
> > environment for deploying it are:
> >
> > a. ISPs serving the multi-homed site have direct
> > connection(s) to
> > each other. Although such direct connection is
> > not required, it
> > would make arrangement simpler and will also
> > improve aggregation
> > by limiting specific routes visible only to ISPs
> > serving the
> > multi-homed site.
> >
> > b. Enterprises with requirements for good
> > redundancy but not
> > absolute redundancy.
> >
> > c. Enterprises with limited to resource for
> > onsite sophisticated
> > network administrators
> >
> > d. Enterprises able to choose a robust ISP as
> > primary provider.
> >
> > Although not the main focus, the mechanism
> > described in this
> > document can also be used to improve routing
> > scalability within
> > networks shares one aggregation block or Top
> > Level Aggregator
> > (TLA).
> >
> >
> > --- Ben Black <[EMAIL PROTECTED]> wrote:
> > > 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:
> > >
> > === message truncated ===
> >
> >
> > __________________________________________________
> > 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]
--------------------------------------------------------------------
