Skip to main content

Minutes IETF97: ospf
minutes-97-ospf-00

Meeting Minutes Open Shortest Path First IGP (ospf) WG
Date and time 2016-11-16 00:30
Title Minutes IETF97: ospf
State Active
Other versions plain text
Last updated 2016-11-18

minutes-97-ospf-00
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.