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.