NOTE: This charter is a snapshot of the 42nd IETF Meeting in Chicago, Illinois. It may now be out-of-date. Last Modified: 30-Jul-98
Chair(s):
John Moy <jmoy@casc.com>
Routing Area Director(s):
Rob Coltun <rcoltun@fore.com>
Routing Area Advisor:
Rob Coltun <rcoltun@fore.com>
Mailing Lists:
General Discussion:ospf@discuss.microsoft.com
To Subscribe: ospf-request@discuss.microsoft.com
Archive: http://discuss.microsoft.com/archives/ospf.html
Description of Working Group:
The OSPF Working Group will develop and field-test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations.
Goals and Milestones:
Jun 96 |
|
Complete OSPF for IPv6 specification and submit to IESG for consideration as a Proposed Standard. |
Jun 96 |
|
Document current usage, update OSPFv2 and submit to IESG for consideration as a Standard. |
Dec 96 |
|
Develop OSPF for IPv6 MIB and submit to IESG for consideration as a Proposed Standard. |
Dec 96 |
|
Submit Internet-Draft on ISPF extensions of IPv6 to IESG for consideration as a Proposed Standard. |
Jun 97 |
|
Update OSPF for IPv6 based on implementation experience, and submit to IESG for consideration as a Draft Standard. |
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 |
|
Obtain performance data for the protocol. |
Done |
|
Design the routing protocol, and write its specification. |
Done |
|
Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. |
Jun 98 |
|
Submit OSPF for IPv6 to IESG for consideration as a Standard. |
Internet-Drafts:
· The OSPF Address Resolution Advertisement Option
· OSPFv2 Domain Of Interpretation (DOI) for ISAKMP
Request For Comments:
RFC |
Status |
Title |
RFC1246 |
Experience with the OSPF Protocol | |
RFC1245 |
OSPF Protocol Analysis | |
RFC1586 |
Guidelines for Running OSPF Over Frame Relay Networks | |
RFC1587 |
PS |
The OSPF NSSA Option |
RFC1765 |
E |
OSPF Database Overflow |
RFC1793 |
PS |
Extending OSPF to Support Demand Circuits |
RFC1850 |
DS |
OSPF Version 2 Management Information Base |
RFC2096 |
PS |
IP Forwarding Table MIB |
RFC2328 |
S |
OSPF Version 2 |
RFC2329 |
OSPF Standardization Report | |
RFC2370 |
PS |
The OSPF Opaque LSA Option |
42nd IETF OSPF WG Meeting Notes
Rob Coltun opened the meeting with an introduction and summary of new RFC and
draft revisions since the LA IETF. These include:
1. RFC 2370 - Opaque LSA Option
2. John Moy's revised MOSPF Draft
3. New Version of NSSA Draft (Updates RFC 1587)
Rob then went through the differences between the new MOSPF draft and RFC 1584.
These differences can be classified as one of 4 types:
1. Bug fixes to the current specification.
2. Changes for consistency with RFC 2328.
3. Changes in support of IGMPv2.
4. Clarifications in response to questions on RFC 1584.
Rob expects there to be at least one more revision of the draft but those wishing to
review the draft should not delay. The draft is draft-ietf-mospf-mospf-00.txt.
Cyndi Jung from 3Com presented the results of the MOSPF Inter-Op IPMI testing
performed in June. Interoperability of 4 MOSPF implementations was tested. These
included Bay, Ascend/Cascade, 3Com and IBM. Mixed MOSPF and DVMRP dmains
tested successfully. Inter-area test with a DVMRP domain and non-MOSPF OSPF area
caused confusion due to the fact that the RPF preferred the non-multicast inter-area
route to the multicast capable external route (via the DVMRP domain). However, this
is consisent with the specification.
Next Rob indicated that an Internet Draft was in the works based on Daniel Awduche's
requirements for MPLS traffic engineering. Expect this to be discussed at the next IETF.
Finally, Pat Murphy from the US Geological Survey/Department of Interior presented
the 2 drafts he has been working on. The first was the latest OSPF NSSA option revision
(draft-ietf-ospf-nssa-update-05.txt). The main differences between the new draft and
RFC 1587 include:
1. Type 3 Summary LSAs can be inhibited from being advertised into NSSA's. Rather,
a single default (0/0) type 3 LSA is advertised by the ABR(s).
2. There is configuration control over which ABR(s) translate 7 type NSSA LSA's to
type 5 LSA. An ABR can be configured to always translate type 7 LSA's, never
translate type 7 LSA's or participate in the election process.
Pat presented problems with installing routes corresponding to NSSA type 7 LSAs with
their P-bit clear. The concensus was to leave the base NSSA draft as it is and document
the problems in an appendix. Pat favors policy based filtering so that packets originating
within an NSSA could still use routes corresponding these P-bit clear type 7 LSAs.
While this is the most flexible, there was general agreement that this should not be a
requirement for OSPF NSSA implementation.
Pat also drew a picture of his overall OSPF area architecture and discussed the size and
complexity of the multi-agency OSPF network for which he is responsible.
Pat will issue a new draft in the near term and Rob/John will request last call.
Last, Pat presented his proposal for multiple area links. This is to satisfy the requirement
to use an inter-area path including a high speed backbone link rather than the intra-area
path. The proposal introduces the concept of secondary adjacencies in the non-backbone
areas and utilizes Opaque LSAs to augment the intra-area area route computation
process. Pedro Marques (Cisco), Tony Przygienda (Lucent), and Acee Lindem (IBM)
all indicated that there should be a simpler solution to this problem. Pedro suggested
using an IP tunnel across the backbone for each non-backbone area. Acee suggested
simply allowing the backbone area interface to be configured in multiple areas. It would
be represented as an unnumbered link in non-backbone areas. Acee will post an E-mail
to the OSPF list elaborating on this proposal. Others are encouraged to submit their
ideas for solving this problem.
None received.