00:00 -- Chairs
          https://www.youtube.com/watch?v=FSPWvOsUEN4&t=99
          Roundup of the current drafts.
          
          o SR Replication Policy for P2MP Service Delivery
          draft-voyer-spring-sr-p2mp-policy-01
          Daniel Voyer                10 minutes
          
          01:50 -- Daniel Voyer
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=282
          Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=590
          
          This is also being presented in PIM.
          Collaborating with Juniper -- Jeffery.
          Defines two new types of SID -- Spray (ingress replication), TreeSID,
          controller is used to program replication.
          Reliant on current SR policy.
          Looking for working group adoption.
          [Cheng Li from Huawei] There are SRv6 drafts for BIER -- what is the
          difference here?
          [Daniel] Not familiar with BIER -- will need to look at this to compare.
          [Bruno] Will you post the SRv6/BIER draft to the mailing list?
          [Zafar Ali] This is a different dataplane in BIER -- this is using the
          existing dataplane, so there’s a difference between the two.
          [Zafar] What is the plan for adoption?
          [Bruno] Chairs will come back with this.
          [Rob] We should discuss this draft on the list.
          [Zafar] This has been discussed in the community.
          
          o Segment Routing (SR) Based Bounded Latency
          draft-chen-detnet-sr-based-bounded-latency-00
          Mach Chen                10 minutes
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=774
          Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=1277
          
          9:00 - Mach
          Detnet is trying to have end to end bounded latency -- would like
          SPRING’s comments.
          SIDs that are mapped to deterministic cycles on particular links.
          Would like to solicit comments.
          [Zafar Ali] Can you comment on the scalability of this? We need hop-by-hop
          Adj-SIDs, and this is multiplied by the number of cycles?
          [Mach] There can of course be a lot of cycles. We do not expect that
          the cycles grow without bounds -- for example, we can potentially use
          these SIDs cyclic.
          [Bruno] Would be good to clarify
          [Himanchu, Ciena] Clarification question -- how will the head end know
          that the cycle that it is scheduling into is not filled? It’ll be
          difficult to know what is being used
          [Mach] These SIDs should only be used by latency sensitive critical
          traffic -- and best effort will be treated with different SIDs.
          [Himanchu] So this interops with regular SR traffic?
          [Mach] Yes, we need to differentiate detnet traffic with the SID.
          [Zafar] What happens if you miss a cycle?
          [Mach] The audio is not clear, please discuss this offline.
          [??] If you missed a particular slot on an interface, then you will
          delay until the next slot, so the latency is not deterministic.
          [Mach] This is an error condition. Detnet has some requirements on
          traffic patterns -- the rate of packet arrival is known before the path
          is chosen.
          [Bruno] Would be good to clarify what SPRING should review, or should do.
          [Mach] We are just soliciting comments from the SR perspective -- we
          may need extensions to the IGPs to advertise the cyclic SIDs.
          [Bruno] Can you post to the mailing list? Also, do we need to support
          anything other than Adj-SID (e.g., prefix,  binding SID)?
          [Mach] Have considered the existing segment types, but might need a
          different type.
          [Robin, Huawei] Considered an adjacency segment since this is linked to
          particular deterministic latency.
          
          
          o Service Paths with SR
          
          - Service Programming with Segment Routing
          draft-xuclad-spring-sr-service-programming-01
          Francois Clad                6 minutes
          
          https://www.youtube.com/watch?v=FSPWvOsUEN4&t=1800
          
          26:25 -- Francois
          [Bruno] We proposed at IETF 103 to have a discussion on segment routing /
          SFC. The goal of this slot is to discuss the requirements -- two drafts
          both have 6 minute segments, and then we have 20 mins for discussion.
          
          - NSH and Segment Routing Integration for Service Function Chaining (SFC)
          draft-guichard-spring-nsh-sr-00
          Jim Guichard                 6 minutes
          
          https://www.youtube.com/watch?v=FSPWvOsUEN4&t=2173
          
          33:40  - Jim
          Francois is discussing stateless -- this draft instead uses NSH to have
          “stateful”. This work covers the ways that NSH and SR interwork.
          NSH using SR as transport is per any other dataplane for NSH.
          Where we want to integrate NSH with SFC then NSH is beneath SR stack,
          but SR indicates that service plane is dealt with by SR -- so we should
          remove the SR header when sending to the service, and then new SR header
          is pushed based on NSH.
          Expects to update draft to define what do when SR header is removed.
          Key point: Stateful (NSH) or Stateless (SR) service chaining are not in
          competition but independant and kind of complementary and dependant on
          what a particular operator wants to deploy.
          Next steps are to adopt SPRING WG -- pursue in conjunction with SR.
          
          - Discussions on Service Paths with SR          20 minutes
          
          https://www.youtube.com/watch?v=FSPWvOsUEN4&t=2416
          
          38:10 -- Bruno
          Summary of deployment scenarios.
          [Wim Hendrickx] Two different proposals are for different environments
          -- and are complementary to each other. Assuming no proxy, one assumes
          that the service function supports NSH, and in the other cases it needs
          to support SR. People have expressed interest in both of them. Believes
          that there is a need for both of them.
          [Adrian Farrell] Some things that are seen as necessary, but some are
          open for discussion. Being able to carry NSH over SRv6 transport seems
          a necessary requirement -- we have NSH we have SRv6 networks… we need
          this. I had a strangely passionate conversation with Joel Halpern about
          the merits of having two approaches to the same requirement -- as SFC
          cochair had reluctantly allowed for MPLS SFC work because it was for
          getting SFC in a legacy requirement. SRv6 networks are not a legacy
          environment, so we have a choice of not having two ways to be able to
          do this. Doesn’t have a strong feeling as to how we approach things --
          there is a decision point here. Is this two ways of doing the same thing
          and therefore focus on just one approach. Or is this two things for two
          different use cases and therefore go ahead.
          [Jim] Thinks that there is a simple answer here -- also as a SFC
          cochair. I have operators asking for both -- so planning to provide
          both. Not fighting against each other -- complementary. So doesn’t
          have an issue pursuing both.
          [Zafar] ???
          [Rob] Clarify -- are you disagreeing with Wim?
          [Zafar] There is nothing common between the two solutions. Responding
          to Adrian -- thinks that these two solutions
          [Joel] The point of chartering SFC was that we would have a
          transport independent way to be able to do service chaining. There is
          SRv6/MPLS/Ethernet. There’s a lot of transport. We should have an
          interoperable way to do this. Creating another solution (i.e., SRv6) is
          something that is counter to the chartering of SFC. If we take apart the
          NSH and put it in TLVs in the SRv6 header -- there were other proposals to
          do this. Avoid an N^2 integration problem. Why would we do this for SRv6?
          [Robert Razsuk] Let me answer. SRH makes sense e2e -- including at
          host. Doesn’t have visibility into the NSH, at the compute notes.
          [Joel] If you have SRv6 visibility, then you likely have NSH
          visibility. Just use this correctly.
          [Ketan] The main difference is stateful vs stateless [service chaining].
          [Chen, Huawei] As co-author of stateless SFC drafts. There are significant
          differences here-- but they are complementary.
          [Adrian] “Stateless” is the key to this. Joel is right that SFC
          was chartered to SFC. SPRING was also chartered to do SFC. SPRING’s
          charter says source routed stateless service chaining. Both is in scope
          and stateless seems to be the word.
          [Daniel Voyer] The goal is to simplify the network -- Jim’s draft
          gives interop to support NSH header. Joel talked about the SFC charter,
          but it is in the charter of SPRING. This is useful work for us.
          [Bruno] Clarification for Adrian -- we already have two solutions: in NSH
          and then in the MPLS environment. Are you fine with service chaining in
          SR-MPLS given that this is the same MPLS dataplane, or do you disagree
          with that?
          [Adrian] Was previously channelling Joel. Opinion: MPLS SFC says that
          this is a way to be able to support a legacy environment. Personal view
          is that letting a lot of flowers bloom is a good way to find the right
          technology. Not opposing doing this work in SRv6.
          [Bruno] Point is that MPLS has been accepted for service chaining and
          SR-MPLS is the same dataplane. Why would these two things be different?
          [Adrian] Doesn’t oppose this -- MPLS-SR service chaining stateless
          approach works well and is actually covered in current MPLS SFC document
          (not deeply).
           approaches:
          - NSH over anything
          - MPLS in stateful
          - MPLS in stateless
          - SRv6 in stateless
           [Wim] A lot of the vendors here are transport. The biggest impact
           is on the actual services elements-- they need to support all of the
           different encapsulations (e.g., MPLS, NSH…). The adoption in this
           space is slow. Typically these vendors are in different places. Are
           these vendors supportive of this?
          [Rob] Should SPRING not define them?
          [Wim] Not saying that -- but this is an industry problem.
          [Daniel] Would like more work on ways that we can simplify the network,
          and add value to the network.
          [Jim] We just published a joint draft. Concerned that metadata, and the
          way that the TLV are defined is a challenge. We need to coordinate to
          define them such that we don’t have multiple types.
          [Bruno] Looks doable for SRv6. For MPLS, the MPLS WG have already defined
          a way to carry metadate.
          [Jim] Personal view is that carrying metadata in MPLS doesn’t make
          sense. Too difficult. SRv6 metadata TLVs should be the same as the NSH
          ones.
          [Jeff Tantsura] Industry outside of the IETF is slow. Surfnet looked
          whether they can use SR for service chaining -- but concluded that there
          weren’t enough service functions supporting this. Glad to see that
          we’re having the discussion -- but we need to provide clarity to the
          industry.
          [Rob] Can we come to consensus on the 4 different approaches -- and then
          something on metadata.
          [JeffT] Clarification that not adding metadata makes sense.
          [Bruno] The MPLS WG defines MPLS and has already defined MPLS way to
          carry metadata.
          [Adrian] Don’t think that its sensible to define metadata in the label
          stack. Draft defines a way to have an index - and then looks this up. MPLS
          draft uses the NSH, and then looks up the metadata.
          [Bruno]  See whether there are remaining discussions on the list-- and
          seems like we have clarified the problem space. The difference between
          stateful and stateless is a good way to structure the discussion.
          
          
          o In-band Performance Measurement Using TWAMP for Segment Routing
          Networks
          draft-gandhi-spring-twamp-srpm-00
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=4080
          Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=4365
          
          1:05:27 -- Rakesh
          TWAMP for SR-PM
          [Greg Mirsky] 5357 defined TWAMP control and TWAMP test. If we extend
          the TWAMP test packet, then the new option needs to negotiated in the
          TWAMP control protocol. Cannot expect that new fields are reflected by
          non-conforming reflectors. To ensure that they are we need control.
          [Greg] Said that we use the reflection port -- which one should we use?
          [Rakesh] There is no signalling here -- the port is configured.
          [Greg] What port range?
          [Rakesh] Dynamic port range.
          [Greg] Needs to be explicitly stated. The TWAMP RFC says that this
          should be dynamic pool, so this is in-line. I think that you mean that
          this should be TWAMP-lite, but this is non-standard because its an
          informational.
          [Rakesh] Yes, this is TWAMP lite.
          [Greg] Familiar with implementations -- but concerned with
          interoperability. This is why we have STAMP -- which is in WGLC. Has
          a number of differences -- including extensibility, and well-known UDP
          ports.
          [Greg] Said to use 6374, there is discussion in the BFD WG -- to extend
          BFD for PM.
          [Rakesh] There is no use of 6374. This can work with OAMP, TWAMP,
          STAMP… What we are saying is that we configure a UDP port at either
          side -- we send a message. There’s no interop.
          [Greg] Disagrees. There is no normative reference. With a non-conformant
          implementation can’t guarantee what happens with the payload.
          [Rakesh] The packet on the wire is the same as TWAMP.
          [Greg] Block number is not part of the TWAMP format -- information
          field. It’s not part of the standard message. So don’t know what
          will happen.
          [Rakesh] We define direct mode loss measurement -- this is a new
          definition.
          [Greg] If we send this to a particular packet, we don’t know what will
          happen. Must be a conforming implementation.
          [Bruno] Please take this to the list.
          [Raji Bashadi] Is it defining probe and response in the SR context? They
          are dedicated packet, not inserted in user packet. Not like typical IOM
          [Rakesh] This is not in situ OAM. This is crafted probes.
          [Raji] Would be good to reflect that.
          
          
          o In-band Performance Measurement for Segment Routing Networks with MPLS
          Data Plane
          draft-gandhi-spring-rfc6374-srpm-mpls-00
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=4860
          Discussion:
          
          1:18:58 -- Rakesh
          Requesting adoption -- should this be in SPRING/MPLS?
          [Greg] What is the value of this informational draft?
          [Rakesh] Many questions about how the PM works for SR. This draft defines
          this is how we think that this should work.
          [Greg] Mentioned bi-directional measurement. Not sure we’ve agreed
          that there is agreement on what bidir SR is.
          [Rakesh] There is some work in PCEP that is discussing bidir SR path.
          [Greg] there are a lot of things that need to happen before we are
          concerned with PM on bidir paths. This draft says something quite obvious
          -- 6374 works over MPLS.
          [Stewart] … something?
          [Greg] Return address can be specified.
          [Stewart] We need a way to specify a SID list for the return.
          [Greg] This can work over IP/MPLS for return.
          [Stewart] Seems fundamental that we can specify both forward and return
          paths -- nothing to do with the measurement, just in SR network may want
          to have SR network as the way back.
          [Greg] Same as the MPLS LSP ping -- with return option. For PM, this
          is overkill to define this within each packet. Considers that this is
          asking for inconsistency.
          [Himanchu] Supportive.
          [Stewart] Minor preference for this happening in MPLS WG -- such that
          it is in the same place than other 6374 related drafts.
          
          o In-band Performance Measurement Using UDP Path for Segment Routing
          Networks
          draft-gandhi-spring-rfc6374-srpm-udp-00
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=5260
          (no) Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=5400
          
          1:25:11 - Rakesh
          Would like to request WG adoption.
          
          o The IPv6 Compressed Routing Header (CRH)
          draft-bonica-6man-comp-rtg-hdr-01
          Ron Bonica                10 minutes
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=5420
          (No) Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=5740
          
          1:27:38 -- rbonica
          Would like wide review in SPRING and 6man -- would like adoption in 6man
          WG.
          
          o Segment Routing Proxy Forwarding
          draft-hu-spring-segment-routing-proxy-forwarding-01
          Huaimo Chen         10 minutes
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=5763
          Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=6120
          
          1:33:20 - huaimo
          [JeffT] This is just for TE scenarios, you don’t have this problem
          with non-TE?
          [H] Yes
          [JeffT] You are using TE for a reason. Probably you wouldn’t use IGP to
          say that the path failed, but BFD. Shouldn’t the headend be responsible
          for computing a path to avoid the failure node?
          [H] Is the concern that the protection path should be computed using
          the constraints?
          [JeffT] Yes
          [H] Proxy node doesn’t have this information -- so this solution
          doesn’t do this. We consider this for temporary protection, then
          head-end can restore to the constraining path.
          [JeffT] We don’t have messaging -- waiting for the IGP to converge,
          not sure of the use case.
          [H] Time from ..
          [JeffT] Pre-install the backup path -- this is how we do path protection?
          [H] Then we need BFD, we might have problems here.
          [JeffT] if we didn’t care about placement then we wouldn’t have TE.
          [H] depends on whether we want fast protection or not.
          [Acee] Using the wrong bit-vector rather in the informational
          capability. Rfc7770. Haven’t heard this called proxy forwarding --
          this is node protection. Funny terminology.
          [H] we can rename it to be more consistent.
          [peter psenak] no problem with node protection -- but I don’t consider
          that pretending a SID that has gone is a good idea. There can be second
          failures. If you need this kind of protection then we should precompute
          disjoint path.
          [Rajiv] applicability question -- if N is a boundary router between
          domains, and N is loose mode, but N has to be disjoint -- makes sense
          if it is at the border. Wouldn’t we want to do TI-LFA, and then assign
          the same prefix SID across the different elements?
          [H] We can discuss
          [Bruno as individual] Slide 4, talks about both IP prefix and Node SID --
          are you thinking about both IP and MPLS forwarding plane? IP prefix can
          be BGP nhop -- so needs to go away to trigger BGP convergence.
          [H] Keep forwarding IP.
          [Bruno] Clarify in the draft -- nhop will not disappear. IP prefix may
          be used by BGP.
          [H] …
          [Bruno] Follow up on the list.
          
          
          o Segment Routing in MPLS-TP Inter-domain Use Cases
          draft-hu-mpls-sr-inter-domain-use-cases-00
          Quan                10 minutes
          
          Presentation: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=6720
          Discussion: https://www.youtube.com/watch?v=FSPWvOsUEN4&t=7228
          
          1:49:21 - Quan
          [JeffT] Using TE/TP interchangeably -- in TP, why would we need >1 label?
          [Quan]
          [Greg] There is confusion. MPLS-TP is a profile of the MPLS network. No
          different than MPLS network. We try to look at SR-MPLS-TP as a profile
          of SR-MPLS. MPLS-TP can be provisioned with a control-plane -- which is
          GMPLS. There are different options and considerations, but MPLS-TP does
          have GMPLS control plane.
          [JeffT] It cannot distribute SR information.
          [Greg] Not offering the solution for the control plane.
          [JeffT] It should work.
          [Greg] This is a legitimate question. Needs to consider the control
          plane. Controllers (centralised/hierarchical) can be considered.
          [Bruno] Not clear for SPRING what SR MPLS-TP is -- need to define this
          profile.