Current Meeting Report
Slides


2.5.5 Open Shortest Path First IGP (ospf)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 06/24/2002

Chair(s):
John Moy <john.moy@sycamorenet.com>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Bill Fenner <fenner@research.att.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 develops and documents extensions and bug fixes to the OSPF protocol, as well as documenting OSPF usage scenarios. The specific protocol work items area listed in the Goals and Milestones section below. Additional work items will require rechartering.
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  Submit Internet-Draft on ISPF extensions of IPv6 to IESG for consideration as a Proposed Standard.
DEC 96  Develop OSPF for IPv6 MIB and submit 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  Design the routing protocol, and write its specification.
Done  Develop multiple implementations, and test against each other.
Done  Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC.
Done  Obtain performance data for the protocol.
JUN 98  Submit OSPF for IPv6 to IESG for consideration as a Standard.
SEP 01  Submit to IESG a document which updates RFC 1793 allowing detection of demand circuit neighbors whose OSPF process has exited.
SEP 01  Submit to IESG a BCP advocating that OSPF LSA refreshes be spread out over time
SEP 01  Submit to IESG a BCP advocating that OSPF Hellos be given preference over other OSPF control traffic.
OCT 01  Update OSPFv2 MIB and submit to IESG as a Standard, replacing RFC 1850
OCT 01  Update MOSPF specification with bug fixes and changes required by RFC 2328. Submit to IESG as Draft Standard
JAN 02  Develop pruning support for MOSPF, allowing it to be used in a transit multicast domain and with IGMPv3. Submit to IESG as Proposed Standard
JAN 02  Develop a hitless restart mechanism for OSPF and submit it to the IESG as a Proposed Standard.
JAN 02  Develop mechanisms to reduce OSPF flooding traffic in highly connected network topologies. Submit to IESG as Proposed Standard.
Internet-Drafts:
  • - draft-ietf-ospf-nssa-update-11.txt
  • - draft-ietf-ospf-mlinks-03.txt
  • - draft-katz-yeung-ospf-traffic-06.txt
  • - draft-ietf-ospf-abr-alt-04.txt
  • - draft-ietf-ospf-ospfv3-mib-05.txt
  • - draft-pillay-esnault-ospf-flooding-03.txt
  • - draft-ietf-ospf-mib-update-05.txt
  • - draft-ietf-ospf-hitless-restart-02.txt
  • - draft-ietf-ospf-scalability-01.txt
  • - draft-ietf-ospf-5to7-01.txt
    • Request For Comments:
    RFCStatusTitle
    RFC1131 PS OSPF specification
    RFC1245 I OSPF Protocol Analysis
    RFC1248 PS OSPF Version 2 Management Information Base
    RFC1247 DS OSPF Version 2
    RFC1246 I Experience with the OSPF Protocol
    RFC1252 PS OSPF Version 2 Management Information Base
    RFC1253 PS OSPF Version 2 Management Information Base
    RFC1583 DS OSPF Version 2
    RFC1586 I 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
    RFC2178 DS OSPF Version 2
    RFC2329 I OSPF Standardization Report
    RFC2328StandardOSPF Version 2
    RFC2370 PS The OSPF Opaque LSA Option
    RFC2740 PS OSPF for IPv6
    RFC2844 E OSPF over ATM and Proxy PAR
    RFC3137 I OSPF Stub Router Advertisement

    Current Meeting Report

     IETF54: OSPF WG Minutes

    Bill Fenner chaired the meeting, since John was on vacation.

    1. Administrivia from Bill

    The ADs are looking for a co-chair. If you would like to be considered or
    suggest someone, please talk to Bill and Alex.

    Agenda bashing

    Status update:

    MIBs: MIB doctor review

    Pending for new version after AD comments:

    alt-abr
    padma's flooding reduction
    katz-yeung

    NSSA: almost out

    Active WG documents:

    Multi-area links
    HItless restart
    Hello priority
    5-to-7 trans

    Bunch of ospf ids not mapping to the charter
    (Bill showed the list of all drafts with ospf in them)

    Goals & Milestones:

    Bill: The dc-neighbor: status?
    Alex: expired, but should be ready for the LC
    Bill: should probably do the LC then

    Bill: refresh guidelines?
    Alex: need to solve the problem with publishing the model and increase the
    refresh jitter per comments from the WG, should be ready for the LC then.

    MOSPF update? no work
    MOSPF prunning? no work

    Flooding reduction item? maps to padma's doc

    Bill: what do people think about the goals and milestones?

    Dimitry: LLS in charter?

    Bill: no

    Dimitry: any interest in the WG?

    Bill: need interest and the IESG approval of the milestone

    Dimitry: isn't it a WG item as I see in the list?

    Bill: the chairs allowed the documents to be WG docs without the charter update.
    We're trying to make sure all work items are in the charter.

    Rahul: GMPLS ext: part of the CCAMP WG, should we revisit this issue and bring
    them here?

    Kireeti: I had a discussion with John, he was happy to put it in CCAMP.

    Bill: does CCAMP want to do it?

    K: it is probably easier, it's GMPLS details, an opaque LSA.

    ISIS took a different approach: it's an extension to the base proto, so we don't
    want to be out of the WG

    Need to rediscuss with Tonys.

    B: CCAMP could create a document for the pieces of info and have a
    protocol-specific details in protocol WGs

    K: we have it. the ownership of ISIS is in ISIS WG. In isis we have to be
    careful too. There are reasons. We need to revisit with the ISIS chairs. Maybe
    also OSPF

    Dave Ward:
    On behalf on the Tonys, they want to control the changes to the protocol, but
    are happy with GMPLS going back to CCAMP

    K: As virtual John: do you have a preference? [:)]

    B: makes sense for the protocol pieces to be in the protocol-specific WG to make
    sure proto-specific issues are dealt with.

    A: this is the default

    K: ccamp does work on the protocols

    A: I meant to say if we're using an existing protoc

    K: not necessarily the case, examples: CR-LDP, RSVP-TE.

    A: should probably discuss this more

    Mina: we should look where the expertise is and the workload of the WG is


    2. Rahul presented ospf optional router capabilities. current use is for
    troubleshooting and management, maybe used for protocol extension in future:

    [draft-raggarwa-igp-cap-00.txt]

    Abhay: have you looked at the LLS?

    R: no

    A: it solves most of what you're talking about

    R: haven't looked at the draft, but the intention is to provide a mechanism for
    ann. of capabilities. we're trying to consolidate capabilities announcement for
    IGPs,

    A: LLS will allow you to have options in Hello packets, useful if you want to do
    negotiation before the adj comes up while the opaque lsa maybe too late:

    R: will look

    A: why do you need bits for restart?

    R: for management. one of the operators said there's a way in other protocols
    (bgp) to announce capability... right now, no help for the protocol, info,

    Naming: coming from the anchor of the hitless restart, some vendors support
    either one of them or both of them

    Amir: not to comment on any related necessity, specific: it might be better to
    exclude the actual bit listing from the specified draft, so you don't have to
    update the doc everytime a new capability is introduced. you mention it is
    optional, you should take in account that if this goes through, it will have to
    be implemented, people will use it.

    R: 1st point those are existing capabilities, let's identify them 2nd: optional
    mechanism, TE is optional, implement or not--different issue.

    A: we either don't need it or the graceful restart will use it

    N: 1st point: took the approach from ISIS, list the current standard drafts
    published that so far have been using the code point, it does not prevent.... if
    in future any draft wants to announce a capability, we'll have another draft

    2. ??????

    K: you should have a bit that says: I'm capable of doing capabilities [:)]

    K: does this belong here or in MIB?

    R: MIB does not solve what we're trying to solve

    K: why not use the MIB, since it is informational

    Bill: I had the same concern, so why do we need it in the IGP

    R: some operators asked us to introduce this info, but point is well-taken.

    Alex: Sounds like we should either have a useful application for this mechanism
    or have the operators speak up on the list explaining why this is a do-or-die
    for them. Otherwise, we're just increasing the entropy.

    R: yep, makes sense.

    Jeff: easy to foresee events under which some peer would take action, if you do
    envision that, you need to specify those actions

    also, how many bits you have:

    R: extensible

    J: good, bgp takes approach of list of values

    Andrew L: peer?

    J: adjacencies, the neighbor could use it to take different actions

    Andrew: you could manually configure

    Naming: on Kireeti's: MIB is for the NMS, needs explicit request. if you're
    troubleshooting the hitless restart, ours helps to see who supports hitless
    restart.

    SNMP support is behind feature-wise

    if the protocol wants to use for internal use, it's not the MIB issue

    Kireeti: if purely informational: MIB, no protocol

    Dimitry: do you debug the capability or the fact that it is announced?

    R: didn't understand

    K: you have to bits support restart and restart enabled

    R: the draft does not specify... if you haven't received any LSA identifying a
    capability you don't know what happens, if you HAVE but the bit is off, it gives
    the clue that it doesn't support


    Bill: we need more discussion on the list

    R: we'll take it to the list, will ask the SPs to speak up


    3. Mukesh presented his draft on ospfv3 and ipsec, discussing how ipsec should
    be used to secure ospv3 communication.

    [draft-gupta-ospf-ospfv3-auth-00.txt]

    Bill: the document says AH or ESP, we get inconsistent advise, just use
    one--AH/ESP. I'm told that there are existing implementations with AH only,
    switching to ESP only would mean interoperability problems.

    M: I have options AH or ESP

    B: if we implement different, we won't interoperate

    there are places: getting interoperability: what algos are necessary: hash,
    cyphers, the doc doesn't pick a cipher, we could have interop problems

    M: should I add algos?

    B: yeah, if you implement one and I implement another, we wont work together

    M: I implemented, have options for both

    B: say i have a router that has no ipsec implement, i want to implemenyt ipsec
    sec, what the min to implement to be compat with others. have to have common min


    M: ok

    Alex: to give a bit of perspective--I encouraged Mukesh to look at the problem
    after the discussion on the list went in a wrong direction, this is the first
    shot, expecting constructive comments from the WG.

    Yasu: did you look at both unicast & multicast packets?

    M: covered both unicast and multiast

    Y: another question: do you think OSPF can prevent the replay attacks? if
    there's a replay packet, it will break the adjacencies

    Alex: We use ipsec for ospfv3. ike is p2p only, hence we need to use static
    shared keys, which means no sequence number, and effectively no replay
    protection. ospfv2 solves this by using its own crypto sequence numbers, but not
    completely, isis went a different direction--no sequence numbers there.

    M: we also have a problem with maintaining the seq nums in SAs when operating in
    a multicast group.

    ????: could we use sequence numbers in ospf packets?

    Alex: we don't really have them in packets. LSAs do have seq nums, but the
    problem is when an LSA is gone, the seq num is gone and you can replay. No seq
    num in ospf packets, ospfv2 has its own crypto ones, the problem with them is
    when a nbr is gone, its seq num is gone and you can replay again.

    Bill: there's some work on mcast key exchange protocol, when they mature, it
    might be useful for it.

    M: it is all happening at the IPSec, if IPsec has a problem, we have it in OSPF

    B: got some comment from Ran Atkinson, will work with you.


    4. JP presented the draft on PCSD-discovery draft

    [draft-vasseur-mpls-ospf-pcsd-discovery-00.txt]

    Bill: needs reviews like other uses of OSPF opaque LSAs.

    Kireeti: issues need to be broken down into what they affect. One consideration
    in deciding where to do the work is how many times are you going to have to see
    the draft presented.

    Kireeti also talked about breaking the task into functional and protocol
    specifications. This makes it easier to decide where to do the work.

    Francois: talked about precedents that had followed a similar model.

    Bill: the idea is that the WG needs to review the work at some point.


    Alex: please provide comments on the OSPFv3 FA issue, getting feedback that the
    discussion was not sufficient to resolve it.

    Slides

    None received.