IETF 95: Open Shortest Path First (OSPF) WG Agenda Thursday, April 7th, 2016. 14:00 - 16:00 - Afternoon Session I Location: Quebracho A ======================================================== Chairs: Acee Lindem Abhay Roy Scribe: Les Ginsberg (ginsberg@cisco.com) WG Status Web Page: http://tools.ietf.org/wg/ospf/ 1) Administrivia - 5 minutes - Blue sheets - Scribe/jabber - Jabber room: ospf@jabber.ietf.org ************************************************************ 2) WG Status Update - 10 minutes - Acee Lindem draft-ietf-ospf-flowspec-extensions-00 Acee: Flowspec draft not accepted in IS-IS - but with OSPF as PE-CE protocol still reasons to go ahead with this for OSPF. draft-ietf-ospf-ospfv2-hbit-00 Acee: Quagga interprets max-link metric as blocking traffic - may impact H-bit support. Chris Bowers: Does it indicate that clarification is needed to prevent incorrect implementations? David: Leftover from RFC 1583 Acee: Not correct. draft-raza-ospf-stub-neighbor-02 Padma Pillay-Esnault: Draft will be updated by next IETF. draft-chunduri-ospf-operator-defined-tlvs-02 Uma Chunduri: No time to respond to comments on Operator-defined TLV draft. Will do so soon. Removed some use cases. Acee: IDR rejected same idea in the past but is being proposed again. Uma: Needed in OSPF as well - BGP will not always be availble. Padma: Many small drafts for TLVs. Had service distribution draft. Service distribution draft could serve in this way. Revive it. Les Ginsberg: IS-IS defined GENAPP for this. Acee: Two components to address: 1)Separation into two instances (routing and application) 2)how to support the actual encoding ************************************************************ 3) OSPF Segment Routing Update - 10 Minutes - https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ - https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ - Acee Lindem for Peter Psenak Uma: No discussion about IPv6 dataplane - is there something to be added? Acee: Additional draft for IPv6. Send comments to the list. Uma: Some confusion about bits - OSPF is clearer than IS-IS (P flag vs NP flag). Acee: Are IGP drafts missing IPv6 dataplane content? Les: No. Covered in dataplane specific drafts for MPLS and IPv6. IGP drafts only indicate support for the IPv6 dataplane ************************************************************ 4) OSPF YANG Model Update - 10 Minutes - https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ - Acee Lindem for Derek Yeung Jeff Tantsura: router-id is a simple number? Acee: Agreed to use dotted-quad. Alia Atlas: Router-id should be dotted quad. ************************************************************ 5) Signaling MSD (Maximum SID Depth) using OSPF - 10 Minutes - https://datatracker.ietf.org/doc/draft-tantsura-ospf-segment-routing-msd/ - Jeff Tantsura Acee: Use Link MSD if you advertise ADJ-SID. Les: Up to controller to use correctly - can advertise regardless. Acee: Agreed Bruno Decrane: Specific to MPLS dataplane? Jeff: Yes Bruno: Do we need same for IPv6 labels? Jeff: Not as straightforward for IPv6. Naiming Shen: Is this a security issue? Revealing your label imposition capability may provide an attack vector. Alex (???): 32 bits - do we need that many? Padma: If to be used by PCE do we want generic TLV? Is router-info LSA the right place Jeff: Related to SR - so router-info is the right place Acee: Using router-info as a generic container decided in the past by the WG Padma: Agree - one place is nice - but may not be the best approach. Les: In IS-IS use Router Capabilities for things the protocol uses, GENAPP for info not used by the protocol. ************************************************************ 6) OSPF Corrupted MaxAge LSA Flushing Problem Statement - 10 Minutes - https://datatracker.ietf.org/doc/draft-dong-ospf-maxage-flush-problem-statement/ - Jie Dong Juliusz Chroboczek: How much corruption is seen in the field? Jie: Could be hardware issue - may not occur often Padma: Flooding reduction drafts assumed that corruption is rarely seen Yega (???): May not happen often - but how to reduce impact of the issue? Juliusz: Not complaining - agree w robustness Chris: How bad does system timer have to be to cause a problem? Jie: 2 times? Padma: How often isn't relevant. Robustness is important. Shraddha Hegde: Locating originator of a purge is important. Les: Problems in IS-IS were different because authentication is not calculated hop-by-hop. Acee/Jie: Agree the problem is different - addressing the fast timer may be the most significant issue. Padma: How does injecting POI help? ************************************************************ 7) OSPF Geo Location - 10 Minutes - https://datatracker.ietf.org/doc/draft-acee-ospf-geo-location/ - Naiming Shen Juliusz: Router going to derive IGP metric from geographical distance? Naiming: Yes Juliusz: Trying to minimize geographical distance a packet traveled. But this may or may not be a valid assumption in your network. Naiming: Agree. But today even if you don't do dynamic metrics underlying transport may change. Agree warning as to whether this use case is appropriate for your network is needed in the draft. Acee: This is non-normative. Provide example algorithm similar to link bandwidth. Acee: Thought it important NOT to use floating point - would like to get feedback on this choice. Naiming: Other formats exists - but following LISP model seemed best Juliusz: Other more complex formats make testing more difficult. Padma: Be good to have a version # for the algorithm Acee: Put example of an algorithm. Metric derived from bandwidth algorithm has been standardized. Naiming: Controller could be used to calculate metrics Don't need to keep advertising. Acee: Not ready for WG adoption yet - authors want at least one more revision. ************************************************************ 8) OSPF TE Attributes for non-TE Applications Alternatives Update - 10 Minutes - https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/ - Acee Lindem Bruno: Is this RSVP-TE info? May need to be clarified - not confused with SR-TE. Chris: Feels discussion on the list is not resolved. SPs are saying this will cause problems in their networks. Need clearer e explanation of what is and isn't TE. Uma: Some TE parameters can be used for RSVP-TE and for LFA - will parameters need to be repeated? Acee: Often do not have RSVP-TE and other non-TE applications enabled at the same time. Uma: A deployment with 17 SRLGs (for example) was requested. Need to show how this will be supported. Jeff: We wish to decouple the two use cases. Chris: Need clearer examples of how this is supposed to work. If they are currently using RSVP-TE LSAs for LFA - how will this help? Acee: More discussion on the list. Does RFC 3630 require enablement of TE? Chris: We could call TE LSAs another name. Will this help implementations?