Protocol Action: 'OSPF for IPv6' to Proposed Standard

The IESG <> Fri, 16 May 2008 20:25 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 731CC28C2B4; Fri, 16 May 2008 13:25:20 -0700 (PDT)
Received: by (Postfix, from userid 30) id 2FE3228C2A7; Fri, 16 May 2008 13:25:17 -0700 (PDT)
X-idtracker: yes
From: The IESG <>
To: IETF-Announce <>
Subject: Protocol Action: 'OSPF for IPv6' to Proposed Standard
Message-Id: <>
Date: Fri, 16 May 2008 13:25:18 -0700
Cc: ospf mailing list <>, ospf chair <>, Internet Architecture Board <>, RFC Editor <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

The IESG has approved the following document:

- 'OSPF for IPv6 '
   <draft-ietf-ospf-ospfv3-update-23.txt> as a Proposed Standard

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

The IESG contact persons are David Ward and Ross Callon.

A URL of this Internet-Draft is:

Technical Summary

   This document describes the modifications to OSPF to support version
   6 of the Internet Protocol (IPv6).  The fundamental mechanisms of
   OSPF (flooding, Designated Router (DR) election, area support,
   (Shortest Path First) SPF calculations, etc.) remain unchanged.
   However, some changes have been necessary, either due to changes in
   protocol semantics between IPv4 and IPv6, or simply to handle the
   increased address size of IPv6.  These modifications will necessitate
   incrementing the protocol version from version 2 to version 3.  OSPF
   for IPv6 is also referred to as OSPF Version 3 (OSPFv3).

   This document is organized as follows.  Section 2 describes the
   differences between OSPF for IPv4 (OSPF Version 2) and OSPF for IPv6
   (OSPF Version 3) in detail.  Section 3 provides implementation
   details for the changes.  Appendix A gives the OSPF for IPv6 packet
   and Link State Advertisement (LSA) formats.  Appendix B lists the
   OSPF architectural constants.  Appendix C describes configuration

Working Group Summary

   This document could be considered the lifework of Acee Lindem. The doc
was originally WG LC'ed at rev 11 (we are at 21 now). The document
represents a complete overhaul of the specification of OSPFv3 from
something that was a "sketch" by the original authors to something that is
now widely deployed.  

Document Quality

   There are multiple deployed implementations of OSPFV3 and the document
is of excellent quality at this point. It has been through multiple LCs,
edits, revisions, clarifications and had a large amount of expert review.
It is believed that OSPFV3 can be implemented from this specification.


  DWard is the shepherding AD and been working/discussing the document
for it seems 10 years.

proto-writeup below:

 1. Have the chairs personally reviewed this version of the Internet 
     Draft (ID), and in particular, do they believe this ID is ready
     to forward to the IESG for publication?


  2. Has the document had adequate review from both key WG members and
     key non-WG members? 


     Do you have any concerns about the depth or breadth of the reviews
     that have been performed?
     No. This document is a counterpart to rfc3623 and uses similar
     mechanism as specified in rfc3623.
  3. Do you have concerns that the document needs more review from a
     particular (broader) perspective (e.g., security, operational 
     complexity, someone familiar with AAA, etc.)?


  4. Do you have any specific concerns/issues with this document that
     you believe the ADs and/or IESG should be aware of? For example,
     perhaps you are uncomfortable with certain parts of the document,
     or have concerns whether there really is a need for it. In any event,

     if your issues have been discussed in the WG and the WG has
     indicated it that it still wishes to advance the document, detail
     those concerns in the write-up.


  5. How solid is the WG consensus behind this document? Does it
     the strong concurrence of a few individuals, with others being
     or does the WG as a whole understand and agree with it?

     Since it's a similar mechanism as in use by OSPFv2, there is
     a strong consensus for this document.

  6. Has anyone threatened an appeal or otherwise indicated extreme
     discontent? If so, please summarise the areas of conflict
     in separate email to the Responsible Area Director.


  7. Have the chairs verified that the document adheres to all
     of the ID Checklist items ?

    Yes (used idnits 2.04.16 to verify)

  8. Is the document split into normative and informative references?
     Are there normative references to IDs, where the IDs are not
     also ready for advancement or are otherwise in an unclear state?
     here that the RFC editor will not publish an RFC with normative
     references to IDs, it will delay publication until all such IDs
     are also ready for publication as RFCs.)

    Yes, No

  9. What is the intended status of the document? (e.g., Proposed

    Proposed Standard

 10. For Standards Track and BCP documents, the IESG approval
     includes a write-up section with the following sections:

    * Technical Summary
      This documents extends OSPF graceful restart as documented
      in RFC 3623 to OSPFv3. An OSPFv3 LSA type is used for signaling
      and there are additional concerns with respect to avoiding churn
      when determining whether pre-restart LSAs need to be reoriginated.

    * Working Group Summary
      There was no opposition to this document. There was one proposal
      to modify the existing OSPF graceful restart mechanism but it was
      not adopted by the working group and the requirement is unclear.

    * Protocol Quality
      The OSPFv3 graceful restart exhibits the quality as the
      base OSPF Graceful Restart specification (RFC 3623). Both planned
      and unplanned restart are supported. Depending on configuration,
      OSPF LSAs changes may result in helping routers aborting graceful
      restart or allowing the restarting router to proceed.

IETF-Announce mailing list