IETF-54/OSPF WG minutes

[Alex Zinin <[e-mail]>]

Folks,

 Below is what I took at the meeting. Thanks to Eric Gray
 for his help and sorry if I missed anything. Those who
 were there, pls review and provide corrections if you
 find a mistake.

--
Alex


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 reply
   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.