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 Group. The IESG contact persons are David Ward and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-23.txt 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 parameters. 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. Personnel 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? Yes 2. Has the document had adequate review from both key WG members and key non-WG members? Yes 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.)? No 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. No 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, 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. No 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? (note 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 Standard, Informational?) Proposed Standard 10. For Standards Track and BCP documents, the IESG approval announcement 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
