Subject: Re: W.G. Last Call on "IPv6 Multihoming with Route Aggregation"

From: Jessica Yu <[email-masked]>
Date: Wed, 28 Jun 2000 07:13:33 -0700 (PDT)

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

---

From: Ben Black <[email-masked]>
Date: Wed, 28 Jun 2000 09:58:27 -0700

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Jun 2000 16:10:23 -0500

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

---

From: Ben Black <[email-masked]>
Date: Wed, 28 Jun 2000 14:57:17 -0700

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

---

From: Vijay Gill <[email-masked]>
Date: Wed, 28 Jun 2000 18:11:10 -0400

> RFC giving people the impression it has somehow been blessed as

I believe that this mail from Vernon S. pretty much sums it all up.

/vijay

 From: Vernon Schryver <[email-masked]>
 Message-Id: <[email-masked]>
 To: [email-masked]
 Subject: Re: The Non-IETF Informational RFC Publication Fiction
 X-Loop: [email-masked]

> From: Bill Manning <[email-masked]>

> ...
> I think things are headed in that general direction and I think it is a
> sad state of affairs. Historically, RFCs were used to document ideas, 
> both good and bad. The series covered the range of idea generation
> and expression and this was encouraged by the RFC editor. Now, many 
> "non-conformant" ideas are being released into the community as defacto 
> documents since it is too hard to get material documented in the RFC series 
> as either informational or experimental. This is in part due to the IESG/IAB
> review cycle that is now part of the process.

The alternative is many more and far worse circuses.
What happens when someone writes something like
draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-08.txt without what seems
to be that author's non-confrontational nature but with the attitudes of
D.J.Burnstein and Mohsen BANAN?

In the old days, the IETF was in fact closed because no one knew about
it, and the RFC editors did real editing.  The barriers to outsiders in
1986 were informal but much higher than they are now.  Even had he heard
of RFC's and wanted to publish some ideas as one 1985, Mohsen BANAN could
not have, at least not in the forms the modern IETF allowed.  As the public
discovered TCP/IP, the RFC printing press was in effect forced open.  The
relatively recent attempt to make the IETF a free vanity publisher is a
growing, inevitable disaster that pleases no one.

Things have changed in the last 15 or 20 years.  The publishing services
of the IETF and (and ISI) are no longer needed except for official products
of working groups and perhaps except for open mailing lists.  Each of us
can trivially operate our own vanity publishing houses.  Consider how very
much better things would have been for everyone including Mohsen BANAN
had the IETF said "those ideas are interesting, but until they have been
implementated and tested, and thereby attracted an IETF Working Group to
sponsoring them, all we can do is suggest that you mention a mailing list
and URL for your documents in the IETF mailing lists."  And similarly for
TAP vs. Ident and whichever other excitements involving DJB that Mohsen
BANAN is talking about.

>                                                This practice leads to 
> closed environments, documentation, code and operations.  Not what I would 
> have hoped for in an evolved Internet.

That is clearly wrong at least about code.  Close vs. open code has nothing
one way or another to do with the IETF's publishing polices, as
demonstrated by the closed and open implementations of offical IETF
protocols, not to mention the "individual submissions."  Besides, there
has been practically no code ever published by the IETF.  I suspect one
RFC contains most of the code in all existing RFC's.

It's also not clear that open publishing leads to open protocols or
anything else besides open (esp. vanity) publishing.  Contrast the
protocols that Microsoft has described with RFC's with the availability
of source implementing them and the chance of anyone outside Redmod fixing
or convincing anyone to fix even their most egregious and obvious bugs.

What made sense as a semi-formal way to slightly polish items discussed
in mailing lists has nothing to do with the polices, procedures and
even goals of a competitor or co-equal of the ANSI and IEEE and member
of the ITU.

The IETF should keep the best parts of the RFC process, including free
access to RFC text.  However, for better or worse, the IETF doesn't
have the organization, policies, procedures, people, or billing systems
to operate a major vanity press catering to the under appreciated
computer geniuses of the world.

Vernon Schryver    [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jun 2000 09:28:54 -0500

Publishing an informational RFC does not "bless" an idea.

   Brian