Minutes IETF98: spring
minutes-98-spring-00

SPRING WG - Source Packet Routing in Networking

        Tuesday, March 28, 2017
        13:00-14:30 Tuesday Afternoon session I
        Room:    Grand Ballroom 3
 ======================================================
Chairs:
 Bruno Decraene <bruno.decraene@orange.com>
 Martin Vigoureux <martin.vigoureux@nokia.com>

Minutes taker: Jonathan Hardwick

o WG status
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=75

Martin sr-conflict: an editorial revision needed. Then going for last call.
Bruno: I've been involved in the discussion so will recurse.

Discussion on recharter vs sleep vs close the WG:
Stephane Litkowski(Orange): Very few deployments; no real operational feedback.
There may be things to change in future. So closing now may be too early.
Stefano Previdi(Cisco): Too soon to close. Maybe the SR-TE policy and SRv6
network programming drafts fit within the current charter? Alvaro Retana(AD):
Don't close. Either recharter or sleep. At minimum stay open until at least
co-requisite protocol extensions get published. Jeff Tantsura: MPLS is done but
v6 is still to come. Feedback from v6 should come into the group. Closing is
definitely too early. Acee Lindem(Cisco): Even without recharter, a few
documents are still coming in e.g. conflict resolution document. There are also
additional use case documents. So there is plenty of work without rechartering.
Martin: Agree, we do need to process that document before. Uma
Chunduri(Huawei): definitely not closing.

o Implementing non protected paths using SPRING
draft-litkowski-spring-non-protected-paths-01
Stephane Litkowski, 7 minutes, 13:15

Presentation:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=770
Discussion:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1280

Julien Meuric (Orange): Side comment as PCE chair; support this document as it
addresses interoperability issues that we may face in deployment. No change
required in PCEP session initiation (which does not imply anything about its
relevance). Jeff Tantsura: Valid use case, needs to be done. We need to support
PCEP session on demand, so need BGP auto-discovery of PCE. Stephane: For BGP,
some implementations already support authorization of a range of valid
addresses. So no configuration needed. Alvaro (Cisco): What is the goal of the
draft? Is this a mandatory to implement option? Stephane: If you want to
implement this use case you have to do it this way. Alvaro: So not mandatory to
implement. Stephane: No. Alvaro: Should it be a STD track document? Stephane: I
don't know. Martin: Who has read the document? About 10-15 persons.

o Segment Routing Policy for Traffic Engineering
draft-filsfils-spring-segment-routing-policy-00
Stephane Litkowski, 7 minutes, 13:22

Presentation:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1485
Discussion:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=1995

Jeff Tantsura: Configuration is still very imperative (CLI-driven). Decouple
the value of the binding SID from the action/meaning. The action should be
driven by the business logic, not hand-coded by CLI. Acee Lindem: Document is
only 20 pages, not 45! This document really puts SR-TE and IDR into
perspective, it's a good companion. We should discuss on IDR list. Stefano
Previdi: We removed SR policy from IDR draft and left only BGP mechanics. We
had a BGP-LS draft (LSP distribution) that we could re-use for this with a
simple extension.

o SRv6 Network Programming
draft-filsfils-spring-srv6-network-programming-00
Kamran Raza, 20 minutes, 13:29

Presentation:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=2220
Discussion:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=3204

Chair: Who has read this document?  (More than 20 people)
Prem Jonnalagadda (Barefoot): We have an implementation of this draft - just
wanted to make that comment.

o Separating Routing Planes using Segment Routing
draft-gulkohegde-routing-planes-using-sr-00
Shraddha Hegde, 10 minutes, 13:49

Presentation:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=3310
Discussion:
http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF98_SPRING&chapter=chapter_1&t=4475

Greg Mirsky: When does the 50ms failover timer start? From when falilure is
detected? (Yes) Normally in IPFRR it is understood that you have to precompute
- with a central PCE you will have to precompute for all possible failures.
Your proposal is reactive. If instead you propose FRR then describe it
explicitly. Scaling characteristics are different. Shraddha: I am not proposing
anything new about FRR itself. Your comment seems disconnected from the actual
proposal here. Greg: FRR is local computation. You are talking about central
computation. Shraddha: No, I'm not talking about central computation. Greg: So
it's computed only on nodes affected by the failure?  OK. If you put PCE in the
picture it confuses.

Jeff Tantsura: It looks operationally as complex as multi-topology.
Shraddha: You don't ave to maintain separate routing tables or configure MT
information. Jeff: Complexity from operations - troubleshooting. Jeff: Comment
2 - Look into conflict resolution daft and also mapping server. Shraddah:
sr-conflict is within algorithm (and not across) so should not be a problem.
Martin Hoeffner (DT): I don't agree PCE needed for end-to-end solution with
Anycast. Could be done without any controller. Martin: What is the overlap in
use cases between this draft and Stephane's non-protected path? The use case I
have in mind would be the same for both. Shraddah: good comment. Stefano:
Acknowledge Multi Topology does not work well. Stefano: There are easy ways to
achieve FRR within 1 plane without changing the architecture or extending the
protocol. This proposal goes way beyond what is needed. But I agree with the
requirement. Shraddah: It would be possible to tweak the TI-LFA algorithm to
stay in one plane but it requires a lot of configuration. Stefano: I don't
think it does require a lot of configuration. Tony P. (Juniper): Having
invented Multi-Topology, Stefano, you may have to hire better implementers.

Speaker Shuffling Time 5 minutes

Total 64 minutes 14:04