A slow start to September

It takes a couple of months to get back in gear after summer vacation--and the IETF is no exception.

By Pete Loshin | Posted Oct 7, 2000
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

IETF Corner

How much do you normally get done in the first two weeks after the end of summer vacation? If you're like the Internet Engineering Task Force (or at least the RFC Editor) this year, probably not a whole lot--a bare seven new RFCs were published (one a BCP), and just one IESG workgroup action and one proposed workgroup were announced. No document or protocol actions were taken, either; and precious few last calls, for that matter.

No matter. This time, we can look at the new RFCs in more detail. And we can anticipate a more active end to the month, as over a dozen document and protocol actions were announced on September 18 (I'll take a peek at the most interesting of them so you won't have to wait).

New RFCs

Table 1 lists the new RFCs announced between September 5 and September 17. Not only is the pace of RFC releases maddeningly slow, some of these are stragglers from August. Even though there are just seven, they include some important stuff, such as a new BCP about network congestion control principles and an Informational that reports on an IAB routing workshop held over two years ago. Read on to find out what it's all about.

Table 1: RFCs announced August 21-September 4, 2000

Newest best current practice

The Best Current Practice (BCP) series just gets better and better. These documents consistently deliver key information about core Internet practices, and the latest--BCP 41 (also known as RFC 2914), "Congestion Control Principles"--delivers an excellent foundation for anyone who wants to know more about congestion control in the Internet. This one is a must-read for anyone in the business of delivering packets over the Internet, as well as anyone whose business depends on getting those packets.

According to the abstract, "The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols."

Author Sally Floyd, with the AT&T Center for Internet Research at ICSI (ACIRI), begins with an overview of current IETF standards covering congestion control, and continues with discussions of the development of end-to-end congestion control, the role of the standards process, description of congestion collapse, and forms of end-to-end congestion control. She concludes with a special section covering TCP congestion along with the obligatory (but in this case quite meaningful) security considerations.

Refreshing BGP and other routing news

Until this month, no mechanism would allow a BGP-4 router to dynamically request a BGP peer to readvertise its routes. With publication of RFC 2918, "Route Refresh Capability for BGP-4," this lack has been addressed with a new Proposed Standard.

RFC author Enke Chen of Redback Networks Inc. wrote a very short (three pages) document that describes the "Router Refresh Capability" for BGP so that (for example) routing policy changes can be effected without disrupting routing.

Perhaps more interesting and certainly more substantial is RFC 2902, "Overview of the 1998 IAB Routing Workshop." Though hardly breaking news, this Informational's authors include such Internet luminaries as Cisco's Stephen Deering and Sun's Radia Perlman, and it provides more than merely a two-year old workshop summary.

Attended by about 30 of the leading Internet routing experts, this workshop generated significant results that are directing much of the IETF's routing efforts. The RFC summarizes the discussions; but more important, it lists conclusions reached by the group and suggestions for future work. Some of the results will surprise you: For example, the very first conclusion reported is that "Most of the current unicast routing stability problems can be fixed with improved implementation."

If you want more details, check out the RFC itself and then take a look at the IAB Web site (www.iab.org) for the full report.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter