Minutes IETF109: spring
minutes-109-spring-00
| Meeting Minutes | Source Packet Routing in Networking (spring) WG | |
|---|---|---|
| Title | Minutes IETF109: spring | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2020-12-09 |
minutes-109-spring-00
# IETF 109 SPRING WG
Chairs:
Bruno Decraene <bruno.decraene@orange.com>
James Guichard <james.n.guichard@futurewei.com>
Joel Halpern <jmh.direct@joelhalpern.com>
Secretary:
Shuping Peng <pengshuping@huawei.com>
==========================================================
# Session I
* Wednesday, 12:00-14:00, November 18, 2020 (ICT (UTC+7))
## 1 SPRING Status [ 10 minutes ]
Chairs
No comments on the Agenda.
For the egress protection, we have about 5 or 6 drafts related to this subject.
It is better to align between the RTGWG and the SPRING WG. It could be an
interim meeting.
## 2 Segment Routing Policy Architecture [ 15 minutes ]
draft-ietf-spring-segment-routing-policy-09
Ketan Talaulikar
Tarek Saad: Slide 7 please, it is about the block allocation for dynamic SR
policies, we had email exchanges. In favor of a separate block of colors for
those dynamically created policies by a controller. I am not sure about letting
operators manage the color blocks. It will be cumbersome. Evetually it has to
be learned dynamically from PCEP and other protocols. Ketan Talaulikar: Please
clarify your concerns if we dont do that. Tarek Saad: For the hiarachical SR
Policy just presented. Ketan Talaulikar: The operators may not use them for
steering? Tarek Saad: Yes. Ketan Talaulikar: There are the cases like BSIDs
that do not use colors. We look for more inputs and take it forwards. Shraddha
Hedge: Composite candidate path introduces one more level of weighted ECMP. It
is possible for some platforms may not support this. It would be good if we
could add some text to address what should happen in this case. Ketan
Talaulikar: Agree with you. This hierarchy is more from conceptual and
framework perspective. Not forwarding plane as it is implementation specific.
Please provide some text and discuss. Cheng Li: It is hard to understand the
composite candidate path. More text would be good. Do we really need to specify
that the endpoint of the composite candidate path must be identical? Ketan
Talaulikar: Yes, otherwise, it will be odd to have them go to different
destinations. It won't fit the hierarchy. We can discuss more in the list.
Please suggest the text for clarification and then we should add. Boris
Khasanov: Separate color block for non-BGP case may bring additional complexity
because we will require color negotiation etc. It could be more helpful but
also more complexity. Ketan Talaulikar: Opinions on both sides. We can further
work it out on the mailing list. Bruno Decraene: WGLC? Ketan Talaulikar: We
should wait to reach consensus on these conversions today.
## 3 An MPLS SR OAM option reducing the number of end-to-end path validations
[ 5 minutes ]
draft-geib-spring-oam-opt-00
Ruediger Geib
Bruno Decraene: Any questions can go to the mailing list or private.
## 4 Segment Routing Generic TLV for MPLS Label Switched Path (LSP)
Ping/Traceroute [ 10 minutes ]
draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-04
Nagendra Kumar Nainar
Srihari Sangli: How do you handle the anycast sid? Is there any procedure you
would recommend? Nagendra Kumar Nainar: In case of anycast, we are not going to
replicate. We will not be expecting multiple responses. Xiang Ji: Only one
bottom FEC is needed to be validated at the far end or a stack of FECs for each
segment? Nagendra Kumar Nainar: It depends on what you want to validate. If it
is multiple FECs that need to be validated then you need more. If it is the
bottom most in case of PING, then you just need to include the bottom most.
## 5 Seamless Segment Routing [ 10 minutes ]
draft-hegde-spring-mpls-seamless-sr-03
Shraddha Hegde
Ketan Talaulikar: The draft has three parts: use cases, requirements, and
proposal based on BGP-CT. There are several solutions available, e.g. H-PCE.
Would it be better for the WG to first look at the use cases and the
requirements? Shraddha Hegde: We can look at the use cases and requirements and
discuss. The proposal is different than the existing one. It is using BGP-based
mechanism to interconnect multiple domains. The existing solutions are mostly
using label stacking and not using BGP. This architecture is extension to the
existing seamless MPLS, trying to bring the capability to create multiple
colored paths end to end. Ketan Talaulikar: Use cases and requirements are all
Informational. Seamless MPLS is actually informational. The WG is better to
tackle the use cases and requirements to capture what is there. We should
document all the solutions not just one. Shraddha Hegde: Fair point. Ketan
Talaulikar: We can collaborate and discuss further offline. Boris Khasanov:
More comparison with BGP-LU is needed. Currently it is just one sentence.
Shraddha Hegde: Add more text to the draft. BGP-LU could give you one single
best path. Here we add capability to create multiple paths. I agree to add more
text. Ron Bonica: Reply to Ketan. Two distinct requirements. One is for
coarse-grained TE between networks and the other is for fine-grained TE for the
network that is much more tightly coupled. This draft should go forward to
satisfy the first requirement. Shraddha Hegde: Very valid point. Ketan
Talaulikar: Exactly my point that the WG needs to have a better understanding
of these requirements. Kireeti Kompella: To ketan. If it targets as a standards
draft then it needs a requirement draft. Now it targets as informational,
better set out the goals and how to achieve them. Requirement draft will create
overhead. Whether we should have hierarchy or not? Hierarchy has trade off,
losing granularity and e2e visibility. Should be fine to document both
solutions. Uma Chunduri: Read the draft, strong believe to adopt it. Support.
Ketan Talaulikar: Agree with Kireeti. But the draft is standards currently. We
want to present all the various solutions if it is an informational. So
operators can make their choices. Still believe it would be valuable to have a
separate doc to record the use cases and requirements. Ron Bonica: It is good
to have a requirement document. We should not have solution document block the
informational one. We had that in the past and we should not repeat that. *
Chairs polling: If you have read the document, do you think that it provides a
good start? - hand raised: 14 - hand explicitely not raised: 13 - read the
draft (computed): 13+14=27 - total participants: 121 Bruno Decraene: We will
welcome more discussions on the list. Please focus on the subject. We can
discuss later whether to split the draft into two, by requirements and
solutions.
## 6 Segment Routing Header encapsulation for In-situ OAM Data [ 10 minutes ]
draft-ali-spring-ioam-srv6-02
Zafar Ali
Greg Mirsky: It is about how to use IOAM trace option. That is only one way. In
IPPM WG, there is a working group draft, direct export, does not require any
information to be added to the packet. It has a number of advantages. In IPPM
Monday's session, the proposed hybrid-two-step method is a combination of the
IOAM trace option and direct export. It creates a follow-up packet which is out
of band. Have you consider this out-of-band collection? Zafar Ali: Agree that
out-of-band collection would be needed in some cases. O-bit is defined. It does
not effect the in-band solution. Both have their own space. We collect the data
from only the capable endpoints. Greg Mirsky: MTU is more concern for the IOAM
trace option. It may reach limit. For the direct export and hybrid there is no
limit. It will need corelation. There are tradeoffs. Zafar Ali: Segment list is
deterministic. The MTU is also deterministic. We need the in-band solution. Ron
Bonica: Agree with Greg's comments. It will work with the SRH. How will it work
with the micro SID? Zafar Ali: The decision is based on the local
configuration. Ron Bonica: Even though you route through micro-sid you will
still look at the SRH. Zafar Ali: Yes. SRH TLV is equally applicable to
micro-sid. Ron Bonica: ok Bruno: With micro-sid you don't use SL (Segment
Left). Not sure how the IOAM encoding would work. We can follow up. Giuseppe
Fioccola: The relationship between this draft and the IPv6 IOAM draft? It can
be achieved using DOH+SRH. Zafar Ali: We can take it offline. When using HBH,
you can collect hop by hop. The difference is that we collect from the
endpoints. Giuseppe Fioccola: Similar discussions in 6man. You can use DOH+SRH
to have the same effect. Bruno: Have you presented in 6man? Zafar Ali: Yes,
have presented a few times. I leave Chairs to discuss. Bruno: Need to discuss
with the 6man Chairs to coordinate. Andrew Alston: Multiple methods to do it.
Would it be helpful to have a fully-defined requirement document? Zafar Ali:
There are already a lot of drafts in IPPM. We only use the IPPM encoding for
the SRv6 network. We can discuss offline. Xiang Ji: Is there a TLV to allow us
skip some segments? Zafar Ali: TLV processing is only based on local
configration on the segment endpoint. Xiang Ji: The headend control is that the
headend can decide which nodes to measure. Zafar Ali: We can discuss the
headend control offline. Bruno: Discuss in the mailing list both on in-band and
out-band.
## 7 Point-to-Multipoint Transport Using Chain Replication in Segment Routing
[ 10 minutes ]
draft-shen-spring-p2mp-transport-chain-03
Yimin Shen
Adrian Farrel: No forking anywhere else apart from at the source?
Yimin Shen: Right
Adrian Farrel: For some topology it does not work well. The Letter Y topology,
normally a P2MP fork. It does not work in other topologies. Yimin Shen: Works
better in ring topology and linear topology. Not in all the topologies. In
general, in certain type of topology with certain constraints it works. Adrian
Farrel: It makes it a useful tool rather than a global solution. Jeff Tantsura:
Why don't you use the BSID? Use BSID as the Bug SID. Yimin Shen: The idea is
the same. We want it to be routable. Please refer to example 1. Jeff Tantsura:
Computation should be addressed in the PCE. Interested to see what type of
computation you could do. Xiang Ji: Large number of destinations, how to do the
TTL manipulation in a uniform mode to allow the chain do not terminate earlier?
Any considerations on the label stack depth? Yimin Shen: If a large number of
leaves, you will use a large number of chains. Specify the maximum hop count
when you do the path calculation to limit the maximum delay, which should be
derived per chain based. Bruno Decraene: There are a set of trade-offs
involved. It would be good to discuss more.
## 8 Segment Routing for Redundancy Protection [ 10 minutes ]
draft-geng-spring-sr-redundancy-protection-00
Fan Yang
Ron Bonica: Slide 8, is it possible that SRH2 or SRH3 is longer than SRH 1.
Fan Yang: Between these two nodes (Redundancy and Merging) this is a redundancy
protection. Ron Bonica: So SRH may be longer when it leaves from redundancy
node, right? Fan Yang: Yes, any concern? Ron Bonica: The same concern as the
head delete and insertion. You might have MTU problem. Fan Yang: It is a
generic problem, not in the scope. Reply to you later. Ron Bonica: You have the
same problem to make the header longer. Fan Yang: I will reply to you later to
understand it better and see how we can solve the problem. Cheng: That can be
solved with compression, which would be another topic on Friday.
Bruno Decraene: Running late.
For Egess protection, there are several drafts, need coordination, we are going
to have an interim meeting for it. We are going to skip the slides.
## 9 SRv6 Path Egress Protection [ 10 minutes ]
draft-ietf-rtgwg-srv6-egress-protection-01
Huaimo Chen
Skipped
## 10 SR-TE Path Midpoint Protection [ 10 minutes ]
draft-hu-spring-segment-routing-proxy-forwarding-12
Huaimo Chen
Skipped.
Bruno: We'll setup a dedicated session for the subject of segment
endpoint/egress failure.
## 11 YANG Data Model for SR Service Programming [ 5 minutes ]
draft-jags-spring-sr-service-programming-yang-00
Jaganbabu Rajamanickam
Bruno: No time to review the draft in details. It can be reviewed in the draft.
No comments to the mic.
Thank Huaimo for understanding.
Meeting on Friday dedicated to Compression. Please read the requirement draft
and have an effective discussion.
* Speaker Shuffling Time/Buffer: 10 minutes
* Total Presentation Time: 115 minutes
==============================================================
# Session II
* Friday, 14:30-15:30, November 20, 2020 (ICT (UTC+7))
## SPRING Status
Chairs
The design team was created on 7th July.
## Design Team: status update and future plan
Weiqiang Cheng
The github for minutes and documents of the design team:
https://github.com/IETF-srcomp
Jim Guichard: Please be aware that there is another presentation. So please
only comment on this one rather than the output.
Ron Bonica: One thing to add. The current draft still don't include all the
requirements. A lot of them have not been worked on yet. Do you agree, Weiqiang?
Weiqiang Cheng: Yes, roughly agree.
Andrew Alston: You said the design doc is done, but then said the design doc
will be ready in Dec. The current doc only states the obvious. Questions to the
Chair, do you believe that this DT will produce a proper design doc in a
reasonable timeframe? It is already over the timeframe which was promised. Do
you believe that there will ever be consensus in the DT? What is the chairs'
opinion on where is the DT to go?
Jim Guichard: It has not been 6 months but 4 months. It is a requirement doc
not a design document.
Weiqiang Cheng: Agree with Chairs. Hope to help the WG to get to the right
direction about the technology. Don't know when we can get agreement in the WG.
Make the plan to guide the DT to reach the target. So far the submitted draft
is still an individual draft. We still need strict review, comments and
modifications to reach rough consensus. I won't say we have consensus in the DT
then the WG should accept our output.
Andrew Alston: Zero responses from the DT to the comments submitted to the
mailing list.
Weiqiang Cheng: Would like the WG Chairs to give some comments.
Joel Halpern: DT will be the one to take care of the comments. Please engage
with people and reflect the comments in the next version. We need to move on.
Ahmed Bashandy: Better to lay out the requirements and let the WG to decide.
There is no consensus on what the requirements are within the DT after a long
time. Existing standards should be included in the Appendix and taken into
account when we choose the design.
Weiqiang Cheng: Thank you.
Greg Mirsky: Sent comments recently, looking forward to discussions. One
general concern is that the DT was chartered to set requirements for compressed
sid in IPv6 networks. From the title and the abstract, it seems that it only
focus on SRv6. The charter is broader than the scopt of the current doc.
Appreciate comments from Weiqiang or the Chairs.
Jim Guichard: From Chairs' perspective, DT can make their own decision. If the
assigned task (SR compression over IPv6) and the results don't match, then the
DT needs to explain. We would like the DT to look at all the possible solutions
and make those requirements.
Greg Mirsky: The DT should follow the Charter. If they decide that there is
something might stay out of the Charter, they need to provide good reasons
based on technical discussions.
Joel Halpern: Chair cannot say more at this time.
Darren Dukes: To Greg, it will be answered in the next presentation.
Cheng li: The DT is hardworking. If people are not happy about the progress
please contribute. The title of the draft is the consensus of the DT.
Joel Halpern: The scope of the doc should be coming out from the next
presentation.
Chongfeng Xie: SRv6 has been defined in a series of RFCs and WG drafts and
deployed in operator's networks. From the point of migration, the future
compression solution should be SRv6 based. It should be taken as a basic
requirement.
Luay Jalil: Appreciated the work. I see general requirements in the current
doc. A lot of work in the past were use case driven. Per use case may be more
beneficial. The consensus is the most important, and should be thought about up
front.
Keyur Patel: Thank to the DT, but hoping to see consensus. Please get the draft
in shape. Looked at the Appendix and requirements, if there is no consensus,
please be aware that we Arrcus have running code and solution based on SRv6. We
like to see consensus soon.
## SR over IPv6 Compression Requirements
draft-srcompdt-spring-compression-requirement-02
Weiqiang Cheng
Greg Mirsky: What is marked as "full consensus"? Got a impression that the
requirements are centered for the brown field scenarios. Recommend to consider
the green field scenario.
John Scudder: Surprised to see that the forwarding efficiency requirement
listing the number of headers parsed as metric, which is wrong to me. I would
rather parse three very simple headers instead of one very complicated header.
Satoru Matsushima: All the requirements are good. Especially impressed by the
requirements in the Appendix. As the operator who has deployed SRv6 in a while,
these SRv6 based, SRv6 functional TE and heterogeneous SID-list are really
important requirements to us. Please make sure these requirements to be the
normative part of the requirements.
Bob Hinden: Talking about the slide "SRv6 Base Coexistence". Although I read
the draft, but still could not understand what does this mean " The compression
solution MUST support deployment in existing (RFC8402) SRv6 networks." Please
elaborate.
Weiqiang Cheng: This figure is provided by Ron Bonica. Please answer, Ron.
Ron Bonica: Two SR paths in the figure. One path is using SRH, and the other is
using compression mechanism whatever it is. The Node 3 should support both but
not in the same packet.
Bob Hinden: Okay, good, thank you! That helps.
Darren Dukes: Bob, we also called it the ship in the night at one point.
Reminder on timeline: There is pandemic. People took vacation in the summer and
design team really started in September. Design team worked very hard and long
hours. It is a good start. The requirements come from operators and the people
we have contacted. The design team agreed that SRv6 SID list is what needs
compressing. The document considers both SRv6-based and non-SRv6 solutions.
Please read past the first page of the draft.
Ron Bonica: Agree with Greg. What is the charter of the DT? Compression of SR
over IPv6 or compression of SRH? Should we also consider the green field?
Jim: It is important that the DT identifies what needs to be compressed. If the
DT decides that it is the SRH that needs to be compressed then that is what we
need to focus. Figure out what needs to be compressed and work from there.
Wim Henderickx: I am part of the DT. DT is working on both green and brown
fields. We have not done analysis yet. Currently building requirements draft
general enough to cover both fields. Different people want different things. We
want to remain open at this stage. The way we want to do the analysis which we
havenot discussed. For some of the requirements we want to build a set of use
cases and then anaylze the solutions that are out there. To John on
performance, we had consensus on how to do it. The DT has agreed that the
lookup will determine the performance and efficiency of how the implementation
will scale. So we keep the requirement in the doc and believe that it is
valuable.
Cheng Li: We include both green and brown fields. The draft is not ready yet,
still a lot to do. The compression requirement comes from the overhead of the
SRv6 SID. So the name of the draft is appropriate. Yet the draft does not limit
the solutions to SRH-based only. Right now we focus on very general
requirements. The text is fine right now.
Tom Hill: I have a concern around the mix of compressed and uncompressed SIDs
in the same header. It is not efficient from the forwarding plane perspective.
Suggest the DT to look at all the requirements in a broad perspective instead
of isolation. Make sure there is no contradictory element there.
Andrew Alston: Agree with Tom. It is really efficient. Anything outside of SRv6
should be outside of the consideration? There are already other solutions with
running code and being shipped. People will not stop developing. The delay here
is harming the whole eco-system.
Joel Halpern: Allow Weiqiang to answer. The time left is very limited.
Weiqiang Cheng: Good question. The first goal is to get the right direction for
the WG. There are a lot of solutions but we should give a clear suggestion to
the industry which one should be adopted by the WG. The DT team will do its
best but the decision should be made by the WG.
Yisong Liu: As an operator, I think that the compression solution should be
compatible with classic SRv6 standards, so the requirements and the compression
solution should be SRv6-based. Please progress solution very fast, because CMCC
needs to deploy SRv6 with compression soon. Thank the DT for their work.
Martin Horneffer: The requirements listed so far are good if you are in a green
field approach with a single network domain or a small number of network
domains. But missing one requirement for a brown field in large multi-domain
environments. To manage the SID number space, it would be much painful to do so
for many network domains that you might want to consolidate in a large
organization. Would like to see it to be added.
Huaimo Chen: Can you explain the reason for mixing compressed and
non-compressed SIDs?
Jim Guichard: Take to the list. Long explaination. No time now.
Ketan Talaulikar: Thank the DT. We are in the requirement stage, and approaches
come later. The requirements should not look at only what have been deployed
with SRv6. Building on existing standards and introducing things is how the
IETF works.
Joel Halpern: Continue on the list. We need to know what is the most important
for the DT to consider. Encourage the DT to work towards the goal and finish
within the timeline that has been laid out.
Daniel Voyer: Thank the DT. Scalability is important and should be considered
in the requirements.
Joel Halpern: Thank you all!
* Speaker Shuffling Time/Buffer: 5 minutes
* Total Presentation Time: 60 minutes