Skip to main content

Minutes IETF101: spring
minutes-101-spring-00

Meeting Minutes Source Packet Routing in Networking (spring) WG
Date and time 2018-03-23 11:50
Title Minutes IETF101: spring
State Active
Other versions plain text
Last updated 2018-04-16

minutes-101-spring-00
SPRING WG - Source Packet Routing in Networking

    Friday, March 23, 2018
    11:50-13:20  Friday Afternoon session I
    Room:    Viscount
 ======================================================
Chairs   Bruno Decraene <bruno.decraene@orange.com>
         Rob Shakir <robjs@google.com>

o Administrativia
Chairs
- Document Status                6 minutes    11:50

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=30

o SPRING re-chartering discussion
Chairs                          14 minutes    11:56

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=276

Items for rechartering:
* No disagreement that we should have OAM and SR policy items working on.
* Zafar Ali: This WG should work on Service chaining. On the agenda today.
* Jim Guichard: Integration of service chaining in NSH and SPRING
* Zafar Ali: Agreed. But service chaing with SR should be done in the SPRING WG
because segment routing expertise is here. * Linda Dunbar: SD-WAN integration
with SR should be worked on. It'd be interested in working in this domain. *
Martin V (Individual): Understood from Jim that Service Chaining - SR
interworking should be done. Jim: yes. No preference on where the work should
be done. * John Leddy: I'm interested in both Service chaining and joint path
selection- SPRING should work on this (rather than breaking the work in two
different WG.) * Zafar Ali: +1 SD-WAN work * Jie Dong: Virtualisation and
partitioning of network ressources - draft related to this item. * Ketan:
Ingress replication is extension of the policy work. Need to analyze the use
case and work on it in spring. * Zafar: DMM work should be reviewed here * Uma:
Mobility management should be in DMM, since this work should be agnostic to the
dataplane. Only SRv6 work should be reviewed here

Some protocol work in spring (to avoid some coordination issue)
* Zafar Ali: Likes the approach of taking the protoocl work here in a cohesive
fashion, and other WGs should review. Faciliate the process and accelerate the
work. * Jeff Tantasura: Protocol extensions should be done in protocol working
group. Architectural documents here. Good co-ordination will solve the problem.
* Acee Lindem: (as co-chair of LSR) Would be a mistake to take this into
SPRING. Coupled with the core protocol machinery. SPRING has had only 1 RFCs. *
Jim Guichard: Stifles innovation if there is one WG, SFC has had this
experience. Protocol work should be done in protocol WGs. * Stefane Litowski:
Having protocol extensions in SPRING allows use-case synchronisation across
different approaches. IS-IS/OSPF merge gives better sync. Only remaining work
is BGP-LS. * <?>: Why does this overlap with BIER? * Rob: It doesn't overlap,
it's about the model of working accross the routing area. * Alvaro: I am not
the responsible AD. There still needs to be some co-ordination. Problem that
goes beyond SPRING - we need to better figure this out. Doesn't mean authors
presenting across all WGs. * Jeff T: TEAS is not taking work on. Rather SR work
needs to work with underlying approach. * Chris Bowers: Would lean towards opt
2 (some protocol work in SPRING). Delay was useful for cleaning up the
architecture work. Bringing the work together is something that would have
benefited iteration. Flex Algo would have benefited. * Zafar Ali: Bringing all
SR responsibility to SPRING, WG/chairs get responsibility for SR. * Wim
Hendrickx: SPRING should be the architectural work. SR-TE policy has elements
across multiple WGs - should be done here, and something that should be done. *
Zafar Ali: Agree SR-TE belonfs in SPRING.

o Segment Routing with MPLS data plane
draft-ietf-spring-segment-routing-mpls-12
Ahmed Bashandy                  15 minutes    12:10

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=1588

* Alvaro (as routing AD): What do you want me to do with this information?
Draft has been revised and is now double the size. Draft was returned to the
working group. Now this work is part of the WG again - resolve comments, but
have fundamentally different document. WG has to go through last call, and has
to review. * Ahmed: Purpose of this presentation is an update on this version.
* Chris Bowers: Have done 3 IPR declarations, will you do more? * Ahmed: Yes,
if required. * Chris B: We're not in a position to be able to evaluate this
right now. * Alvaro: Going to be blunt, originally thought the draft said
nothing. Everything that the draft says is said somewhere else. IPR question --
this one has IPR against it, when the architecture does not. Question was
whether this is the right place to file the IPR? Maybe it was on something that
has already been addressed. * Greg Mirsky: Are you suggesting to create another
FEC on top of the LSP ping ones? * Ahmed: Not sure what FECs this refers to. *
Greg M: LSP ping does this. * Kamran Raza: Does not define any new form of FEC.
* Rob: Call for WG review, we need to stabilise this and publish.

o Segment Routing Policy for Traffic Engineering
draft-filsfils-spring-segment-routing-policy-05
Ketan                           10 minutes    12:25

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=2317

 * Robin (Huawei): Routing area discussion of policy - ends up complex. For SR
 policy, not only the steering policy, but has concerns about the scope. There
 is another draft relating to BFD relating to policy. There are other drafts in
 this area. * Ketan: Notion of a stack of labels in SR, but how does the node
 know what that means? Trying to define the notion of policies, and what this
 means. BFD is covered in other docs. * Zafar Ali: This document is a baseline.
 * Rob: We need to understand what the set of documents that we would like are.
 * Bruno: Policy is a wide term, you can scope it at the start of the doc.

o Segment Routing for Service Chaining
draft-xuclad-spring-sr-service-chaining
Francois                        10 minutes    12:35

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=2892

 * Greg Mirsky: Characterised as  stateless. Do you expect to program the whole
 service chain from the head-end? Are you sure that this will scale, NSH idea
 means that the SFF forwards based on the chain ID. * Francois: The head-end
 will applies all of them, if the next-hop cannot be resolved, then on-demand
 next-hop can be used (defined in SR policy). * Greg: How/where are the
 classifiers? * Francois: Just at the head-end. * Ahmed: Expect that this
 approach is more scalable, because there is nothing in the core. * Jim
 Guichard: Clarification of the proxy function. Clarification - proxy function
 has an interface/subinterface per segment path? * Francois: Yes, this is the
 current requirement - but may extend this in the future. * Jim Guichard: Do
 you take care of multiple instances hanging off the same port of a SF - some
 of the diagrams are too simplistic. If have large scale, then there are
 scalability concerns. Integrating this work with NSH using the path ID would
 mean that this scalability concern could be addressed. * Francois: If you use
 the approach in the draft with a proxy, then there may be scalability concerns
 with this. Only applies with a proxy, otherwise can just be specified from the
 head-end where the head-end specifies an instance. * Jim: Spent 4 years for
 the NSH, and we're asking for another one here. In 4 years then there will be
 another one, can we re-use things.
* <?>: If there is something that re-classifies and modifies the header then
classification may break. * Francois: Depends on the proxy

o SRv6 YANG: Base/Static
draft-raza-spring-srv6-yang-01
Kamran                           5 minutes    12:45

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=3663

<no time for questions>

o OAM in SRv6 Networks
draft-ali-spring-srv6-oam-00
Zafar Ali                        5 minutes    12:50

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=3955

Sam Aldrin: Can you do MTU? Is there a case whereby there is a non-SR network?
Zafar: Scope is non-SR, will take MTU offline.

o BFD in SR Networks using MPLS
draft-mirsky-spring-bfd
Greg Mirsky                      5 minutes    12:55

https://youtu.be/x6LjdKSwZj8?list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4280

Sam Aldrin: Is anycast SID in scope for this? If so, please document it.

o BFD for SR Policies
draft-ali-spring-bfd-sr-policy-00
Zafar Ali                        5 minutes    13:00

https://www.youtube.com/watch?v=x6LjdKSwZj8&feature=youtu.be&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4500

Greg Mirsky: Traffic engineered SR means that there is no guarantee of the
reverse path. Tried to bring a draft discussion of the suitability for bi-dir
SR paths - S-BGP is not suited well to bidir. Zafar: We should discuss offline.

o Segment Routing for Enhanced VPN Service
draft-dong-spring-sr-for-enhanced-vpn-00
Jie                             10 minutes    13:05

https://www.youtube.com/watch?v=x6LjdKSwZj8&feature=youtu.be&list=PLC86T-6ZTP5j_HaBNdfPbgxGIp22cnaWS&t=4810

Jeff Tantsura: Clarification question - same as rtgwg. When talking about
resource reservation - the controller is doing the resource reservation, not in
SR? Jie: Has to be done in the control plane and the data plane, Jeff T: Please
add some clarification. Jie: Each SID in the diagram has a portion of the
resource - have to allocate each. Isolated in both control and data plane.
Bruno: Jeff's point is that this should be in the PCE - can we clarify this,
nothing for SPRING here is? Ketan: There are a few points of clarification that
are not in the draft. Currently, reservations are not clear as to what SPRING
should review. Jie: Will add more details in next version. Zafar Ali: We should
talk offline, these problems can be solved in other ways. Discuss on the list.
Robin: Clarification, resource reservation refers to admission control in the
PCE, but no actual bandwidth guarantee in the data plane. There is also a
requirement here for bandwidth reservation in the forwarding plane. RSVP-TE can
do resource reservation, but it is not explained how to do data plane
reservation today. Speaker Shuffling Time           5 minutes    13:15

Total                           90 minutes    13:20