IETF
idr
idr@jabber.ietf.org
Wednesday, July 27, 2022< ^ >
Meetecho has set the subject to: IDR IETF-113
Room Configuration
Room Occupants

GMT+0
[18:52:18] <zulipbot> (Jeffrey Haas) Good afternoon (locally) everyone.  you should be seeing the chairs' slides.  Meeting will start in ~~ 10min
[19:01:09] <zulipbot> (Randy Bush) @sue: loud and clear
[19:01:23] <zulipbot> (Job Snijders) Audio sounds good Susan
[19:01:23] <zulipbot> (Jeffrey Haas) thanks!
[19:01:36] <zulipbot> (Randy Bush) @jeff: you do not look like sue
[19:01:49] <zulipbot> (Jeffrey Haas) she has better hair.
[19:01:49] <zulipbot> (Jie Dong) here is the link for the collaborative note taking: https://notes.ietf.org/notes-ietf-114-idr
[19:03:45] <zulipbot> (Randy Bush) re autoconfig: no users wanted
[19:03:58] <zulipbot> (Tony Li) Did we get any operator responses?
[19:04:11] <zulipbot> (Jeffrey Haas) We did not, Tony.
[19:12:17] <zulipbot> (Jeffrey Haas) We're trying to run the timer to make sure people get the allocated time for their presentations.  Please be mindful of the time.
[19:13:00] <zulipbot> (Jeffrey Haas) Note that Jie's presentation will be moving to bottom of agenda to accommodate him having a conflict with a presentation in 6man.
[19:19:37] <zulipbot> (Jie Dong) thanks Jeff
[19:21:50] <zulipbot> (Randy Bush) fine sue
[19:22:51] <zulipbot> (Jeffrey Haas) Note that we expect a lot of discussion here, but have limited time.  we'll do best we can to make sure presenters have fair time to provide their content and if we have time for discussion we'll do so.
[19:26:59] <zulipbot> (Jeffrey Haas) Note that we have a typo in the slides for Tomasz Szewczyk's name  and affiliation for Poznan Supercomputing and Networking Center.  We'll  arrange for these to be corrected before minutes are cut.
[19:36:05] <zulipbot> (Dan Voyer) @Tony Li, if we end up with both for operator, it will be fun when we come back with an interop
[19:38:53] <zulipbot> (Tony Li) I disagree with your definition of 'fun'. :-)
[19:39:55] <zulipbot> (Jeff Tantsura) @dan - took us 10 years to fix rsvp-te, which was supposed to interop day 1 :)
[19:40:39] <zulipbot> (Jeffrey Haas) A goal is to make sure all known issues are published in the appropriate document.  There shouldn't be lost "lore" as part of the process that surprises people after publication.
[19:42:38] <zulipbot> (Adrian Farrel) @Jeff. My RSVP-TE implementation interop'ed fine. It was everybody else's implementations that didn't interop
[19:43:25] <zulipbot> (Jeff Tantsura) @Adrian - it is always the “other guy”
[19:44:07] <zulipbot> (Jeffrey Haas) We have 7 minutes for discussion if anyone wants to enqueue.
[19:46:11] <zulipbot> (Randy Bush) as an op, if you are talking interdomain (which i question due to vuln of communities) then interop would seem to be important.
[19:46:24] <zulipbot> (Dhruv Dhody) Thanks chairs for all your efforts in managing a difficult adoption call!!
[19:46:50] <zulipbot> (Jeffrey Haas) Thanks to the WG for navigating a difficult adoption.
[19:46:50] <zulipbot> (Jeff Tantsura) +1, great work chairs!
[19:50:06] <zulipbot> (Tony Li) In other words, the IETF process has failed multiple times.
[19:52:58] <zulipbot> (Jeff Tantsura) One might argue that interpretation is the issue, not the process…
[19:53:11] <zulipbot> (Randy Bush) @rony: +1
[19:53:24] <zulipbot> (Randy Bush) *tony
[19:54:27] <zulipbot> (Tony Li) @**Jeff Tantsura** AFAIK, the IETF is an SDO. Its purpose is to produce standards.
[19:54:40] <zulipbot> (Adrian Farrel) @Randy. Doesn't your point mean that we need reports from consortia of operators?
[19:55:29] <zulipbot> (Randy Bush) when i was youger, a standards body was driven by users' desires for a common interoperable device
[19:55:48] <zulipbot> (Randy Bush) now it seems to be driven by vendors desires to sell shiny objects
[19:56:08] <zulipbot> (Jeffrey Haas) /me stares at both IS-IS and OSPF...
[19:56:37] <zulipbot> (Tony Li) Which is exactly why things like autoconfiguration, which demonstrate zero operator interest, should be tabled.
[19:56:50] <zulipbot> (Randy Bush) yup
[19:57:29] <zulipbot> (Randy Bush) except "tabled" has the opposed (to american) meaning in some cultures
[19:58:00] <zulipbot> (Randy Bush) @jeff: i doubt there is a shortage of stu^Wduplicity.  it is the converse which grows scarce
[20:00:04] <zulipbot> (Aijun Wang) There are many similarities between CAR and CT solutions, when we compared with other conflict proposal for the same goal.  Then I think there is more possibilities to converge these two proposals into one
[20:00:28] <zulipbot> (Randy Bush) this would be a good thing
[20:00:54] <zulipbot> (Tony Li) Have we considered a 'thunderdome' approach?
[20:01:48] <zulipbot> (Jeffrey Haas) Wearing a leather bikini would satisfy ietf dress code, tony, but I don't think it'd suit you.
[20:02:29] <zulipbot> (Tony Li) Full agreement. However, I was suggesting that the chairs mandate that the two alternatives collaborate and converge.
[20:02:55] <zulipbot> (Randy Bush) /me being media impaired assumes arena of blood
[20:02:55] <zulipbot> (Jeffrey Haas) We tried to raise the meta issue at wgchairs this afternoon.  We are likely to have to act unilaterally.
[20:03:39] <zulipbot> (Aijun Wang) How about to build one Design Team to accomplish this aim?
[20:03:53] <zulipbot> (Jeffrey Haas) at this point, with two deployed code bases, a merged solution just means a third solution.
[20:04:06] <zulipbot> (Wim Henderickx) why need setup a team including the authors to try to converge.
[20:04:19] <zulipbot> (Wim Henderickx) sorry why not iso why need
[20:04:19] <zulipbot> (Randy Bush) how about adopt neigher draft until the two groups come back with one draft?
[20:07:20] <zulipbot> (Aijun Wang) I support. Either side should make some compromises, or else, no converge possible
[20:08:11] <zulipbot> (Boris Khasanov) A design team may have chance to succeed as it was in other WGs
[20:08:53] <zulipbot> (Randy Bush) the label on the door of the room in which they sort it out is not really very important.
[20:10:56] <zulipbot> (Bill Fenner) Thunderdome≅ Design Team
[20:11:25] <zulipbot> (Randy Bush) /me dives for duckduckgo
[20:12:32] <zulipbot> (Randy Bush) yuchh!
[20:13:22] <zulipbot> (Tony Li) @**Jeffrey Haas** I would happily take a third, standardized and de facto standard. However, a third, partially deployed solution would be worse. Could we force the first outcome?
[20:14:49] <zulipbot> (Jeffrey Haas) I have articulated to multiple parties that with three changes, we could likely end up with a merged solution.  There is a level of intransigence of the participants at this point.  If there is some belief that they would actually compromise it might be possible.
[20:15:32] <zulipbot> (Randy Bush) don't adopt until they resolve
[20:15:59] <zulipbot> (Gyan Mishra) As we adopted both solutions, I understand the motivation for operators on interoperability as the fear from standardization perspective that each vendor will maintain their own solution and not develop the other solution.  I think if this went the same way as OSPF, ISIS good example as completely different solutions and both solutions were implemented and no need interoperability as that would be impossible.  I think if both solutions are progressed to ensure interoperability between vendor, instead of making CAR and CT interoperability work which may or may it be possible it would be better if both vendors implement both solutions.    I think operators should push for the implementation of both solutions.
[20:16:48] <zulipbot> (Randy Bush) QED, eh?
[20:17:56] <zulipbot> (Tony Li) Well, the OSPF/IS-IS result is that we have two roughly identical results. Twice the work for no benefit.  Not a happy model.
[20:18:35] <zulipbot> (Ketan Talaulikar) @ Tony, +1 on OSPF/ISIS and I agree overall
[20:18:48] <zulipbot> (Randy Bush) as someone who had to merge 66 (yes, 66) isps who had one or the other, this was a major horror.
[20:19:27] <zulipbot> (Fan Yang) @Jeffrey presentation material for Redundancy policy is here https://datatracker.ietf.org/meeting/114/materials/slides-114-idr-advertising-redundancy-policy-in-bgp-00
[20:20:20] <zulipbot> (Jeffrey Haas) Fan, I can see the presentation in the list but it's not in the pre-imported slides.  I shall have to share my full screen.
[20:20:46] <zulipbot> (Randy Bush) fan's url produces a pdf
[20:20:59] <zulipbot> (Fan Yang) is there anything I can do?
[20:21:12] <zulipbot> (Aijun Wang) For CAR/CT, both solutions require end-to-end planning for the color/intent, I think it is impossible for one operator to deploy both of them. Will it also difficult/confusion for the vendor to support both of them
[20:21:25] <zulipbot> (Jeffrey Haas) It's our problem, fan. I think we'll have you next presentation.
[20:21:38] <zulipbot> (Fan Yang) great, thank you
[20:27:36] <zulipbot> (Gyan Mishra) @Randy & @Tony, I hear you on the M&A and having to change IGP, however having alternative
[20:28:32] <zulipbot> (Randy Bush) with is-is/ospf it was releatively "easy" as they are feature compatible and one can convert using ships in the night.  not so with car/st.
[20:28:46] <zulipbot> (Randy Bush) *ct (excuse cat in lap)
[20:30:56] <zulipbot> (Gyan Mishra) Agreed.  That is good example as well as having two IGP in operator toolbox does help troubleshoot one over the other as you can run both in parallel and flip between the two with AD change.
[20:31:48] <zulipbot> (Randy Bush) unless some of the devices do not support, e.g., is-is (not mandated by 1812)
[20:31:49] <zulipbot> (Gyan Mishra) Similarly possible with CT/CAR implementation of both you use both to troubleshoot the other as well
[20:32:14] <zulipbot> (Louis Chan) I have the impression that this kind of redundancy policy is a special case of multicast but with same destination.
[20:34:27] <zulipbot> (Randy Bush) @gyan: if they are so similar and feature compatible that i can debug one against the other, then clearly we do not need both.
[20:34:42] <zulipbot> (Tony Li) And we all pay for both, whether we're using them or not.
[20:34:55] <zulipbot> (Randy Bush) forever
[20:35:21] <zulipbot> (Randy Bush) twice the bugs, twice the cost, and twice the fun
[20:36:14] <zulipbot> (Fan Yang) @Louis The behavior on redundancy node is the replication of packets, kind of similar to multicast replication. But since redundnacy protection is mainly used for protection to unicast traffic, we prefer to use the unicast mechanisms to achieve the same functions.
[20:37:34] <zulipbot> (Jeff Tantsura) @fan we have used similar techniques going back as far as PIM dual-join
[20:39:09] <zulipbot> (John Scudder) Regarding the OSPF/IS-IS analogy, I have to pass on a quote heard at a years-ago IDR meeting:
Person 1: "As you know, we have two IGPs: the good, and the bad".
Person 2: "... and the ugly"
[20:39:10] <zulipbot> (Jeffrey Haas) Jie, are you here for next presentation?
[20:39:35] <zulipbot> (Fan Yang) another point is redundancy protection and multicast are quite different scenarios. There is no obvious benefit to use multicast mechanism to solve unicast problem.
[20:40:01] <zulipbot> (Jie Dong) @Jeff yes i'm back
[20:40:02] <zulipbot> (Jeffrey Haas) Thanks. You're last presentation and the next one.
[20:40:41] <zulipbot> (Gyan Mishra) @John 😀
[20:41:23] <zulipbot> (Fan Yang) @Jeff good point. It is always good to work on the shoulder of history. I will look into it and come back to ML.
[20:41:46] <zulipbot> (Jie Dong) ok
[20:42:21] <zulipbot> (Gyan Mishra) @Randy - I guess we will find out how similar if they can figure out how to make interoperability work.  Cheers 👍
[20:43:27] <zulipbot> (Les Ginsberg) @John The "ugly" comment was in reference to BGP linkstate. :-)
[20:45:18] <zulipbot> (John Scudder) @Les I was trying not to point fingers but yes it was.
[20:47:13] <zulipbot> (Les Ginsberg) @John Neither was I - and which protocol is "good" and which is "bad" is in the eye of the beholder.
[20:47:44] <zulipbot> (Tony Li) Ok, but we have rough consensus on "ugly".
[20:48:17] <zulipbot> (Les Ginsberg) For some definition of "we".
[20:49:19] <zulipbot> (Gyan Mishra) @IDR FYI, I am presenting on TCPM on Friday a deck on NG TCP Yang mode to help with BGP TCP statistics for states due to the TCP zero window issue that has come up on ML.  This all came about during my OPSDIR review or TCP Yang model and issues brought up and compromise to progress that draft and addres in this new draft - idea was brought up by Sue - I won’t take credit for it.  If you are around on Friday try to drop in for my presentation would be great!👍
[20:50:53] <zulipbot> (Gyan Mishra) Feedback from the WG greatly appreciated!
[20:50:54] <zulipbot> (Shunwan Zhuang) BGP-LS brings many job opportunities for network engineers:)
[20:51:26] <zulipbot> (Tony Li) We need more?
[20:51:27] <zulipbot> (Jie Dong) thanks everyone
[20:51:39] <zulipbot> (Boris Khasanov) RIFT? :)