Protocol Action: 'Detecting Inactive Neighbors over OSPF Demand Circuits' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Tue, 15 June 2004 22:28 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22828 for <ospf-archive@LISTS.IETF.ORG>; Tue, 15 Jun 2004 18:28:53 -0400 (EDT)
Received: from vms.dc.lsoft.com (209.119.0.2) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <14.00DE5543@cherry.ease.lsoft.com>; Tue, 15 Jun 2004 18:28:26 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 21627966 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 15 Jun 2004 18:21:51 -0400
Received: from 132.151.6.71 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 15 Jun 2004 18:11:51 -0400
Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BaM30-0001Cd-Qx; Tue, 15 Jun 2004 18:04:50 -0400
X-test-idtracker: no
Message-ID: <E1BaM30-0001Cd-Qx@megatron.ietf.org>
Date: Tue, 15 Jun 2004 18:04:50 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: 'Detecting Inactive Neighbors over OSPF Demand Circuits' to Proposed Standard
Comments: To: IETF-Announce <ietf-announce@ietf.org>
Comments: cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, ospf chair <john.moy@sycamorenet.com>, ospf chair <acee@redback.com>, ospf chair <rohit@utstar.com>
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list

The IESG has approved the following document:

- 'Detecting Inactive Neighbors over OSPF Demand Circuits '
   <draft-ietf-ospf-dc-07.txt> as a Proposed Standard

This document is the product of the Open Shortest Path First IGP
Working Group.

The IESG contact persons are Bill Fenner and Alex Zinin.

Technical Summary

  The Demand Circuit Extension for OSPF (RFC 1793) reduces routing protocol
  overhead on demand circuit links by eliminating Hello messages over such
  links.  This prevents the link from being kept alive simply by routing
  protocol traffic, but also prevents the detection of a dead neighbor over
  a live demand circuit.  Detecting Inactive Neighbors over OSPF Demand
  Circuits introduces a mechanism which probes the liveness of the neighbor
  on a demand circuit only when other traffic is flowing and/or with packets
  that do not count towards keeping the link up.  In this way, neighbor
  liveness may be detected while retaining the on-demand nature of the
  circuit.

Working Group Summary

  There was consensus in the OSPF Working Group on this specification.

Protocol Quality

  The protocol was reviewed for the IESG by Bill Fenner.  There are
  two implementations.

RFC-Editor Note:

In the second paragraph of section 2, please replace the acronym
"NBMA" with "Non-Broadcast Multi-Acess (NBMA) links".

In the third paragraph of section 2, please replace the acronym
"LSDB" with "Link State Database (LSDB)".

Please change the title of section 5 to "Deployment Considerations".