# SPRING @IETF-118   {#spring-ietf-118}

Thursday 9 November 2023

Room: Congress Hall 1

09:30-11:30, Local

Log into the IETF datatracker to access:

*   [MeetEcho][1]

*   [Notes][2]

*   [Zulip][3]

## SPRING WG Meeting Agenda   {#spring-wg-meeting-agenda}

### 09:30 SPRING Status - Chairs (5 mins)   {#0930-spring-status---chairs-5-mins}

### 09:35 Compressed SRv6 Segment List Encoding in SRH (10 mins)   {#0935-compressed-srv6-segment-list-encoding-in-srh-10-mins}

Presenter: Francois Clad (Remote)  
[draft-ietf-spring-srv6-srh-compression][4]

Nobody in the queue.

Joel: Talked with people and they are comfortable with the updates.
Appreciate the authors and reviewers for their work. We want to move
this work along.

### 09:45 Circuit Style Segment Routing Policies (10 mins)   {#0945-circuit-style-segment-routing-policies-10-mins}

Presenter: Christian Schmutzer   
[draft-ietf-spring-cs-sr-policy][5]

Weiqiang Cheng: Valuable draft. New work called MTN published by ITU-T.
Please consider to include it which will operators who are using MTN.

Bruno: More comments and reviews needed in the mailing list before a WG
Last Call. To the authors, please ask for reviews in the mailing list.

### 09:55 SRv6 Security Considerations (15 mins)   {#0955-srv6-security-considerations-15-mins}

Presenter: Nick Buraglio

[draft-bdmgct-spring-srv6-security][6]

Yingsong Liu: We proposed a draft. Please check. We have deployed SRv6
and think that there is no risk. Please read the draft.  
[draft-liu-spring-srv6-security-experience][7]

Eric Vyncke: RFC6169 (Security Concerns with IP Tunneling) is very
similar. RFC9099 (Operational Security Considerations for IPv6 Networks)
is also important. Please have a look.

Darren Dukes: Looks good. Happy to help if you need. (From chatbox:
Security analysis was done in the context of RFC8754 with 6man and the
IESG. This continued in subsequent specifications in their security
considerations as needed. So there has been security analysis before
now.)

Zhenbin Li: It has been 7 years since SRv6 is proposed. Not a paper work
anymore. More than 160 deployments around the world. Six important banks
in China have deployed SRv6 but few security issues. Please talk with
the operators of the enterprises who have deployed SRv6 and learn from
them. In the SRv6 ops side meeting, operators have introduced their
experience. Please communicate.

Bruno: To Robin, please introduce the SRv6 ops side meeting in the
mailing list.

Jim Guichard: Thank you for the work. Appreciated. The only purpose of
this draft is that we want to well document the security considerations
and for operators to make their own choices. Not expecting solutions.

Joel: Agree, this draft also serves as inputs to other documents that
need security considerations. It is not a survey of the field.

Weiqiang Cheng: In the SRv6 ops side meeting, 5 operators worldwide have
shared their experience of operating SRv6 networks. There are some very
good materials. Basic conclusion is that there are no deployment or
security issues if it operates in a trusted domain.

Bruno: Thank you for the work and please continue.

### 10:10 Extending ICMP for IP-related Information Validation (10 mins)   {#1010-extending-icmp-for-ip-related-information-validation-10-mins}

Presenter: Yao Liu  
[draft-liu-6man-icmp-verification][8]

Zafar Ali: SRv6 OAM is a RFC now (RFC9259). We discussed before and
concluded that we should rely on the exisiting IPv6 OAM. Please consider
RFC5837. Should we rely on IPv6 or create something new? We learned from
MPLS lessons. It is very difficult and complex to introduce new OAM
mechanisms. We should carefully think about whether we need this or not.

Yao: Will check this RFC. The proposed method is intended to be simple.
We could add some more comparison and analysis.

Zafar: Good. We can talk more.

Ketan: We have the capability of exposing topologies using BGP-LS, and
this is more scalable for operators to use for validation of the control
plane, and then the existing ICMPv6 will validate the data plane.

Yao: Different from BGP-LS which is a push mechanism. BGP-LS cannot
commodate with the sudden errors.

Ketan: Control plane validation is based on the topology being exposed,
and the ICMPv6 is for the data plane validation. Both together.

Bruno: Feedbacks from operators who deployed SRv6 are good to have.

### 10:20 EVPN Fast Reroute (5 mins)   {#1020-evpn-fast-reroute-5-mins}

Presenter: Luc Andr ¦ Burdet  
[draft-burdet-bess-evpn-fast-reroute][9]

Zhaohui: Is this discussed in the mailing list? There is an alternative
mechanism. Do we prefer a flag or a new behavior?   
[draft-liu-bess-multihome-srv6-service-sid-flag][10]

Luc: Proposed in the mailing list but no responses and have not checked
the new messages.

Bruno: Discussed in SPRING or BESS?

Luc: BESS.

Ketan: The SID is the same even if we define a new behavior. This
proposal scales better. We dont need to allocate extra SIDs.

Bruno: BESS Chairs want to check whether it is ok with SPRING. Please
review on the new behavior to be defined and provide comments in the
mailing list.

### 10:25 SRH Reduction for SRv6 End.M.GTP6.E Behavior (10 mins)   {#1025-srh-reduction-for-srv6-endmgtp6e-behavior-10-mins}

Presenter: Yuya Kawakami   
[draft-kawakami-dmm-srv6-gtp6e-reduced][11]

Bruno: Not a work for SPRING but for DMM.

No comments.

### 10:35 4map6 Segments for IPv4 Service delivery over IPv6-only underlay networks (10 mins)   {#1035-4map6-segments-for-ipv4-service-delivery-over-ipv6-only-underlay-networks-10-mins}

Presenter: Guozhen Dong (Remote)  
[draft-dong-spring-sr-4map6-segments][12]

Chongfeng Xie: Provide more background information. We need to consider
how to carry IPv4 traffic in an IPv6 network. We adopted the mapping
solution and defined the SID behaviour. The draft is at the early stage.
Looking for more comments and suggestions.

Bruno: Please check with the Chairs of the BESS WG.

Chongfeng Xie: Will do.

Ketan: Already solved with BGP RFC 5549/8950, and documented in RFC9252.
The End.DT4 SIDs are defined in RFC8986. Discuss offline.

Bruno: Please send to the list, Ketan.

### 10:45 Encapsulation of BFD for SRv6 Policy (10 mins)   {#1045-encapsulation-of-bfd-for-srv6-policy-10-mins}

Presenter: Changwang Lin/Yisong Liu   
[draft-liu-spring-bfd-srv6-policy-encap][13]

Joel: To clarify as a Chair, are the two modes two different ways for
the originators within the domain to generate packets or this is
something happening at the edge that inserts an SRH into an existing
SRv6 BFD packets which is not aligned with RFCs?

Yisong: The BFD packets are within the SRv6 domain.

Joel: That is fine, just to be sure.

Greg Mirsky: Go to the 2nd slide. BFD only monitors candidate path which
is already reflected in a working group document. You are extending and
changing RFC5880. Your expectations are beyond what BFD does. Which BFD
mode do you imply when you use the term "unidirectional"?

Yisong Liu: We called the packets as unidirectional to indicate that the
packets does not return to the headend.

Greg Mirsky: Please use the agreed terminologies. Check and align with
RFC5880. No definition yet on the BFD echo in SR.

Yisong: We have proposed another draft on the BFD echo.

Bruno: Please reply in the mailing list.

Zafar Ali: To correct, BFD runs in the segment list level.

Greg Mirsky: That changes the RFC5880. Please make the community agree
with this first. Policy is not monitored by BFD.

Gao Fang: How to realise the monitoring in the reverse path?

Yisong Liu: You could use reverse binding SID or path segment. Not
specified in this draft but other drafts.

Dan Voyer @Chatbox: why not using PM to monitor SR policy ?

### 10:55 Validity of SR Policy Candidate Path (10 mins)   {#1055-validity-of-sr-policy-candidate-path-10-mins}

Presenter: Ran Chen   
[draft-chen-spring-sr-policy-cp-validity][14]

No comments.

Louis Chan @Chatbox: for validity subject, I'd rather see vendor
specific contraints encapsulated since there could be diversity of use
cases.

### 11:05 SR-MPLS FRR Extension (5 mins)   {#1105-sr-mpls-frr-extension-5-mins}

Presenter: Huaimo Chen   
[draft-chen-spring-srmpls-frr-ex][15]

Bruno: Comments in the mailing list please.

Ketan: Already a draft on this problem. This is an alternative
mechanism.

Huaimo: That was long time ago. There were two solutions at almost the
same time. To go in parallel was what had been decided before.

Bruno: Why the second solution?

Huaimo: This one is simpler.

Bruno: Please be clear about the benefits.

### 11:10 SR Path Binding Protection Architecture (10 mins)   {#1110-sr-path-binding-protection-architecture-10-mins}

Presenter: Huaimo Chen   
[draft-chen-spring-sr-bind-protect-arch][16]

Bruno: Discussions in the mailing list are needed. Please reuse the
terminologies that have been defined in the SR Architecture and SR
Policy.

Speaker Shuffling Time/Buffer: 5 minutes   
Total Presentation Time: 115 minutes



[1]: https://wws.conf.meetecho.com/conference/?group=spring
[2]: https://notes.ietf.org/notes-ietf-118-spring
[3]: https://zulip.ietf.org/#narrow/stream/spring
[4]: https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/
[5]: https://datatracker.ietf.org/doc/draft-ietf-spring-cs-sr-policy/
[6]: https://datatracker.ietf.org/doc/draft-bdmgct-spring-srv6-security/
[7]: https://datatracker.ietf.org/doc/draft-liu-spring-srv6-security-experience/
[8]: https://datatracker.ietf.org/doc/draft-liu-6man-icmp-verification/
[9]: https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/
[10]: https://datatracker.ietf.org/doc/draft-liu-bess-multihome-srv6-service-sid-flag/
[11]: https://datatracker.ietf.org/doc/draft-kawakami-dmm-srv6-gtp6e-reduced/
[12]: https://datatracker.ietf.org/doc/draft-dong-spring-sr-4map6-segments/
[13]: https://datatracker.ietf.org/doc/draft-liu-spring-bfd-srv6-policy-encap/
[14]: https://datatracker.ietf.org/doc/draft-chen-spring-sr-policy-cp-validity/
[15]: https://datatracker.ietf.org/doc/draft-chen-spring-srmpls-frr-ex/
[16]: https://datatracker.ietf.org/doc/draft-chen-spring-sr-bind-protect-arch/