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