Spring Status PagesSource Packet Routing in Networking (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2013-Oct-25 —Chairs:
IETF-104 spring minutes
Session 2019-03-28 1350-1550: Congress Hall 2 - Audio stream - spring chatroom
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). 4 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.