Minutes IETF112: spring
minutes-112-spring-00
| Meeting Minutes | Source Packet Routing in Networking (spring) WG | |
|---|---|---|
| Title | Minutes IETF112: spring | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2021-11-16 |
minutes-112-spring-00
SPRING WG - Source Packet Routing in Networking
Chairs:
Bruno Decraene
James Guichard
Joel Halpern
Secretary:
Shuping Peng
===============================================================================
Monday, 12:00-14:00, November 8, 2021 (UTC)
o SPRING Status [ 5 minutes ]
Chairs
Joel Halpern presented.
The issue tracker for the adopted compression document will be on the Github.
Srihari Sangli (from the Chat Panel): Should 6man bless the document? c-sid and
its relationship to RFC4291. Joel Halpern: The 6man will decide the
relationship.
o Enhanced Performance Measurement Using Simple TWAMP in Segment Routing
Networks [ 10 minutes ]
draft-gandhi-spring-enhanced-srpm
Rakesh Gandhi
Greg Mirsky: It enables one way measurement. The reflector doesnot have a
state, and the packet does not leave the data plane. The format of the
reflected packet is different from the format of the packet received from the
sender. How you can simply swap the source and destination address of the two
packets? Also if you dont have state in the reflector you cannot measure one
way but only round trip. It is not accurate. I think some serious problem with
this. Rakesh Gandhi: Thanks. The loopback measurement mode has been defined in
a working group document. Please have a look at the draft and let us know. That
is for the round trip delay. This is an optimization where the session
reflector using the network programming function as the receiver timestamp.
This is explained in the enhanced loopback mode draft. Please have a look and
let us know about your comments. Greg Mirsky: I sent comments before the
meeting. I see contradiction between the statements. SR programming does not
introduce any special mode in the stamp. The reflector has to be stateful for
the one way measurement. The underlay for the packet encapsulation is not
really relevant. We can continue in the mailing list. Rakesh Gandhi: I will
look at your recent email and reply. Stewart Bryant: How do you avoid the ECMP
issue with this? The ECMP will give you a different answer when you run this.
Is ECMP safe? Is it for MPLS? Rakesh Gandhi: For ECMP there are standard
techniques for example using the Entropy label. Stewart Bryant: You require
the Entropy label for the ECMP safe measurement that is absolutely fine, but
you must show it. Currently it is not. Rakesh Gandhi: We will add it. Stewart
Bryant: It has to be high level required because people will get the wrong
answer. You cannot publish a document where people get the wrong answer. Rakesh
Gandhi: Good comment. We will add it. Andrew Alston: What is the impact on the
BCP38? The incorrect sender and receiver. That reversal of addresses does kind
of worry me. Would like to hear your thoughts on the impacts on things like
BCP38 and anti-spoofing protection. Rakesh Gandhi: If that is not suitable for
the network, so the second method for the reverse path can be SR-MPLS. The full
label stack could be used to bring the packet back to the sender. Both methods
have been defined depending on the deployment. One of them can be selected.
There are already many RFCs around about using the swapping of the source
address. It is no difference here. Joel Halpern: Please continue email
discussions.
o Segment Routing for End-to-End IETF Network Slicing [ 10 minutes ]
draft-li-spring-sr-e2e-ietf-network-slicing
Yongqing Zhu
Vishnu Beeram: Slide 3 that showed all the relevant drafts. We have a WG draft
on framework which stated ietf network slices, and we don't limit the scope of
that draft. It would be good to limit the scope of this draft on how to stitch
multiple vtns together. Jie Dong: The related framework draft of this draft
will be presented tomorrow in teas. This draft is more about SR based extension
to solve the multi-domain mapping and concatenation. Adrian Farrel: Speaking as
the editor of the network slicing framework draft in teas which is intended to
be sort of all embracing for ietf network slices. I want to caution the authors
here to be very careful about the term end-to-end. It has been used by 3GPP.
The IETF network slice is only a part. The concept of end has a strange meaning
in IETF. Maybe step back from the headline title of end-to-end and talk more
about what you want to achieve, rather than get hooked on the terminology.
o SRv6 inter-domain mapping SIDs [ 10 minutes ]
draft-salih-spring-srv6-inter-domain-sids
Salih K A
Zhenbin Li: End.replace is similar to swap of MPLS. In SRv6 we don't need SWAP.
Why to introduce this SID. Salih: It is for multi-domain. On the boarder node,
it is for option C and uses BGP. Ketan Talaulikar: End.DB6, service SID is per
prefix or per VRF. Salih: Per prefix. It is option B. Ketan Talaulikar: Please
clarify in the draft. Also, suggest to consider per VRF instead. Salih: Sure.
Cheng Li: Don't understand why to replace the destination address. 2. When the
SID list contains one SID like BSID, what is difference between the BSID and
End.replace. The procedure is the same. Salih: If it is multiple SIDs to reach
the other domain. It will be based on the situation. We will update the draft
with more details. Zhenbin Li: The purpose of this type of SID. It is different
from MPLS and SRv6. IPv6 can reduce using aggregation. It is reducing the
benefits of SRv6. Salih: Different scenarios. It is for multiple domains and it
is option C. It could be multiple intent-based path. Different mechanisms for
different scenarios. Shraddha Hegde (from the chat box): This mechanism is for
loosely coupled domains where aggregation is not possible. Darren Dukes:
Additional discussion of how an SR Source uses SIDs of these behaviors and will
be interesting to see in subsequent versions. Salih: Will update the draft.
Shaofu Peng: END.Replace seems enough why we need END.ReplaceB6? Salih: In the
diagram you can see that cross areas you need multiple SIDs in the SRH and that
is why you need to push an additional SRH at the corresponding ingress boarder
nodes. It will be clear with an example when we mention it in the draft. Cheng
Li (from the chat box): Better to clarify why we need these new behavious why
not the existing ones.
o SRH encapsulation for Alternate Marking Method [ 10 minutes ]
draft-fz-spring-srv6-alt-mark
Giuseppe Fioccola
Ron Bonica: Why would you not to make it more general, and make it work for any
other routing header? Giuseppe: Just to leverage this capability of SRH to be
extended to TLV. The solution for all the routing header is already in the 6man
draft. There we define the DOH that can be applicable to all the routing
header. It can be an optimized solution only for SRH. Ron Bonica: It seems a
second solution for the problem you have already solved. Tianran Zhou (from the
chat box): The generic way is defined in 6man. This is only an optimization for
SRH. Joel: Please continue in the mailing list.
o A Simplified Scalable ELAN Service Model with Segment Routing Underlay
[ 10 minutes ]
draft-boutros-spring-elan-services-over-sr
Sami Boutros
Éric Vyncke: Your draft and your slides got a section about IPv4 arp but
nothing about v6 NDP. Will add support for IPv6 support later? Sami: Yes, will
add later. Matthew Bocci: Relationship with the draft in BESS? Clarify your
intention of the BESS draft. This relates to BGP signalings and it should
really live in BESS. Sami: The concept is more segment routing so we present
the concept here in SPRING. The signaling details will be in BESS. Here is more
about the concept and the architecture. Will clarify in the later version. Joel
Halpern: The Chairs will coordinate to make sure that the right materials are
discussed in the right WG. Patrice Brissette: The same comment to Matthew. Is
it any difference between there two drafts? Sami: No, not right now. Will
change the other draft to more signaling aspects in the later version.
o Intent-based Routing [ 10 minutes ]
draft-li-teas-intent-based-routing
Zhenbin Li
Linda Dunbar: Is that intent perform the similar function to QoS / Policy in a
way that you can steer traffic and give another layer of policy matching
criteria? Zhenbin Li: To some extent, it is similar. To be more exact, it is
like color, such as low latency or high bandwidth, not only just like DSCP
which is just a codepoint. It is a abstract of the requirements. Not a detailed
service requirement. Eric Vyncke (from the chat box): please specify whether
the IPv6 Dest Options should be BEFORE or AFTER the routing header.
o Source Segment for Multicast Source Routing over IPv6 [ 10 minutes ]
draft-xl-msr6-source-segment
Xuesong Geng
Ron Bonica: What happens if a packet has a SID as its source address but for
some reasons the packet can not be forwarded, and the node cannot forward it
sends an ICMP message to that source address. What does the ICMP message go?
Xuesong: The source address is still routable. The locator part is still
routable. Just the MVPN information can be carried in the Argument part. Ron
Bonica: So lower bits are totally ignored at the source. Joel: This is a
detailed discussion. Please go to the mailing list. Zhaohui Zhang: This concept
was first brought up in BIER. There were a lot of discussions in the mailing
list. Xuesong: It is not for BIER. This can be used for any IPv6 based
multicast scenarios to carry mvpn. We also discussed this in the section 6 in
the document. Please review the draft.
o Functional Addressing (FA) for internets with Independent Network
Address Spaces (IINAS) [ 10 minutes ]
draft-eckert-intarea-functional-addr-internets
Toerless Eckert
Joel: It is very questionable whether it is within the charter of SPRING.
Take care! Stay well!
Speaker Shuffling Time/Buffer: 5 minutes
Total Presentation Time: 85 minutes