Minutes IETF104: spring
minutes-104-spring-00

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.