IETF 97: Open Shortest Path First (OSPF) WG Agenda Wednesday, November 16th, 2016 (KST) 9:30 - 11:00 - Morning Session I Location: Park Ballroom 1 ======================================================== Chairs: Acee Lindem Abhay Roy 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 - Abhay Roy See slides - Highlights: - TTZ draft waiting for AD comments - Entropy draft will be revised based on discussion on the list. - SR YANG split out to separate document - Awaiting implementations for OSPFv3 Extenmded LSAs - MSD draft has become WG document 3) OSPF Segment Routing Update - 10 Minutes (See slides) - https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions/ - https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-segment-routing-extensions/ - Acee for Peter Psenak Pre-presentation discussion: Chris Bowers: 2 new sub-TLVs added. Zero discussion on the list even though document passed last call. Why wasn't discussion taken to the list. Changes could be handled in a separate document. Shouldn't WG discuss this? Acee Lindem: If changes were not made would have lost synchronization with IS-IS draft. Chris Bowers: Not sure there was unanimity among authers. Concerned that significant changes not discussed in WG Stefano Previdi: Actually 3 documents (IS-IS, OSPF, BGP-LS) were updated. We submit new version to WG and comments can be made. Acee Lindem: WG last call may have been premature due to expiration of early a llocation code points. Next steps are in presentation. Chris Bowers: Discussions should be on the list - can we agree on that? Acee Lindem: Stefano is that a reasonable request? Stefano Previdi: Fine to document changes in the document and publish. Jeff Tantsura: That a document will pass WG last call is not automatic. (objections can be made) Les Ginsberg: Documents are not written by a committee of the whole. Document revisions are based on discussions among authers and input from WG, published and then reviewed by the WG. Acee Lindem: Do you want to freeze changes to this document? Is that what you are proposing? Chris Bowers: Chairs were in the dark about changes. Communication about removal from last call was not clear. Also not clear on whether my suggested changes will be incorporated. (Actual presentation started at this point - see slides) Post presentation discussion: Chris Bowers: Is SRLB going to SR architecture document? Stefano Previdi: Yes (Note: later Stefano indicated probably not necessary) Xia Chen: SRLB - RSVP/LDP did not advertise local block - why does SR need to do that? Acee Lindem: Use cases - controller allocates binding SID and needs to know the local block from which to allocate. Xia Chen: Controller will allocate the label? Acee Lindem: Controller will choose lable and software on the node will try to allocate. Xia Chen: Seems to make sense - but need to think more about it. Jeff Tantsura: Use cases for SRLB have been described. Stefano Previdi: Only to provide controller knowledge of the local label space. Up to controller as to how to use this. Xia Chen: If extension is only to notify controller - not only for SR. PCE could use this also. Stefano Previdi: Agreed 4) OSPF YANG Model Update - 15 Minutes (See slides) - https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ - Derek Yeung Acee Lindem: Discovered we had 3 different representations for IEEE bandwidth across the models - now converged. Acee Lindem: Tool is Yumaworks from Andy Bierman Shraddha Hegde: Cannot freeze SR YANG draft until SR draft is stabilized Derek Yeung: Agreed - request for last call only for base model draft Stephane Litkowski: Need to sync on some naming conventions with IS-IS YANG model. Derek Yeung: Agreed Alia Atlas: Happy to see progress - would like to see it last call before next IETF. Jeff Tantsura: Really need to clarify notifications and RPCs from design team Acee Lindem: We have avoided this - it can be problematic to include these definitions - but can talk about this. Jeff Tantsura: Really want guidelines from design team. Will take this to the YANG Routing design team. ******************************************** NOTE: Discussion of Presentations 5 and 6 follows the completion of both presentations since they are alternative solutions in the same space. ********************************************* 5) OSPF TE Attributes for non-TE Applications Alternatives Update - 15 Minutes - https://datatracker.ietf.org/doc/draft-ppsenak-ospf-te-link-attr-reuse/ - Acee Lindem 6) Advertising TE Protocols in OSPF - 10 Minutes (See slides) - https://datatracker.ietf.org/doc/draft-hegde-ospf-advertising-te-protocols/ - Chris Bowers Uma Chunduri: What do you mean by conflicts? Chris Bowers: Different values in the TE Opaque LSA and Extended Link attributes advertisements. Hannes Gredler: Why not use unreserved bandwidth as indicating RSVP is enabled on a link? Chris Bowers: Some implementations do that - but not all existing implementations do. But it is an acceptable solution. Stephane Litkowski: Better to have clear semantics as to whether RSVP is enabled than indirect indicator. Hannes Gredler: But unreserved badnwidth is RSVP enablement indicator George Swallow: There are 0 bandwidth RSVP tunnels so Hannes proposal is a non-starter. Acee Lindem: Question that RLFA RFC 5286 standardized use of existing link a attribute advertisements for RLFA - believe it is non-normative. Chris Bowers: That is absurd. Acee Lindem: Need to look towards the future. Prefix/link attributes can eventually go to a single LSA for all attributes. Backwards compatibility problems with both solutions. If TE opaque LSA is advertised some existing implemetations make it part of TE topology as per RFC 3630. Chris Bowers: One could have an SR topology, RSVP TE topology What is the real problem? What is included in the RSVP-TE topology? If RSVP isn't actually enabled on the link then RSVP signaling will fail. Should we fix existing implementations?? Acee Lindem: You are introduced a solution to the problem which everyone will have to implement - including legacy. Chris Bowers: Operators like clean config - but admin group workaround solves this problem. Correlating information between two LSAs is a trivial problem. Acee Lindem: It's added complexity that implementations don't need. Chris Bowers: Immense testing problems. Stephane: Good ideas in both drafts. We are rushing on solutions before we have defined the problem to solve. For example what is the definition of TE? Don't agree with current definition of TE in ppsenak draft. LFA-FRR is a form of traffic engineering. The problem of having some links enabled for RSVP and some links enabled for SR is a real problem. If both are enabled on the same link requiring different attribute values per application may make sense to solve this. Do we want to have an MT scenario using different values/topology? Don't want to unnecessarily duplicate information. Shraddha Hegde: Using SRLG values from opaque LSA has been standardized. Chris Bowers: RFC 4203 is clear on this. Shraddha Hegde: If there are implementations using existing advertisements have to be backwards compatible. Problem of coordinating 3 different LSAs won't go away.. Acee Lindem: Only if you have multiple applications on the same link do we have a backwards compatibility problem. And only until we transition to new advertisements standardized by the OSPF WG as opposed to a non-normative reference in RFC 5286. Shraddha Hegde: Don't see 3 LSA coordination going away. Uma Chunduri: Backwards compatibility kills ppsenak solution. Chris Bowers: Don't see how updating the standard will help with backwards compatibility. Acee Lindem: Have the value of moving eventually to one LSA with OSPFv3 extended LSAs. Chris Bowers: Do not see moving to one LSA as a goal. Should have put extended link LSA in opaque LSA. Les Ginsberg: Agree with Stephane. Need to define the use cases and the requirements and then find a solution which meets that. Backwards compatibility is an issue in all cases. Chris Bowers: Both documents do not do an adequate job with use cases. SRLG - can use configuration based scoping. Need to describe use cases well. George Swallow: What if you have 1000's of nodes in the network that won't get upgraded - how does new TLV help? Admin group was not designed to be used in this way. David Lamparter: Agree with Stephane/Les. Confused about what is an application and what are distinct entities. Chris Bowers: Scoping things by application ??? David Lamparter: The scope of this is attributes should be used for "everything". Hannes: Problem #1: How to determine whether RSVP is enabled on a link. Have to advertise in old container format and new container format for existing deployments. Acee Lindem: Easy to correlate the multiple encodings. Stephane Litkowski: Backport adj-sid to extended link LSA?? Alia Atlas: Let's not focus on what it meant when originally defined. Need to define use cases and backwards compatibility. Acee Lindem: There are backwards compatibility issues for both approaches. RFC 3630 says Opaque LSAs define links are part of RSVP topology. Alia Atlas: Discuss actually backwards compatibility and define use cases. Chris Bowers: We should set document aside and write a use case document. Abhay Roy: Put it on the list. Chris Hopps: Is the main problem duplication of SRLG or are there multiple problems? Chris Bowers: Duplication of advertisements and defining which one to use. 7) OSPF MaxAge Flush Problem - 15 Minutes (See Slides) - https://datatracker.ietf.org/doc/draft-dong-ospf-maxage-flush-problem-statement/ - https://datatracker.ietf.org/doc/draft-dong-ospf-flush-mitigation/ - Jie Dong Acee Lindem: How many have read the draft? (many hands) Shraddha Hegde: Already have SPF holddown timers - why do we need further delay? Jie Dong: If flushing continues will cause churn. David Lamparter:T rying so solve a problem where other routers misbehave. Les Ginsberg: Cannot ignore received MAXAGE LSAs. This will cause forwarding loops/blackholes. Acee Lindem: Prefer to put burden on routers which misbehave. 8) OSPF Geo Location - 10 Minutes - https://datatracker.ietf.org/doc/draft-acee-ospf-geo-location/ - Naiming Shen Not presented due to lack of time - see corresponding IS-IS presentation.