--- 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]
--------------------------------------------------------------------
