Last Modified: 2003-08-26
| Done | Gather operational experience with the OSPF protocol and submit the document as an Informational RFC. | |
| Done | Develop multiple implementations, and test against each other. | |
| Done | Design the routing protocol, and write its specification. | |
| Done | Obtain performance data for the protocol. | |
| Done | Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. | |
| Done | Submit OSPF for IPv6 to IESG for consideration as a Standard. | |
| Done | Update the OSPF NSSA option specified in RFC 1587 and submit to IESG for consideration as a Proposed Standard | |
| Done | Develop Traffic Engineering extensions for OSPFv2 and submit it to the IESG as a Proposed Standard | |
| Done | Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited. | |
| Done | Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time | |
| Done | Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard. | |
| Done | Document Alternative ABR implementations and submit ti IESG as an Informational RFC | |
| Nov 03 | Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. | |
| Nov 03 | Extend the hitless restart mechanism to OSPFv3 and submit it to the IESG as a Proposed Standard | |
| Nov 03 | Develop Traffic Engineering extensions for OSPFv3 and submit it to the IESG as a Proposed Standard. | |
| Nov 03 | Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic. | |
| Nov 03 | Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850 | |
| Nov 03 | Specify IPSEC usage with OSPFv3 and submit to IESG for consideration as a Proposed Standard |
Open Shortest Path First IGP WG (ospf) Tuesday, July 15 at 1700-1800 ============================== REPORTED BY: Dimitri Papadimitriou <Dimitri.Papadimitriou@ALCATEL.BE> CHAIRS: Rohit Dube <rohit@utstar.com> Acee Lindem <acee@redback.com> AGENDA: 1. Agenda Bashing 5 Mins Chairs 2. Administativia and Document Status 10 Mins Chairs 3. IGP Capabilities 10 Mins Rahul Aggarwal <http://www.ietf.org/internet-draf ts/draft-lindem-ospf-cap-01.txt> 4. Traffic Engineering Capability TLV for OSPF 10 Mins Jean Philippe Vasseur ---------------------------------------- --------------------------------------- 1. Agenda Bashing (5 Mins) - No change in the proposed agenda ---------------------------------------- --------------------------------------- 2.1 Administrativia: o Implementation Report for Hitless restart - request issued June 13, 2003 - please respond to Acee (acee@redback.com) o Additional OSPF Page at <http://rtg.ietf.org/ospf> - with thanks to Bill Fenner! o Routing Area Meeting: - Hall NO - Thursday 1530-1730 2.2 OSPF Document Status o Documents Progressing: - Traffic Engineering Extensions to OSPF Version 2 <draft-katz-yeung-ospf-traffic-10.txt> . IANA section updated . Second IETF Last Call completed . Under IESG evaluation - OSPF Hitless Restart <draft-ietf-ospf-hitless-restart-07.txt> . Comments from WG Last Call incorporated . Under IESG Evaluation . New version forthcoming incorporating initial IESG comments - Detecting Inactive Neighbors over Demand Circuits <draft-ietf-ospf-dc-06.txt> . New version incorporating IESG comments required - Prioritized Treatment of Specific OSPF Packets and Congestion Avoidance <draft-ietf-ospf-scalability-05.txt> . WG Last call completed . Under AD review - OSPF Refresh and Flooding Reduction in Stable Topologies <draft-pillay-esnault-ospf-flooding-07.txt> . WG Last Call and AD review completed . Will be published as informational RFC - Traffic Engineering Extension to OSPF version 3 <draft-ietf-ospf-ospfv3-traffic-00.txt> . Refreshed as WG document . Please review and discuss o Document at Same Status: - OSPF Version 2 Management Information Base <draft-ietf-ospf-mib-update-06.txt> . One more update needed prior to WG last call - OSPF Version 3 Management Information Base <draft-ietf-ospf-ospfv3-mib-06.txt> . Vishwas Manral added as author . Recently refreshed . Please review and discuss on list - Authentication/Confidentiality for OSPFv3 <draft-ietf-ospf-ospfv3-auth-01.txt> . Refreshed with comments . Please review and discuss Discussions: ----------- - Bill Fenner: Did you receive our comments ? - Rohit Dube: Yes, we've received them from Alex Zinin - Bill Fenner: I will send my comments to the mailing list o New Documents: - Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs <draft-ietf-ospf-2547-dnbit-00.txt> . Accepted as WG document . Please review and discuss - Extensions to OSPF for Advertising Optional Router Capabilities <draft-lindem-ospf-cap-01.txt> . Will be refreshed as WG document o Document Tracker: - http://rtg.ietf.org/ospf/ - Click on "Status of OSPF WG Drafts" - Click on "AD watching and Beyond" ---------------------------------------- --------------------------------------- 3. IGP Capabilities (10 Mins) - Rahul Aggarwal <http://www.iet f.org/internet-drafts/draft-lindem-ospf-cap-01.txt> Summary: ------- o This draft proposes extensions to OSPF for advertising optional router capabilities by proposing a method that overcomes the lack of bits remaining unassigned in the options field of the hello packet. Router Information (RI) opaque LSA is here proposed to advertise new optional router capabilities or MPLS TE capabilities. The existing applications are PCS, Mesh Groups, and iBGP auto-mesh. Discussions: ----------- - Rahul Aggarwal (addressing the working group): any questions ? - Rohit Dube: the draft has a couple of TLV's assigned for drafts not yet officially adopted by an paticular working group - Rahul Aggarwal: the documents are the Path Compuation Server (PCS) and auto-mesh i-d's. Should they be added when they become WG documents? - Rohit Dube: yes (this is the procedure to follow) ---------------------------------------- --------------------------------------- 4. IGP Traffic Engineering TLV for OSPF (10 Mins) - Jean-Philippe Vasseur Topic: ----- o Definition of the Mesh-Group TLV and the PCSD TLV as OSPF Traffic Engineering capability TLVs to be included in the OSPF Router Information LSA (with Opaque Type of 4, Opaque ID of 0 and Type 10/11 LSA depending on the application) - Scope of the current discussion is first to introduce the applications Summary: ------- o Mesh-Group TLV: . Used by an LSR to indicate its desire to participate to a mesh of TE LSPs (identified by a mesh-group number) . Useful to automate the creation of full meshes of TE LSPs with coloring . Discussion on the structure of the proposed TLV o PCS Discovery (PCSD) TLV: - Allows an LSR to announce its PCS capability to other LSRs within an OSPF area or a routing domain (and thus deliver PCS discovery capability) - PCSD TLV includes several sub-TLVs: . PCS scope . PCS address . PCS capability . AS-domain - Applicability: . situation in inter-area traffic-engineering - reference to the multi-area draft of Kireeti Kompella (scenarios 2, 4 and 5). situation in inter-AS traffic-engineering Discussions: ----------- - Jean-Philippe Vasseur: scope here is to discuss the applications - Rohit Dube: for now this draft is presented to the OSPF WG for information only - where this particular work can progress has to be discussed on the list. - Rohit Dube: other questions or comments on this topic ? => no reaction from the room Rohit Dube: questions or comments on any other topic ? => no reaction from the room Rohit Dube: meeting is adjourned ======================================== ==================== |