Subject: [Idr] I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt (fwd)

From: Pekka Savola <[email-masked]>
Date: Fri, 21 May 2004 07:21:37 +0300 (EEST)

FYI --

As there seemed to be consensus for moving RFC 1863 to historic, I 
made a short I-D to document it.

Comments, adoption as WG doc, ...?

---------- Forwarded message ----------
Date: Thu, 20 May 2004 16:01:08 -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-savola-idr-rfc1863-historic-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Request to Move RFC 1863 to Historic
	Author(s)	: P. Savola
	Filename	: draft-savola-idr-rfc1863-historic-00.txt
	Pages		: 4
	Date		: 2004-5-20
	
This memo requests moving RFC 1863, A BGP/IDRP Route Server"M
alternative to a full mesh routing, to Historic status.  This memo"M
also Obsoletes RFC 1863.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-savola-idr-rfc1863-historic-00.txt

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 21 May 2004 15:19:01 -0400

Seems a good idea to me.

--John

>Comments, adoption as WG doc, ...?
...

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 21 May 2004 15:19:01 -0400

Seems a good idea to me.

--John

...

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 May 2004 10:56:59 -0400

I support the adoption of this.  It should go quickly.

I suggest a few changes though:

:   In the modern terminology, the term "route server" refers to a
:   designated, normal BGP speaker set up for specific purposes such as
:   data collection or retrieval; such route servers do not implement RFC
:   1863.  For clarity, in the context of this document the term "RFC
:   1863 route server" is used to refer to a route server as specified in
:   RFC 1863.

In "modern teminology", route servers are actually route servers in
the traditional proxy routing sense.  The current route collectors have,
IMO, co-opted the term.  So, I'd suggest something along these lines:

By common usage, a "route server" can refer to one of two things:
A "routing proxy" such as that used in the early NSF-Net at the
NAPs or a "route collector" which is used for routing data collection
and retrieval.  The latter case is also called a "looking glass".

Neither form of these route servers had implemented RFC 1863.  

For clarity, in the context of this document, the term "RFC 1863
route server" is used to refer to a route server as specified in RFC 1863.

:    Implementations of RFC 1863 route servers do not exist, and are not
:    used as an alternative to full mesh routing.  Therefore the RFC 1863
:    route server concept is considered extinct and RFC 1863 is requested
:    to be moved to Historic status.

If something is extinct, should it not have lived before?  

Minor tweaks suggested:

Implementations of RFC 1863 route servers do not exist and are not
used as an alternative to full mesh routing.  Therefore RFC 1863
is requested to be moved to Historic status.

:   The most common technique as an alternative to full mesh routing is
:   to use BGP route reflectors [2].  Conferedations [3] and/or dividing
:   the autonomous system to multiple private AS numbers have also been
:   used.  IDRP itself has never been standardized by the IETF and can be
:   considered obsolete.

Two comments here aside from some punctuation suggestions:
1. Do people typically deploy private AS's outside of a confederation
   context?
2. While IDRP never made it as an IETF specification, I believe it is
   still a valid ISO specification and thus our opinion of its obsolteness
   isn't so important.  I'll let Sue comment on this.

Suggested changes:

Current techniques that serve as an alternative to full mesh routing
include BGP Route Reflectors [2] and BGP Confederations [3].

Do [2] and [3] need to be made Normative references in this document?

Additionally (Danny), RFC 3065-bis needs to make sure RFC 1863 is used
as an Informative Reference.

If the updates to RFC 2796 and 3065 get published after this, we should
make sure they reference this memo.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 24 May 2004 10:56:59 -0400

Minor tweaks suggested:

Suggested changes:

-- 
Jeff Haas 
NextHop Technologies

---

From: Andrew Lee <[email-masked]>
Date: Mon, 24 May 2004 10:41:38 -0500

> Do [2] and [3] need to be made Normative references in this document?

I do not think that the language refering to multiple AS numbers 
should be removed.  My suggestion is to broaden it, as there are/have 
been networks that use public AS numbers as well as private ones to 
divide the network into chunks, either as a long term design or for a 
shorter term during transitional periods such as network integrations.

---

From: Andrew Lee <[email-masked]>
Date: Mon, 24 May 2004 10:41:38 -0500

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 May 2004 14:30:32 -0400

> > 1. Do people typically deploy private AS's outside of a confederation

The NSFNET had about 20 public AS numbers just in the NSFNET T3
backbone alone.

Confederations and private AS removed the need to do that sort of
thing.

For a long time UUNET had 701 and 702 (Europe) and other providers had
multiple AS.

I'm not sure if any have multiple AS other than those that use
confederations these days.

It is worth noting that those that use confederations typically use
both confederations and route reflectors within the confederations to
make really big networks scale better.  Aggregation is done at
confederation boundaries (a scaling consideration).

> shorter term during transitional periods such as network integrations.

We are talking about the Internet and use of IDRP in IP.  IDRP is
about as alive as CLNP in the Internet (completely dead and not even
discussed anymore).  This may be important to anyone reading IDR
archives of 8-10 years ago when BGP5 == IDRP was commonly stated.

Curtis

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 May 2004 16:22:20 -0700

Jeffrey,

> route server" is used to refer to a route server as specified in RFC 1863.

<WG co-chair hat off>

Let's keep in mind that the purpose of this document is to
move rfc1863 to historic, and *not* to describe the various uses
of the term "route server" (this is not to say that describing
various uses of the term "route server" is useless, it is just
that it is outside the scope of *this* document).

With this in mind how about replacing:

   In the modern terminology, the term "route server" refers to a
   designated, normal BGP speaker set up for specific purposes such as
   data collection or retrieval; such route servers do not implement RFC
   1863.  For clarity, in the context of this document the term "RFC
   1863 route server" is used to refer to a route server as specified in
   RFC 1863.

with the following:

   In the context of this document the term "RFC 1863 route server"
   is used to refer to a route server as specified in RFC1863.
   Other uses of the term "route server" are outside the scope
   of this document.

>    isn't so important.  I'll let Sue comment on this.

Either this, or instead of "IDRP itself" say "IDRP for IP".

> include BGP Route Reflectors [2] and BGP Confederations [3].

I like this change. 
  
> Do [2] and [3] need to be made Normative references in this document?

I don't think so.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 24 May 2004 16:24:47 -0700

Andrew,

> shorter term during transitional periods such as network integrations.

Please let's keep the scope of this document in mind - the scope
is to document why rfc1863 should be moved to historic. It is *not*
within the scope of *this* document to describe various alternatives 
to full I-BGP mesh.

Yakov.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 24 May 2004 22:12:18 -0400

In message <[email-masked]>, Yakov Rekhter writes
>    Other uses of the term "route server" are outside the scope

Good suggestion on the wording.

A little history on this.

Bay Networks was still Wellfleet and Wellfleet had no BGP
implementation at all until about June 1994 when they finished a BGP-3
implementation shortly after BGP-3 became obsoleted by the CIDR
deployment in April 1994.  Welfleet was having a lot of trouble with
the BGP policy code and Cisco's policy code just plain didn't work
unless you had a very small number of policy statements.  There was
also a problem shared by most commercial routers at the time in that
they didn't have enough RAM to properly support BGP.  At the time
gated was by far the best BGP-4 code available; the policy code worked
and scaled well, the bugs later studied by Craig Labovitz were not
present in gated, and you could get pizza box computers that were fast
and had plenty of RAM.  Deploying a router with one peering and no
routing policy seemed like an attractive idea to some people (at least
people at Wellfleet if no where else).  Dimitri was hoping to find an
acceptable solution that didn't involve a full BGP implementation on
the router.  The idea didn't fly but the RFC lives on, so far.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 May 2004 10:21:12 -0400

Yakov,

> that it is outside the scope of *this* document).

My original issue with the text was that it was limiting the definition

>    Other uses of the term "route server" are outside the scope

I'm cool with this.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 May 2004 23:34:20 +0300 (EEST)

> confederations these days.

This was already out of scope here, but yes, I think private ASNs are 
being used without conferederations.  In our network, we definitely 
use them.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings