Minutes IETF111: spring
minutes-111-spring-01
| Meeting Minutes | Source Packet Routing in Networking (spring) WG | |
|---|---|---|
| Title | Minutes IETF111: spring | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2021-07-28 |
minutes-111-spring-01
SPRING WG - Source Packet Routing in Networking
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
Monday, 12:00-14:00, July 26, 2021 (UTC-7)
o SPRING Status [ 5 minutes ]
Chairs
No comments received.
o SRCOMP Design Team update [ 15 minutes ]
draft-srcompdt-spring-compression-requirement
draft-srcompdt-spring-compression-analysis
Weiqiang Cheng
o SR Compression analysis discussion [ 15 minutes ]
WG
Jim Guichard: Trying to find the noise (rain?) from the presenter.
Weiqiang Cheng: Not sure, the presentation is nearly finished
Joel Halpern: Questions from Gyan?
Gyan Mishra: Will wait till the Q&A.
Gyan Mishra: what is the time line. Will there be multiple solutions or pick
one? Joel Halpern: It is up to the WG. Chairs will do what the WG wants. Not up
to the design. Andrew Alston: Congrats on the good work. Based on the
presumption on SRv6. CRH is not related to SRv6. We have no need for SRv6 only
CRH. May not be valid on everthing else rather than SRv6. Jim Guichard: Ron
wants to join the Queue? Ron Bonica: Control plane drives the whole thing from
the controller... Keyur Patel: CSID is alomst a superset. Looks like a solution
going ahead. Issue a WG adoption soon? Weiqiang Cheng: The current CSID has
combined several solutions. From the DT, we have analysed different solutions
and presented the results. We hope the WG consider the adoption. It depends on
the WG's decision for the adoption. Keyur Patel: Looks like good analysis and
it looks solid. Joel Halpern: We want to know what is the WG thinking. Keyur
Patel: Comes from individual. What is the agenda of the Chairs? Jim Guichard:
The WG Chairs have not made decision. Looking for inputs from the WG. Keyur
Patel: That helps. Thank you! Daniel Voyer: Goes back to the slide Conclusions
summary 4/4. "All requirements are not equally important". It is kind of weird.
Is it that we have the agreement on the requirements before the analysis?
Talking to the DT whether it has been discussed among the team members before.
Weiqiang Cheng: In the DT, maybe some reqiurments are MUST, and others are
SHOULD. We provide all the possible requirements from the DT side. We listed
this sentence because some members in the DT have some concerns that the
requirement draft may cause some misunderstanding that the requirement items
have been given different importance. I don't agree and it is not necessary
either. Jim Guichard: Causing my confusion as well. To me the slide says that
either the solution meet the requirement or not. When you choose solution, some
requirements may not be considered about. The key point is that either the
solution meeds the requirement or not, and it is not about whether this
requirement is significant to a particular operator, right? Weiqiang Cheng:
Yes. Do you have any suggestions to the DT? Jim Guichard: No, just to try to
understand. Daniel Voyer: Should we go back to the requirements draft before we
even look at the analysis document? It is quite obvious that SRv6-based is a
MUST. But after a year, we found that CRH does not meet the requirement. It
does not provide a fair assessment. We are confusing with SHOULD and MUST. Joel
Halpern: A good topic for the mailing discussions. What the WG wants to do
this. Weiqiang Cheng: OK, thank you. Daniel Voyer: OK, done. Wim Henderickx:
What is the WG going to do for going forward? As a vendor we would like to
select one soluiton out of these. This is heavily data plane impacting.
Otherwise, we have to implement them all. How would we do that? Weiqiang:
Questions to the WG Chairs? Joel Halpern: We want to see discussions on the
contents of the two drafts on the list. We need that input. Jim Guichard:
People please go to the mailing list and express your specific views. Chairs
got their own opinions. We try not to influence. Mailing list is really
encouraged. Darren Dukes: It will be great if the WG could pick one of the
solutions. The DT has done a lot of work. Be great to get comments on the work
produced by the WG. Cheng Li: Tough work in the past year. Please look at the
text. Customers want the solutions. Joel Halpern: Close this section.
o SR-TE Path Midpoint Restoration [ 10 minutes ]
draft-hu-spring-segment-routing-proxy-forwarding
Huaimo Chen
Greg Mirsky: If understand correctly, you suggest that not all the nodes may
support the timer, the convergence is going to be problematic. It seems that
the same is applicable to this proposal. All nodes in the domain have to
support this. Why do you think all the nodes will support this proposal rather
than supporting the timer? Huaimo Chen: If the node does not support the timer
it will drop the packets. In draft T, since proxy P advertises proxy
capabilitiy so we can select the route that can support the capabilities. This
proxy solution may be a bit better since it has more information in the
network. Shraddha Hegde: The same question as Greg. If the receiving router
doesnot support draft T, it is the same. The advantage of the draft T is that
if certain PLR does not support local mechanism for protecting a node, then
draft T has a better soluiton. So far whatever protection mechanisms have been
built upon SR TI-LFA. They all follow the post-convergence path, and never
diverge from the post-convergence path. If certain PLR is not created, you are
diverting from the post-convergence path. We need to discuss how much
importance is the use case. Huaimo Chen: For some nodes that don't support, we
can provide some protection. Shraddha: We need that discussion. Peter Psenak:
Small note on what Shraddha just mentioned. Regardless of this draft, the
TI-LFA path may not follow the post-convergence path in the case of node
protection or SLG protection. That scenario can happen. Huaimo Chen: Yes. Thank
you.
o SRv6 Midpoint Protection [ 10 minutes ]
draft-chen-rtgwg-srv6-midpoint-protection
Xuesong Geng
Greg Mirsky: The node that provides protection is expected to have a state of
the notion about its edges and their capabilities so it can select. Question is
two folds. How is this node that switches to another egress knows that this
alternative is still capable? If you switch to a node that is not working, so
there would be no benefit. Why do you propose to use local protection for this
rather than to have e2e protection so not to create states in the transit node
and let the ingress node to do the switch over if something failed? Xuesong
Geng: Another case, when the existing node find its neighor node not working
and it is an endpoint, it will switch its destination address to the next
endpoint. If the neighbor of the next endpoint finds that this endpoint is not
working, it will switch to another endpoint. It will be similar till the last
endpoint. Greg Mirsky: To some extent that answered my 1st question. Xuesong
Geng: E2E protection may have their limitations such as BFD or other detection
mechanisms. Local repair will be faster. The packets won't be lost for a long
time. Greg Mirsky: Not agree that the local protection will not use BFD.
Xuesong Geng: Right, it depends. Greg Mirsky: BFD must be used. Xuesong Geng:
The detection will be still needed. But at least it will be faster. Greg
Mirsky: Regardless of single hop or multi-hops, BFD can be used aggressively.
Xuesong Geng: Like TI-LFA for the transit node, we can treat it as local
repair. This work has its scenario. Greg Mirsky: Don't agree with the approach
that harmonizes everything in a nail. Not necessarily the same mechanism works
for all the scenarios. Bruno Decraene: As individual contributor, slide 4
please. Transit IPv6 node is changing the IPv6 header. It can be seen as a
violation to RFC8200. Xuesong Geng: Similar to TI-LFA, we need to make the
repair node to some extra capabilites to enable the protection. Bruno Decraene:
For protection you may need to do something. Xuesong Geng: The transit will be
required to change the SRv6 header. The transit node is also trusted in a
limited domain. Bruno Decraene: It needs to be discussed in 6man since it
changes RFC8200. Xuesong Geng: We can also bring it to 6man. Zhenbin Li:
Explaination to Greg. When BFD is for local protection, one BFD session is
needed for one link. If BFD is used for end-to-end failure detection, it will
need 1 BFD per SR path, this will bring more deployment burden. And if BFD is
for local detection, the detection period is shorter. If the BFD is for E2E,
the timer will be longer. This is the case in practice. Jim Guichard: Please
take the discussions to the mailing list.
o BGP Extensions of SR Policy for Path Protection [ 5 minutes ]
draft-lp-idr-sr-path-protection
Yao Liu
No comments received.
o Segment Routing for Redundancy Protection [ 10 minutes ]
draft-geng-spring-sr-redundancy-protection
Gyan Mishra
Jim Guichard: Going to allow only one question.
Greg Mirsky: Suggest to analyse why this is more beneficial than just 1+1
protection when you select the working source and protection source and do the
switchover not per packet but source. Jim Guichard: The line is cut. Please
take your questions to the mailing list. Zhaohui Zhang, Balazs Varga, Janos
Farkas were in the queue. Janos Farkas suggested in Jabber: Well, relationship
with DetNet is not clear. Perhaps join the DetNet session.
o SRH and IP header protection [ 10 minutes ]
draft-chen-spring-srv6-srh-security
Meiling Chen
Ron Bonica: How this solution deal with the mutable fields in SRH since there
are many of them? Why is this solution preferable to just using the the AH in
just IPv6? Meiling Chen: It just covers several key fields in the SRH such as
source address. Can you discuss the second questions in the mailing list? Ron
Bonica: Sure, will do.
o Segment Routing Header encapsulation for Alternate Marking Method [ 10
minutes ]
draft-fz-spring-srv6-alt-mark
Giuseppe Fioccola
Ron Bonica: IETF has defined several routing headers. If you want this
alternate marking to be available to all the routing headers, the right place
would be the destination options header that proceeds the RH. Why do you choose
the SRH instead of putting it into the DOH that proceeds any routing header
types? Giuseppe Fioccola: In 6man, we have applied the DOH. For the case of
SRv6, it may prefer to use SRH TLV where the DOH may not be supported. Ron
Bonica: Since it is already allowed in the DOH at the end of the Extensions
header chain, is it also allowed in the one that proceeds the routing headers?
Giuseppe Fioccola: It will be the same behaviour. The concept has been
expressed in our draft. You will have two options to choose. It will depend on
how you deploy.
o S-BFD over SRv6 [ 5 minutes ]
draft-li-sbfd-over-srv6
Zhiqiang Li
Greg Mirsky: The draft is tagged as informational. But looks like you are
requesting a field in the flag. In that case, similar can be achieved with the
binding sid if you concern with the length of the sid list. Then it will be
appliable to both sr-mpls and srv6. Another concern is the sbfd is defined for
multi-point network. So I wonder you will consider only point to point or point
sr policies to multi-point sr policies as well. Zhiqiang: We just consdier
point to point for the first draft. The next draft may consider p2mp scenario.
We can talk in the mailing list. Jim: Thanks for attending. See you next time!
===== appendix: copy of the chat ====
Tony Li
This member would like to see SRv6 be deprecated.
21:35:41 Andrew Alston
my take on this is adopt all of them - they have different use cases as well -
and you have people who are prepared to work on them 21:35:45 Joel Halpern
@Tony - heard @Andrew - heard. Please send email. 21:36:10 Eduard V Too may
solutions would fraction the market. Slow down overall adoption. Not all
vendors would implement all solutions that would break interoperability. Hence,
solution should be one. 21:43:38 Martin Vigoureux I'd be very concerned if the
WG was to restart all the DT work. Yes, that's input to the WG, but valuable
input, resulting from a lot of work from a diversity of individuals. 21:44:20
Éric Vyncke +1 21:44:33 Zafar Ali +1 21:44:57 Kamran Raza +1 21:46:53 Boris
Khasanov If more than 1 solution they should be somehow compatible or support
interop (additional complexity) 21:47:25 Zafar Ali I agreed with Martin.
Especially because key author from each solution were part of the design team!
21:47:35 Jim Guichard @Martin the chairs would like to see mailing list
discussion on the analysis so that we can take a decision on which document/s
to progress 21:48:39 Cheng Li The result is a very valuable output for sure. It
is hard to get all the people to agree all the text in the DT. So hope you guys
can read the text if you have free time. 21:49:20 Ron Bonica Zafar, Actually,
this is not true. The design team included 7 individuals. 5 were co-authors of
CSID, 1 CRH, 1 UIDSR, 0 VSID 21:50:10 Cheng Li BTW, over 10 vendors have made
their choices and finished the interop-test in the past year. This year, our
customers around the world need the solution. 21:51:05 Stewart Bryant If node
N1 advertises the N SIDat a hight cost wouldn't normal FRR fix this? 21:51:36
Jim Guichard @everyone please send your comments on analysis to the mailing
list - if you believe only a single solution should be moved forward say so, if
multiple then say that too - the chairs are looking for guidance from the WG
rather than taking a decision without WG input 21:51:41 Darren Dukes @ron, I
believe your accounting is not correct Ron. 21:51:46 daniel.bernier@bell.ca I
agree with Martin, prior to the design team we were arguing in face to face
meetings and perpetually on the the mailing list ... which triggered the
creation of a design team if I remember correctly. If the end result of this
effort is to again await ML discussions to come up with agreement, we might
might end up with DT#2 @Jim will add my latest comment to the list thansk
21:52:44 Jim Guichard @daniel the chairs will make a decision one way or
another but we would prefer to do that based upon WG input and feedback on the
DT work outputs 21:53:24 Ron Bonica Maybe the solution is to let multiple
solutions proceed and let the marketplace decide After all, the marketplace
knows best what it wants 21:54:36 daniel.bernier@bell.ca 10-4 @Jim 21:55:56
Boris Khasanov so poor customers have to carry the burden of integration all 4
compression solutions if they don't want to have single vendor lock in.
21:58:04 Ron Bonica Or they force their vendors to implement the solution they
want? 21:59:26 Tony Li And customers all want the same thing??? You end up with
customers wanting all four and the vendors having to do all 4. No thank you.
22:00:59 Kireeti Kompella and can actually force their vendors to do anything
meaningful? 22:01:12 Tony Li I propose that we just roll dice. 22:01:23 Daniam
Henriques Boris, or the freedom to choose a solution that's optimized to their
particular constraints and design philosophy. I don't feel that the proposed
solutions are all created to address the exact same set of requirements, each
makes their own trade-offs and some may need to be assessed as stand-alone
solutions to specific requirements. 22:01:42 Boris Khasanov depends on the size
of the customer and their budget to persuade a vendor 22:01:47 Kireeti Kompella
@tony dice are loaded (by market cap) 22:02:14 Tony Li I mean that quite
literally. 22:02:35 Kireeti Kompella as did i 22:03:10 Eduard V I do not
remember any other IETF functionality that was duplicated in 4 solutions. Does
anybody remember any? 22:03:53 Ron Bonica Four solutions is excessive. Maybe we
can decide on a number of lanes (greater than 1) and allow one solution in each
lane. 22:04:46 Martin Horneffer Maybe I'm with an operator (=customer) that is
too small... but anyways: with all the options in IETF standards it already is
a pain to get interoperability for any new functionality. I really don't need
even more variety in new standards. 22:04:59 Bill Fenner Eduard, MANET
basically declared failure after failing to pick among 4 protocols 22:05:47
Kireeti Kompella @eduard vpls bgp/vpls ldp/evpn = 3 22:05:55 all deployed, but
evpn is "winning" 22:06:18 Eduard V no, EVPN is just the replacement. Hence 2.
22:06:43 Kireeti Kompella service is the same 22:06:55 Eduard V And I remember
a lot of interoperability problem from these 2. 22:07:10 Boris Khasanov
Kireeti, there were good old days when we just have to choose between ldp or
bgp signaling :) 22:07:46 Kireeti Kompella keeps life interesting :) 22:07:47
Eduard V the last one is for sure 22:08:04 fang sheng You can detect the link
fault of the directly connected neighbor to determine whether the neighbor is
faulty. 22:09:46 Darren Dukes Why adopt >1? The design team was formed to
inform the WG of requirements and analysis for compressing an SRv6 SID list. We
have a clear collaboration with interoperable solutions around CSID, and it
meets all requirements to the maximum. This isn't just my opinion. It is the
unanimous consensus of the design team that spent 1 year working on this. I
guess we can bring this to the list. 22:25:00 János Farkas Well, relationship
with DetNet is not clear. Perhaps join the DetNet session for
https://datatracker.ietf.org/meetin…ta-plane-preof-for-ip-00.pdf#page=3
22:37:57 Éric Vyncke Unsure why there is a need for a CA in this case 22:42:00
Eduard V Does it mean that SRH would be extended cross-domain? 22:42:37 Éric
Vyncke In this case, a CA could become useful indeed 22:42:54 chenmeiling yes
CA certificate used in the controller Éric Vyncke @Meiling: why not simply
distributing the public keys per ingress node (as all is done via a controller)
? 22:51:29 About alt-mark, 3 different ways (SRH, HbH, dest options) of doing
the same marking? 22:52:03 chenmeiling the range of signatures includes IPv6
Source address, SRH Last Entry, SRH Flags, SRH Segment List, AUTH TLV D, AUTH
TLV Reserved, AUTH TLV Auth Key ID. 22:58:53 fang sheng If the sid list uses
enc.x, can it still be swapped? end.x' chenmeiling we are not limited to
ingress node, we can choose the key node to verify the signature. just key node
need public key for verification.