[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-ospf
Subject:    OSPF WG meeting minutes
From:       "Moy, John" <John.Moy () SYCAMORENET ! COM>
Date:       1999-12-10 17:06:58
[Download RAW message or body]


The OSPF Working Group met at the
46th IETF on Monday, 11/8, from 1300-1500.
The following are minutes of the meeting, as recorded
by John Moy.

1. Working Group report, document status
   John Moy
   Aside from the documents presented during the meeting,
   the Working Group documents that are currently under
   revision include the following. The OSPF for IPv6
   specification is in the RFC editor's queue, ready to be
   published as a Proposed Standard. The updated MOSPF
   spec is due to be submitted for republication at Draft
   Standard, as soon as current deployment/interoperability
   status is documented. The NSSA spec is still being reworked
   (draft-ietf-ospf-nssa-update-08.txt), with the intent to
   republish it in-grade, replacing RFC 1587. The OSPFv2 MIB
   needs updating and advancement to Standard, to match the
   OSPFv2 spec. The Traffic Engineering Extensions to OSPF
   <draft-katz-yeung-ospf-traffic-01.txt> has two small issues
   to work out: how to keep the link metric encodings in sync
   with the IS-IS Traffic Engineering extensions, and how to
   assign new link metrics (such as an IfIndex metric for unnumbered
   links). Curtis Villamizar has changed jobs, so the URLs for
   OSPF Optimized Multipath (OSPF-OMP) no longer work, but Curtis
   intends to reorganize draft-ietf-ospf-omp-02 and
   publish it as an Experimental protocol.

2. Alternative OSPF ABR Implementations
   <draft-ietf-ospf-abr-alt-01.txt>
   Alex Zinin, Peter Psenak
   This document describes the inter-area routing implementations
   of two vendors, cisco and IBM, which differ from standard
   OSPF inter-area routing. Both try to solve the problem in
   standard OSPF where area border routers not attached
   to Area 0.0.0.0 cannot forward packets to remote areas.
   The two vendors' solutions are different. There was a comment
   on the cisco implementation, which prevents some legal virtual
   link configurations from working (those where there is no
   physical Area 0.0.0.0). There was some question whether such
   configurations actually occur in practice. A request was made to
   remove words like "recommended" from the document, since
   it is simply documenting two current vendor implementations.

3. OSPF Shortcut ABR, Enhanced OSPF ABR Behavior (15 minutes)
   <draft-ietf-ospf-shortcut-abr-01.txt>
   Alex Zinin
   These proposed extensions solve the problem with ABRs not
   attached to Area 0.0.0.0, and also optimize inter-area routing
   without the need for virtual links. Alex described them as an
   extension to the cisco and IBM behaviors presented earlier.
   Description of counting behavior that can occur when
   falling back to longer route has been added to document; this
   behavior can also occur in standard OSPF. There was a question
   of how CPU-intensive the short-cut behavior was. There was some
   confusion over what was required behavior in the OSPFv2 spec,
   caused by its lack of "musts" etc., particularly in the area
   of installing discard routes. Shortcut ABR has been implemented
   in the zebra routing daemon, which can be configured to do
   inter-area routing as a) standard, b) cisco, c) ibm or d) shortcut.

4. Techniques in OSPF-based Network (10 minutes)
   <draft-ietf-ospf-deploy-00.txt>
   Howard Berkowitz
   This document tries to fill in gaps between the OSPF specifications
   and real deployments. For example, the OSPF spec uses
   the term Autonomous System in a way that is counter to current
   practice. Howard solicits input for other information that
   would be useful to people deploying OSPF.

5. Management Information Base for OSPFv3 (10 minutes)
   <draft-ietf-ospf-ospfv3-mib-01.txt>
   Dan Joyal
   This MIB is required since the companion protocol spec,
   OSPF for IPv6, is entering the standards track. Indexes in the
   lsdb table have been reordered since Link State IDs in OSPF
   for IPv6 no longer have any semantic meaning; all LSAs originated
   by a given router will now be dumped consecutively.
   Q: How to configure the interface addresses advertised by OSPF.
   A: Through some other MIB.

6. Redundant LSA reduction in OSPF (10 minutes)
   <draft-kini-dube-ospf-redundant-lsa-reduction-00.txt>
   Rohit Dube
   This proposal attempts to reduce flooding in those
   situations where neighbors are highly interconnected, by
   omitting some neighbors from the flooding on a per-LSA basis. It is
   derived from the IS-IS Mesh Group proposal. Comments included
   the following: a) the resulting flooding is not reliable unless
   you use a Designed Router, in which case you just end up with
   NBMA flooding from the base OSPF spec b) you could use "mesh
   flooding" for only certain LSA types and c) maybe the LSA database
   could give you some indication as to which neighbors could
   be safely skipped in the flooding procedure. There was some concern that
   the last comment could give rise to a circular dependency between
   the database contents and its distribution via flooding, which
   could prevent database updating in certain situations.

7. OSPF Refresh and flooding reduction in stable topologies
   <draft-pillay-esnault-ospf-flooding-00.txt>
   P. Pillay-Esnault
   (Document published after the meeting). This document proposes
   to reduce flooding through the use of MaxAge LSAs, which
   were defined originally in RFC 1793 (Demand Circuit extensions
   for OSPF). Comments included a) since the original router
   can now refresh whenever it chooses, you can now make the
   LSA refresh rate configurable on a per-router, per-LSA type
   basis and b) if you set the DoNotAge bit in the originating
   router's database, you don't mess up the database checksum.

8. Vulnerability analysis and intrusion detection for OSPF (25 minutes)
   S. Felix Wu
   This is DARPA-funded work, to try to produce an Intrusion Detection
   system for OSPF. It detects and in some cases thwarts attacks
   on an OSPF routing domain. The objective of an attacker is to
   change routing so that data packets go through a compromised
   router. The authors have concentrated on attacks to OSPF's database
   distribution, and have identified and named a number of possible
   attacks, some taking advantage of implementation software bugs
   (e.g., the MaxSeqno attack) and other attacking the OSPF
   protocol design itself (the MaxAge difference attack). Intrusion
   detection is performed via a finite-state machine, or through
   a statistical module; code for both will be made available. They
   are also trying to detect intrusion by monitoring OSPF MIB
   variables. Future work includes a) a simulation testbed to generate
   data to compare with operation networks b) how to test intrusion
   responses so that they themselves won't harm the network. Felix
   will post papers describing the intrusion detection system onto
   the ospf mailing list.

9. Multi-level OSPF (MLOSPF) (15 minutes)
   Alex Zinin
   Alex presented unpublished work on the requirements and beginnings
   of an architecture for a multi-level (more than 2) hierarchy for
   OSPF. It would be backward-compatible with current OSPF. Areas
   can be grouped together into higher level areas. Inter-area
   routing would be link-state based instead of Distance Vector.
   Policy and aggregation would be possible at every area border, similar
   to the BGP model. More integration with BGP is proposed. This
   work is just beginning, and Alex solicits participation in
   MLOSPF protocol development. The mailing list for MLOSPF
   is mlospf@agtel.net, and its web page is
   http://babylon.agtel.net/~zinin/IETF/mlospf/mlospf.html.


John
 <<John Moy (E-mail).vcf>>

["John Moy (E-mail).vcf" (application/octet-stream)]

[prev in list] [next in list] [prev in thread] [next in thread]