**Session Date/Time:** 23 Jul 2026 07:00

[00:00:11] **Co-Chair**: We can try on the speaker pad to switch to you.

[00:01:08] **Matthew Bocci**: Hi, folks. Welcome welcome to Bess. If you could just get yourselves onto the on-site tool while we wait for a couple of minutes for the folks to arrive.

[00:01:27] **Jeffrey Zhang**: Have you clicked on that one?

[00:01:29] **Speaker 3**: No. Not yet.

[00:01:54] **Jeffrey Zhang**: Now you are able to grab now, right?

[00:01:56] **Co-Chair**: It looks like it. We'll see as long as it works. You might have to swap. Just give it a tough fight last night. Let's check if this works.

[00:03:22] **Matthew Bocci**: It's plugged into the Raspberry Pi there. Where

[00:03:37] **Co-Chair**: is it? Okay.

[00:03:40] **Speaker 3**: Can you keep an

[00:03:41] **Matthew Bocci**: eye on that?

[00:03:42] **Co-Chair**: And I'll do the talking and pushing for hours. Don't just double check it works if you Does that mean I can't do anything? Just a minute. I'm just gonna get the agenda up. Good morning, everyone. My name

[00:04:42] **Matthew Bocci**: is Matthew. I'm one of the co chairs. I'm here here with Jeffrey, and Mancomano is our scribe today, our secretary. This is BGP enabled services. Okay. This is the note well. I'm sure it being nine a. M. On Thursday morning. You've seen this many, many times before this week and in the past. If you have any questions, ask one of the folks at the front of the room here or our AD at the back, who is Gunther. A few meeting tips. You must be signed in via data tracker. You could use the QR code that was shown earlier on, or I think it's just outside the doors there. Use the on-site tool on your phone. It's easiest thing, really, but we'll use that for managing the queue. And for any remote participants that we have, please make sure your audio and video are off unless you are speaking. And please, you come to the queue come to the mic, state your name for the minutes. Okay. The agenda is posted. I think we talked about MeetEco. So here is the agenda. We now have a fairly complete agenda. We had a lot of last minute requests. Thank you. Any questions on the agenda? I hope that we have everybody's slides who's presenting. Everybody was very, very late submitting their slides. It's very difficult to manage a 9AM meeting when the slides are so late. You know who you are. Please in future try to get it a couple of days beforehand. Luckily, we didn't have too busy an agenda this time. But traditionally, if it's not here a couple of days before, you lose your slot. I just want to make a note about the BGP directorate review team. So this has been formed to help with cross working group reviews and things affecting the base BGP protocol for drafts related to BGP, which of course includes BESS. So they'll cover many of the drafts here. So there's already a couple of reviews that have been requested or have come in. Please watch out for BGP directorate reviews of your drafts in addition to the traditional Routing Directorate and Gen Arts and so on, other area reviews you may get. Okay, let's go into the working group status update. No new RFCs have been published since the last IETF. Thanks, Gunther, for doing a great job at processing everything that was in your queue. So now I think we have to send some more to you. There are some documents in the RFC editor's queue. Finally, the BGP's first D1 overlay networks document is in the RFC editor's queue. Multicast and ethernet VPN with SR Point two multi point ingress replication, the EVPN IPVPN interworking document, and the weighted multipath procedures for eVpn multi homing is in the RSC editor's queue at the moment. Please, if you are an editor of one of those documents, watch out for any questions you may get from the RSC editor, And please try to reply to them promptly. In AD and IESG review, there's BGP based multi homing in VPLS. So this is related to BGP VPLS, not EVPN, I think. And this is the one that was submitted a very long time ago to the IESG due to various changes in the editorial team for the draft that kind of died in the IETf. We brought it back, and then we sent and we appointed a new editor, which was, I think, pretty, and we have sent it back again. So hopefully, we can get this this done fairly quickly. We know that, obviously, there's deployments of this, so it would be it's quite important for us to to get this draft to RFC. We have some working group drafts that have passed working group last call and have a few outstanding kind issues with them. So the EVPN BFD draft still has this issue. It had consensus to publish, but it failed the implementation poll. We did not have anybody declaring an implementation of this. And for standards track documents in Bess, we have a requirement to have at least one implementation. So one potential way forward of this is to make it experimental. Another potential way forward is to just let it sit until somebody declares implementation. I think we would I don't know if anybody has any opinion on a good way forward for that, but the chairs will consider it.

[00:10:25] **Ketan Talaulikar**: Yeah. So this is Prasadv, Matthew. Think I'm okay with going experimental because our technical comments have been reviewed. I am one of the coauthors.

[00:10:45] **Matthew Bocci**: So I think the the comment yeah. I think the comment was you're okay with it going experimental because all the technical comments sorry. The audio is not very good in the room. Saw the record. Yep. Yep.

[00:10:58] **Prasad Miriyala**: Thank you.

[00:10:59] **Matthew Bocci**: Okay. One of the things you do need to think about if it goes forward as experimental is to define an experiment that needs to pass to then potentially upgrade it to a standards track document at a later date. Okay. Sure.

[00:11:20] **Co-Chair**: Okay.

[00:11:21] **Matthew Bocci**: So the seamless master class interoperability between EVPN and MVP NPEs, that's waiting for write up. Venkamma, you had comments on this?

[00:11:37] **Mankamana Prasad Mishra**: Yes. I have provided comment. I think once we have the updated version, I'll do the write up.

[00:11:54] **Susan Hares**: Hi. My understanding, from the IDR first meeting is that just a minute.

[00:12:01] **Matthew Bocci**: Maybe state your name as well.

[00:12:04] **Susan Hares**: Yeah. Understanding is that after Shu checked with this company, there isn't any IP on that. You should double check with him, but that was what he announced at IDR. So and you can talk to Khitan about that. He would I think the the message was supposed to go to the best list as well.

[00:12:28] **Matthew Bocci**: Is that on this one or the DMZ draft? Both Okay. Of

[00:12:35] **Susan Hares**: That's the big draft- I t f- b g p e b g p d m

[00:12:39] **Sasha Vainshtein**: z. Yeah.

[00:12:43] **Matthew Bocci**: Okay. The EVPN control plane for Geneva. Again, this is another draft that had working group of census but failed the implementation poll. I think it's been switched to experimental status, but it does need to have some text in there to define the experiment so that we know when it would be potentially possible. That was a comment from, I think, from Adrian Farrell on the list about that. Don't see the editor. The editor was Sammy. I don't see Sammy in the room. But if the other authors could please get together, contact Sammy, help us get this thing moving forward. That would be very helpful. Okay. BGP link bandwidth extended community use cases and eGP DMZ draft is in working group last call. That one also had a potential one individual said there might be IPR on it, but they haven't done a formal declaration, and I think this is one of the drafts that in IDR earlier in the week, they verbally said there was no IPR on it. So I'd like to see that clarified on the list.

[00:13:59] **Ketan Talaulikar**: Yes. So that's what that individual said in the IDR meeting on Monday. I asked them to send that to the list. They send it only to the IDR list, but I have forwarded that to the best list as well.

[00:14:13] **Matthew Bocci**: Thank you.

[00:14:14] **Ketan Talaulikar**: So I think this should be okay to go.

[00:14:21] **Matthew Bocci**: So this this is something that this is a document that's being shepherded by by Jeff. So I think we can ask him to move forward with that consensus.

[00:14:37] **Jakob Heitz**: I'm having

[00:14:39] **Co-Chair**: why is it clicking not doing anything? Updating there.

[00:14:47] **Matthew Bocci**: Okay. We have a number of working group drafts that have had reviews or comments on the list that are outstanding for the a little bit of discussion around more discussion around this and getting updates to the documents. The BGP based multicast draft, This is ready to move forward, but it's waiting for a companion controller draft. And the controller based BGP multicast signaling draft, the authors are currently addressing. Don't say anything about that.

[00:15:19] **Jeffrey Zhang**: Sue has been helping us addressing the quite some comments on the tunnel encapsulation attribute templates. We are working on that. We should be able to finish that soon and be ready to move forward. Thank you, Sue.

[00:15:41] **Matthew Bocci**: Okay. The extensions for mobile user plane, draft- has a BGP director to review due on it. I see where bundling service interface in EVPN, I think the you've had some comments on this. It's just updated. You were gonna check the resolution of the comments?

[00:16:05] **Jeffrey Zhang**: We need to to discuss this further. We had we were going to talk about it offline in this idea, but we have not got the chance. We will need to get a conclusion on this and then move forward.

[00:16:24] **Matthew Bocci**: EVPN support for Layer three fast convergence and aliasing slash backup path. Mankhamana, you had some review comments that need to be addressed by that? You don't have comments? Okay. That's incorrect. Okay. So the EVPN multi homing mechanism for led to gateway protocols, that didn't receive a lot of folks speaking up in support of that at working group last call. So didn't really see clear consensus to move forward even though we folks had declared implementations, which is a little bit concerning. So please, could you review the draft and maybe we can run another working group last call shortly to try and move this forward. Need to see more than just the authors of drafts, saying that they are happy to move forward or showing evidence that they have reviewed and commented on document. And the dpath for EVPN- interconnected networks has a BGP director review on it. They posted comments. I think that said not ready. I'd like to see those comments addressed, please. There's then a couple of drafts that are related to the updates to RFC-seventy four-thirty two. That's the RFC-seventy four-thirty two. This draft is the main draft itself. That work has been ongoing for a number of years now. There are some outstanding comments from Geoffrey that I think the authors haven't yet addressed.

[00:18:18] **Jeffrey Zhang**: Jorge has responded to one of the comments and I get it now. Will try to provide some suggested text for that, on that particular topic. And there are other comments. I have not seen any responses. I guess people are busy. To clarify, most of my questions or comments are kind of editorial because I don't think it's technical, But those things are probably obvious and intuitive to real EVPN experts. They are just so they take things for for granted, they can do that. But for people who are not so familiar, then I think it's important to get those things clarified. So, I would like to get those questions or comments answered.

[00:19:18] **Matthew Bocci**: Okay. The next one in this set is the draft on EVPN interoperability modes, and there's some comments that maybe it makes sense to merge this into the r c seventy four thirty two bis document. Any thoughts on this? Okay. We'll send a proposal to the list, I think.

[00:19:45] **Co-Chair**: Oh, sorry, Hako.

[00:19:50] **Matthew Bocci**: Kia is actually first in the queue.

[00:19:54] **Keyur Patel**: Hey, Keyur Patel, Arrcus. Two slides back, you were talking about the mup-safi draft, which is going to go in the BGP directory review. I just wanted to let the working group know we have multiple implementations, two or three to be precise now. Since this working group does not do implementation reports, but IDR does, I'm just letting the working group and the chairs know that we have not filed the implementation report?

[00:20:25] **Matthew Bocci**: Yeah. Normally, way that we handle reporting implementations is simply to ask the question on the list because the gatekeep you know, in Bess, it's really a it was put in as a kind of a gatekeeper to make sure that we got serious protocol we focused on serious protocol extensions. A services working group, we are less concerned well, obviously, we're concerned that things interoperate very much so, But it's more about making sure we work we're focused on on key things that people are implementing.

[00:20:57] **Keyur Patel**: Yeah. I'm just letting you know, in case if the directorate review inside BGP or IDR comes and asks you for implementation, I'll I'll send this out on the working group, but just as an FYI. Somebody's keeping track

[00:21:08] **Sasha Vainshtein**: of it.

[00:21:08] **Himanshu Shah**: Yeah.

[00:21:12] **Sasha Vainshtein**: Hi. Yeah.

[00:21:14] **Ketan Talaulikar**: I'd like to share something from BGP directorate perspective. These reviews are meant for the working group, the whole working group and not just the authors. What I've observed is that it's only the authors that need to kind of respond and all, but I would request the working group to consider this as an input to you and for everybody to, you know, look at the points raised and discuss, debate, argue, agree, and work it out. Please don't think that this is just on the authors to do it, which is typically how, you know, the late reviews are handled from direct rates. So if you agree, disagree with the authors when they respond, yeah, please do that. It would be appreciated.

[00:22:05] **Co-Chair**: K. Thanks. Okay.

[00:22:09] **Jorge Rabadan**: Jorge, Just a comment about the EVPN modes interrupt draft and whether we should merge it with seven forty three-two BIS. The draft itself, there are some aspects that we could actually merge into seven forty three-two BIS because they deal with, like, you know, EVPN broadcast domains. But there are some other aspects that are more layer three, more related to RFC nine one, three five, and three six, which really do not fall into the seven four three two base draft. So I'm not convinced about merging. Okay.

[00:22:52] **Co-Chair**: Manchu.

[00:22:55] **Himanshu Shah**: Himanshu Shah from Sienna. I haven't looked at the latest 7432 bis, but long time back, I had made a comment saying that we should have a small summary of the changes or delta between seventy four thirty two main draft and and the main RFC and the biz. Have you included that in the seventy four thirty two base? And just while he's coming here, you had couple of slides away, the last call failure on l two gateway. I mean, we have the implementation, but I guess you answered the question saying there is it was just a consensus issue. Right? No technical holding back the last call fail?

[00:23:42] **Matthew Bocci**: Sorry. Can you say that this Yeah. The audio is very bad up here.

[00:23:45] **Himanshu Shah**: Yeah. The layer two l two gateway interrupt, it you said that it failed the last call.

[00:23:56] **Matthew Bocci**: And it So, yeah, what happened was that wasn't enough. There was very few people replied on the list, and I think they were all authors.

[00:24:03] **Himanshu Shah**: No technical issue.

[00:24:04] **Matthew Bocci**: So, we need to see I think I stated that knew there were implement people just declared implementations, but there was just yeah, it was only the vendor only the people who had built, you know, implemented it that had declared anything on the said anything on the list. And so we really need the evidence that the working group as a whole has reviewed it.

[00:24:27] **Himanshu Shah**: Okay. We we will do that, but you will reissue the last call. Right?

[00:24:32] **Matthew Bocci**: We we can reissue the last call. Yes.

[00:24:34] **Jeff Tantsura**: Okay.

[00:24:38] **Jorge Rabadan**: Jorge Jorge, no care. Just replying to Himanshu. The first versions of the seven four three two base draft, it had sort of a log section basically highlighting the changes. But at some point, we decided to remove it because it was just adding noise. So I don't think it makes sense to put it back. I don't know.

[00:25:04] **Himanshu Shah**: You put it back.

[00:25:06] **Matthew Bocci**: Put it put it an appendix. Yeah.

[00:25:09] **Sasha Vainshtein**: Sasha Weinstein. Just wanted to say that the LARS two gateway protocol draft has indeed a few implementations and and a live a deployment and a live network exists. So from my point of view, the time is ripe for the repeat the work of last call.

[00:25:39] **Himanshu Shah**: Sorry. Not in line, but I've both are two large big documents. I think the seventy four thirty two base should consider putting the delta summary back in the in the seventy four thirty two base. Otherwise, it's very hard to go through entire document, find out what has changed. It it really helps. It's a huge document. Thanks.

[00:26:08] **Co-Chair**: Great. Thanks. Okay.

[00:26:19] **Matthew Bocci**: We have a few ongoing working group drafts, eVpn- vPWS service gateways, and extended procedures for eVpn optimized ingress replication, which is on the agenda. We have a few newly adopted working group drafts. I just wanted to point out, we're still waiting for a new working group document version on the proxy MAC IP. So as soon as you get as soon as your draft is adopted or we declare consensus on your draft, if you get upload a new working group version, document version that helps us to track documents. And the applications and procedures for unknown Mac routes and EVPN was uploaded and then has just expired, but it's on the agenda. Please try to keep your documents, even if it's just changing the revision number and posting a new version. We have a huge number I think I'll comment this. We have a huge number of expired working group drafts, which is a bit surprising because in theory, when we adopt a draft as a working group draft, it's something that the working group wants to work on. Yes, as I said, there are too many listed in the data tracker to mention in terms of the expired working group drafts that we have. There are some very old ones going back more than ten years, I think. They were parked originally. It's probably time to mark them dead. I don't think some of those are going to come back. We will send a some going back to 2014.

[00:28:05] **Speaker 3**: The working group

[00:28:06] **Matthew Bocci**: adoption queue, we have three drafts currently listed, I think, on the the wiki. If there's anything missing here that the chairs have missed that you would, you believe is ready in addition to these, please send a note to the chairs. I just wanted to have a quick note on some work that went on in the m v o three working group that since the m v o three is not meeting, but this is directly supporting stuff that we have in drafts here in Bess. This is the update to VXLAN, VXLAN spec, which has gone to the ISG now. And the updates are ready to create a new VXLAN flags registry that best can use. So it's taking it from the original RFC was on the independent stream. This BIS version takes it into the IETF streams, and now the IETF has control over the protocol design. Obviously, this protocol is implemented in potentially millions, if not billions, of devices out there. So the only change here was to create a backwards compatible registry in the VXLAN header for the VXLAN header bits. So it's currently in IETf- last call, and it's with Gunter.

[00:29:39] **Jeff Tantsura**: Jeff-, N-f-, Routing Working Group Chair. I recall we discussed finishing up NVO three work in routing. Are we splitting it now? Where are we?

[00:30:01] **Matthew Bocci**: The n v o three still exists. This was a document that did go through n v o three as, actually as a working group document in on the Sanders track for a long time, the original RFC. Then at the last minute, it was sent to the ISC due to, I think I think I believe at the time, it was concerns with change control going to the IETF from the original authors. Now, those original authors have since come back and said, actually, we would like to add add this. Running through this those changes through m v o three makes sense, but yes, we do need to have a discussion on what happens to m v o three now. This is the best meeting. Let's have a separate discussion about m

[00:30:40] **Co-Chair**: v three.

[00:30:40] **Jeff Tantsura**: Let's do so. Thank you.

[00:30:49] **Matthew Bocci**: I think that is it. I think, Wen, then you're you're on next. I will just

[00:31:07] **Co-Chair**: I'm

[00:31:13] **Matthew Bocci**: having some excuse me. I'm having some meat echo problems.

[00:31:23] **Co-Chair**: Stop sharing the site. Somebody's in the tracker. Can you take me off control of the tracker? Take it off. Seems to be stuck. Can you try and show the next slide?

[00:32:16] **Matthew Bocci**: Yeah. I can't get it

[00:32:17] **Co-Chair**: to do it. It's just frozen. Okay. Do you wanna share the clicker again?

[00:32:49] **Matthew Bocci**: Oh, there's a sense to be some lags in the Internet.

[00:33:05] **Wen Lin**: Hi. My name is Wen. I'm from HP. I'm today gonna present extended EVPN optimized ingress replication for EVPN on behalf of other authors on the list. Thank you. This draft has been exist for a long time, so just a refresh. Today, it's extension of the original draft, which is IFC ninety five seventy four optimized ingress replications. So the extended optimized ingress rep replication draft added a multi home procedures for in the case for the NVO network for e v EVPN. In the case for EVPN VXLAN and MPS over x, like in encapsulations based on the using the ex existing Sprint Horizon rules, whether it's local bias or using ESI label filtering rules as specified in those IFCs. So a quick recap, optimized ingress replication can do for EVPN. So this is a defined assistant replications to define the rule for assistant replication leaf and assistant replica. The purpose of it is trying to reduce the number of broadcast multicast flow you have to send from from one point to the other. So as as you see in a typical data center from leaf to the spine and broadcast and the multicast traffic have send multiple copy as number of the for East West traffic. But a system replication help us to reduce the multicast or broadcast flow from leaf to spine. You only need to send the one one flow, one call a one copy of the flow. And they use the replica, which is the spine, it will replicate traffic to the rest of the leaf. It's obviously saved the uplink bandwidth and in the typical data center topology. But there was a challenge in supporting multi homing. As you know, in the data center, a lot of server host are in the multi multi home to to leaves. So the way a system replication work is the leaf send a copy to its replicator, and the replicator will actually decap the packet and then re encat the packet to be using ingress replication to send to the rest of the leaves. So during the decap and the incap process in the replicator, it is hard to, at least, it's hard or difficult for some of the platform to maintain still maintain the source IP address if local bias is used or the ESI label because you do the decap and the re incap. So this draft is actually trying extended procedure is trying to simplify the procedure to overcome the difficulty either in the hardware or make the implementation too complicated to in the PFE forwarding to replicate the source original source IP address of the leaf. And, also, if ESI label filtering rule is used, it's hard to maintain the inner ES label after decap and the incap. So so the way it does is in the control plan, you replicate or only need to know who is original AR leaves its mother home the peer. So AR replicator only replicate broadcast multicast traffic to the leaf nodes, which are not mobile home to the original replicate AR leaf. And the leaf will replicate itself using the extended existing procedure to its peer leafs. So this way, you simplify the procedure in the replica trying the assistant rep replicator trying to maintain the source IP address and the ES label. So that's how it works. Oops. Did I? Sorry. Did I skip procedure? Yeah. So the procedure is what's the procedure to realize that the AR replicator actually performing this extended optimized ingress replication is we introduced a flag called AR replicator frag extended multi homing AI replicate frag. And this is will be signaled using the existing community, kind of extended the multi home using the existing community and advertised in the routes attached to the routes. So this way, the leaf knows his replicator will not perform the replication for his motor home, the leaf. And the leaf will do the ingress replication. That's the new introduction. Yeah. And the status of the this draft as has been there for a long time, and now we also have a implementation in the code and used in in a customer network. So it went through the review twice, and I'd like to request for the last call for this draft. Thank you.

[00:40:42] **Matthew Bocci**: Thanks.

[00:40:44] **Jeffrey Zhang**: Indeed, this is on the last call in the last call queue. I am the chef- I will review this and then we'll get on to it. Sasha?

[00:41:02] **Sasha Vainshtein**: I have a question which is only slightly is triggered by this presentation, but not exact but but not not not very specific for it. Assisted replication is used with v s EVPN VXLAN because it needs source IP address of the replicator. It needs source of it relies on source IP address of the packet it receives not to send the packet this packet back. My question is, have any point and I believe this draft does effectively the same just to provide some enhancements for multihoming as described in in in your presentation. My question is and this mechanism clearly is not applicable for EVPN and PLS. My question is, what is supposed to what is are these mechanisms, assisted replication and enhanced assisted replication? Would they be applicable for EVPN over the SRV six overlay? It is not if you can answer that, that's fine. It's probably a question more to the entire wardrobe.

[00:42:24] **Wen Lin**: So if I understand you correctly, your question

[00:42:28] **Sasha Vainshtein**: Can you please speak closer to the mic? I don't hear.

[00:42:32] **Wen Lin**: If you if I understand your question correctly, you are asking whether it's applicable why it's applicable for EVPM POS encapsulation. Is that right? Is your question? Is your question particularly for EVPN and POS?

[00:43:00] **Matthew Bocci**: Can you both use the mic?

[00:43:03] **Sasha Vainshtein**: So I think audio at

[00:43:05] **Matthew Bocci**: the front is really bad.

[00:43:06] **Sasha Vainshtein**: My question was whether assisted application and standards assistance application to which you have presented now. How can they be used with EVPN over the SRV six overlay? Underlay. Sorry. With the s r v six underlay because you still you have source source address identifying the packets as well.

[00:43:39] **Wen Lin**: Yes. It can be extended for SRV six.

[00:43:43] **Sasha Vainshtein**: I think this I think this makes some sense.

[00:43:49] **Wen Lin**: Yeah. Thank thank you.

[00:43:52] **Jeffrey Zhang**: So if the question and answers will be quick, we can we can finish this rounds, but we are losing our time so may we may have to take it to the list.

[00:44:07] **Jorge Rabadan**: Okay. I just wanted to Jorge and Nokia, I just wanted to to make a comment about Sasha's question about SRv6. So actually, when and I are are working on a proposal so we can share that with you, and we were planning to to publish something very soon in a few days. So

[00:44:32] **Himanshu Shah**: very quick question. Why not do the point to multipoint LSPs that already you are sending in the r t three for the broadcast stuff instead of doing the assisted application? But it's probably academic because it is already an RFC. I think your extensions are good, what what you are showing. And other thing that was Shasha was saying is we need to now look at everything with how will it work in SRv6 underlay. Right? Before, it used to be only just SRM PLS. Now we are to have the VPN solution also work for SRv6.

[00:45:19] **Jeffrey Zhang**: Sorry, we'll have to take this to the list.

[00:45:31] **Co-Chair**: Krishna, thank you.

[00:45:48] **Matthew Bocci**: That's unscrewing it.

[00:46:02] **Krishna Swamy**: Hey. Good morning, folks. I'm Krishna Swamy from Cisco. So I have three presentations. You know, I'll be presenting on behalf of my coauthors. We'll start with EVPN first half security. So, you know, this has been a working group adopted draft already and wanted to do a quick recap. So what is the motivation to FHS? Right? So the r on the n d inspection and IP source card. Right? So these require DHCP snooping. Now when a host is multi homed, right, so then the DHCP snooping database needs to be synchronized between the multi homed PEs. So that's the one reason. Then the second one is, you know, when the host moves, then at that point of time, if the DHCP snooping database is not synchronized in the fabric, then that will also break the host mobility. So these are the two main problems that we have to that this particular draft is addressing. K? So I think I already covered it. So this draft introduces a new DHCP sync route. Right? Then it mainly carries the the MAC address, the IP address, and the DHCP, know, the binding state and the least time and the clear time. So yeah. Okay. So this is already working over our draft and in the zero on the on the first version of it, you know, we have updated make changes to editorial and put it into the RFC style. So, yeah, so this draft is already, you know, coauthored by the multiple the vendors. Right? And there are no known technical issues, open. So we would like to, you know, request, for the working group, last call.

[00:48:18] **Matthew Bocci**: Right. Nissan.

[00:48:25] **Jakob Heitz**: It's handled at the ribbon. Just a comment. We're just working. Sasha's working on a

[00:48:32] **Krishna Swamy**: I'm not able to hear you clearly. Can you come closer to the

[00:48:35] **Jakob Heitz**: hear me now?

[00:48:35] **Krishna Swamy**: Yeah. Now it's better.

[00:48:37] **Jakob Heitz**: Okay. Just a note, we are working on a DHCP v six prefix delegation, so maybe there is a way to unify this sync information, not to have too many routes? Just a comment.

[00:48:55] **Krishna Swamy**: Yeah. Sure. Like, you know, maybe I will sync up with you.

[00:49:00] **Jeffrey Zhang**: A quick request that if you believe your draft is ready for last call, please email us and if you don't get a timely reply, acknowledgement from us, ping us again.

[00:49:13] **Krishna Swamy**: Okay. Okay. Yeah. So the unknown macros, so I know this particular draft is also adopted in the working group. So just wanted to do quick recap. Right? So this clarifies the Mac mobile Mac mobility procedures with the unknown macro specifically on the the data center interconnect. Right? So so all it clearly defines the layer two forwarding and added a new text with the symmetric IRB. So this also updates the RFC nine zero one four. Now, you know, this is already been supported by the multiple vendors, and we would also like to ask for a working group option. We don't want to send any email.

[00:50:26] **Himanshu Shah**: K.

[00:50:29] **Matthew Bocci**: Any comments on that one?

[00:50:43] **Jeff Tantsura**: Okay.

[00:50:48] **Krishna Swamy**: Yep. So, you know, there are multiple DF election algorithms already been defined. Alright? The RFC eighty five eighty four defines a new extended community through which the draft election algorithm is being sent. Now, you know, currently, all these the DF election algorithm are trying to solve the problem of a load balancing across the VLANs, right, or the multicast groups. Now what it does not solve today is, you know, flows inside a single VLAN. Right? So none of the existing DF algorithms are solving that. And, you know, there are some algorithms which are specific to layer two multicast also. Right? So what we want to solve as a part of this particular draft is to have a single DF election algorithm for both you, know, multicast and broadcast and unknown unicast, and also to solve the flows within the VLAN to get the load load balancing. Okay. So what is the solution that has been proposed here? Right? A new DF algorithm type called per flow. Right? And there are no new route types or no, you know, other BGP procedures, no need to be modified. And also, is backward compatible. So the way the Perflo DF algorithm works is we don't even need to maintain any kind of a state in both control plane and in the and in the forwarding plane unlike the other DF algorithms, right, that that do demand a forwarding state here. So what we are proposing is, right, when the packet arrives, right, we calculate the hash, right, that could be the existing the hash mechanism. This particular draft right now does not define, what parameters to use to calculate the hash, but only what it demands is, you know, all the, the BEs which are participating in a given ether segment have to have a same fields to calculate the hash. That's one thing. Then it builds, you know, an ordinal list of the piece, whatever being that's how that's what has been defined in '74, '32, and also in '85, '84. Now in the hardware, right, in the forwarding state, right, when the hash is calculated, now you take the modulo of the number of p's which are participating and and, you know, come up with the d f index. And if the d f index represents to that particular PE, then that is that will claim as a d f. So with this, right, it's pretty much simplifies it, covers both the, you know, layer two multicast and also to, you know, the broadcast and unicast. K? So, yeah, the new DF algorithm is what the per flow is being defined and this is going to be carried in the this extended community, which is defined in RFC eighty five eighty four. Okay? What are the main benefits? Right? Better utilization of the multi home piece. Definitely. Right? Then the per floor load distribution. Yep. So the the second version is like, you know, I just uploaded it to the morning. Sorry for that. And it clarifies the motivation very clearly. What are the gaps with the existing, DF, algorithms and, also defines a clear procedure with the per flow DF and also clarifies with an, example. Alright? And also some of the failure scenarios. So I encourage you to, you know, go over the the the second version and yeah. And let me know if you have any comments. Okay. Yeah. This is think I already covered it. So yeah. So with this, right, so, you know, we also request a working group or option call for this one.

[00:55:40] **Jeffrey Zhang**: Send us an email.

[00:55:41] **Krishna Swamy**: Yeah. Send us an email. Okay. Any questions? No? Any questions?

[00:55:50] **Matthew Bocci**: No. Thank you. Okay.

[00:56:10] **Co-Chair**: Yeah. Should be.

[00:56:11] **Jorge Rabadan**: Okay. Morning, everyone. Jorge, Robaba, Nokia. This draft is basically, multicast router state synchronization in EVPN networks, and that is the list of my co authors. This is the short agenda. We're gonna talk about the why or the motivation for this draft, then a little bit of the specification that we are describing in the text and some use cases. Alright. So the reason why we started this draft is the following. We are talking about EVPN overlay multicast here, and there are already some specifications that talk about how to synchronize multi home host membership membership. What that means is if you have eVpn multi homing and you have multicast hosts and they send I g m p or m l d joins and and leave messages, we can synchronize that on an Ethernet segment so that all the members of the Ethernet segment, they have the same multicast state information. Now what we were missing is if instead of a host sending iGMP MLD reports, you have a router that is multi homed and it's a querier or it's a PIM neighbor. In multi homing, there is no way to synchronize the state for that multicast router, and that is the gap that we are trying to address here. So for that, we use some pieces of information in EVPN. The the main one is we are proposing a new route type. We call it the multicast router discovery route, And this route is inspired in the EVPN PIM proxy procedures. So just to to give you some background, the EVPN PIM proxy draft was something that we started, like, many years ago, and it never really took off because, to be honest, I I think we were trying to boil the ocean. So it was addressing basically how to replace PIM into the EVPN broadcast domain with BGP messages. So what we're doing here with this this new proposal is just we take what we really need out of that draft, and we make it specific to the use cases that we need to address. And those are real use cases. So with the MRT route, basically, what we do is on the Ethernet segment, when we discover a multicast router, a querier, or a PIM neighbor, we trigger this route to synchronize the relevant information on the other piece of the Ethernet segment. The other thing that we are doing here is when we trigger this route because we we identify or we discover a PIM neighbor, there is some PIM information that we need to synchronize. And but that that comes into the in the PIM hello options. So for that, because it can actually change depending on the requirements or or the or the implementation of PIM, what we are suggesting here is to use a new sub TLV in the tunnel encapsulation attribute where you can actually encode those PIM hello options. And the final thing is we are also reusing routes type seven and eight. But instead of being triggered by IGMP MLD join and and leave messages, they can be also triggered by PIM join and prune messages. A bit more details about the the new route type. There you go. It's nothing nothing nothing special. It's basically a typical EVPN route with the route distinguisher, Ethernet segment ID, Ethernet tag ID, originator router, and we're also adding here the multicast router information. And we also have some flags that basically we encode in the same way we do it for other route types being used for multicast, like the like the versions. A new flag here is we are indicating whether this is triggered by a querier or by a PIM neighbor. And you also have below that if the this is triggered by a PIM neighbor, then we set the the the p bit. We set it to one. And then we include the PIM hello options of TLV in the tunnel encapsulation attribute. And there we need, basically, the Doctor priority, the gen ID, and the address list. That is the mandatory options that we need to synchronize. Yeah. Let me go to the use cases, which are pretty much the interesting part here. So there are three use cases we are describing in the draft. So the first one is, if you look at the on the left hand side, you have a classic RFC ninety two fifty one deployment where you have a broadcast domain, an EVPN broadcast domain, and you have all active multi homing. And IFC ninety two fifty one talks about the EVPN broadcast domain being a distributed querier for the for all the hosts that are attached. So here, the the delta is that, in this case, we wanna use an external querier, right, that is multi homed. And that's why we use the MRD route here. So if the router is multi home, the queries can go to one of the piece in the Ethernet segment, and we trigger the MRD route, and we can synchronize the courier state in the other piece of the Ethernet segment. The second use case is for the EVPN l three multi homing product draft.

[01:02:23] **Chisheng Li**: That

[01:02:23] **Jorge Rabadan**: draft basically talks about Ethernet segments that are directly terminated on, layer three interfaces. And, in that draft, there are, EVPN procedures to synchronize ARPs and enable discovery states, also IGMP MLD with the routes type seven and eight. The part that is missing is if you have a PIM router that is multi homed. Right? And you also need to synchronize the the PIM neighbor. So that this proposal can actually help in in that situation as well. And the third one is when you have an OISM network, an optimized intercepted multicast network as in RFC ninety six twenty five. That RFC talks about PEGS, so PIM to EVPN gateways, and also talks about transit PEGS, which are basically PIM routers connected to broadcast domains. But it's not it doesn't cover the case where you have a a PIM router multi home in in a into an Ethernet segment. And if that is the case, you also need to synchronize the the the PIM neighbors. And that's pretty much it. Just please have a read and provide any feedback.

[01:03:43] **Mankamana Prasad Mishra**: Cisco, thanks for this draft. I think we really have to sit down and think over what all bare minimum things are needed from PIM to sync. The reason is PIM has huge amount of hello absence. So we have to make a call conscious call. What all information really need to be synced across BGP? What we can live with where operator has to do the config. Otherwise, it may make statements seem very complex.

[01:04:12] **Jorge Rabadan**: I understand. So that's why you may remember on the the proxy draft that, like, the TR priority or the GEN IT was part of the NLRI, and that's why we thought it's actually better to take it out and put it on some optional sub TLV. But, yeah, we should sit down and discuss. Yeah. Thank you.

[01:04:37] **Matthew Bocci**: Yeah. Thanks, Prashad. Cisco Systems. Yeah.

[01:04:42] **Prasad Miriyala**: The Gen ID, particularly, we'll have to discuss already. Okay. Because, you know, that can change when there is a typically, Gen ID does change when there is a process restart or I mean,

[01:04:53] **Ketan Talaulikar**: some implementations at least do that. Right? So do you

[01:04:56] **Prasad Miriyala**: think that that definitely needs to be there? What is the use case for having the Gen ID?

[01:05:07] **Matthew Bocci**: Sorry. We were having trouble, with the audio here.

[01:05:11] **Jorge Rabadan**: I I think the question was, what is the use case for synchronizing the gen ID in PIM?

[01:05:15] **Matthew Bocci**: Yes. Yes. Yes.

[01:05:17] **Jorge Rabadan**: Okay. So the idea is if you don't synchronize the gen ID and you have a failure and you switch back to the the guy that never received the the hello directly, then, basically, it'll detect, like, a change in gen ID, and and that that trigger unnecessary new PIM packets. So that's that's why we thought it was important to to synchronize the Gen ID, but we can discuss offline if if you have some concerns.

[01:05:51] **Matthew Bocci**: Yeah. Yeah. Sure. Thank you.

[01:05:53] **Jorge Rabadan**: Thank you.

[01:06:13] **Matthew Bocci**: Hi, everyone.

[01:06:18] **Chisheng Li**: I'm Chishang Li from China Mobile. I will present the joint work on behalf of my co authors. Next slide, please.

[01:06:26] **Jeffrey Zhang**: You have the slide control.

[01:06:37] **Chisheng Li**: You help me change the slide?

[01:06:42] **Co-Chair**: Can you take it off? I'm gonna do it.

[01:06:44] **Matthew Bocci**: Thank you. You have control.

[01:06:51] **Co-Chair**: But

[01:06:53] **Chisheng Li**: I can't.

[01:07:00] **Jeffrey Zhang**: Okay. We'll take it back and then we'll we'll move the slides for you. Okay.

[01:07:29] **Chisheng Li**: Okay. Quick background. In you may be in a customs customer site can be much homed to several keys over a single Ethernet segment identified by an ESI. Every key attached to the segment originates Ethernet auto discovery route route type one at a two granularities, ES and the EVI. These routes are not just for eligibility. Next slide, please. Why can route get lost? Section 7.1 of, say, seventy four thirty two defines the EAD route. K as the RD, the ESI, and the Ethernet tag ID. The originating PE's address is missing. So when PE one to PE three, all originated EAD routes for the same segment with the same RD, the three routes have identical case. Plain BGP best pass selection treats them as competing pass for a single prefix and keeps exactly one. But these routes are not redundant copies. Each one, although it has a different p, yes, labor and the u a I labor. And those labors are precisely what remote PEs need to build a segment by the state. Next slide, please. That is feeling mode. P one to p three, all originate the ED routes for ESI one towards the route reflector. The r r wrong best pass selection, and the forward only, It's a single best pass to p four. P four add up with the labor and the labor of just one t out of three. What triggers this outcome? IFC seventy four thirty two recommends a unique RDPE, but real deployments don't always follow that and reflect only reflects its best as per NLRI. Next slide, please. First team, impact. Our remote PEE collects the PVI EAD routes from every PEE on the segment and the program ECMG next hope group across them. If two of these results were suppressed, the ECMG sent degrades to a single member. All flows for that EVA are pinned to one p. The other p links carry nothing. And when that ping p fails, we get a hot outage instead of a simple high sift. The all active the operator paid for sanitary degrees to single active. Next slide, please. Second impact, the mass withdrawal mechanism of section 8.2 line are area remote PE holding each PE's PEE as EAD route. While p lost its segment link, it withdraws that route, and the remote p immediately flash all state pointing at eight. But if the route was pressed, the withdraw never reached remote p at all. And if the filling p happened to be the r's best pass, the r just to reflect a new best pass from p four's perspective that looks like an ordinary pass change, not like a p departing the segment. So PE four keeps still next hop hops program, and the black holes traffic until something slower, like micro aging eventually cleans up. Next slide, please. Third impact. When bomb traffic arrived from the call, the key attached to the source segment must recognize the wire, ES labor. That is traffic originated from its own segment and must not be set back into it. That check works well. Only one's ES label set is in the forwarding plan, which is built from received the PS EAD rules. If some p rules were suppressed, their ES labels are missing. For segments with more than two p's, a non DF folder can then fail to identify call originated BAM traffic and reflect it back into the segment, creating loops or duplicates. So suppressing turning into a real data plan correctness problem, not just optimization loss. Next slide, please. The solution is simple. Instead of running best pass selection over routes and keeping only one, a BGP speaker advertise and install all valid routes for a given segment. The draft has three requirements. Section 2.1 scopes eight to two route type one with a nonzero ESI. Section 2.2 covers the control plan, advertise everything, and the route reflectors reflects everything. 2.3 covers the data plan. Install the ES labor and EVAI labor from every originator. No new root type, new key areas, no capability, and and accents. And because the behavior is local to each speaker, it deprised incrementally. Next slide, please. Requirement one is about scope. The multi pass behavior applies exclusively to route type one, the route. And only one ESI is nonzero, meaning the route actually describes a multi home segment. ED routes with a zero ESI and every other route type keep playing RFC forty two seventy one as per selection with no modification. Next slide, please. Recruitment two is the control plan rule, and it has two musts. First, any BGP speaker must advertise all valid EAD rules for giving ESI to its peers. This applies equally to locally originating the rules and to rules learned from other peers. Second, our routes reflect reflect must reflect all valid YAD routes to its client instead of only the best path. Functionally, this is exactly what IFC seventy nine eleven passes for EDRUST does, but we get it without negotiating the EDRUST capability, which keeps deployment simple or existing infrastructure. Next slide, please. Requirement three ties the data plan to the control plan. It's not enough to receive and appropriate all EAD routes. A speaker must also install forwarding state for area concretely. From each ES EAD route, install the originator's ES label. From each EVI EAD route, install the originator's EVI label. The routing forwarding state maps each ESI and the EVI to the full set of originating p address and their neighbors. Next slide, please. Putting it together with our concrete example, Three p's on ESI one. Each originate their PS and the PVI. PVI, 80 routes. Finally, use shared all unique IDs. No longer matters. The route reflect are low. Keeps and reflects all three steps instead of filtering down to one. P four installs the ES and the EVI label or area originator in forwarding. P four load balance across all three PEs and its split horizon and the mass video. So they cover the whole segment. Next slide, please.

[01:15:33] **Matthew Bocci**: Can you try to wrap up, please? Because we've got three people in the queue, and we're gonna run out of time.

[01:15:40] **Chisheng Li**: Okay. Two opponent oppositional points may be skipped. Next slide, please.

[01:15:50] **Keyur Patel**: Next slide.

[01:15:53] **Chisheng Li**: Multiple growth post the log rib and the forwarding plan for EAD routes are misconfigured. All Melissa's peer could pump out large number of EAD routes for the semi SI. The draft, therefore, makes it mandatory for implementation to support a configurable limit on number of tasks accepted at PSI, and access routes should be discussed once the limit is hit. For sensing protection, TCP authentication, TCP AO is recommended. There is no additional requirement from Anna. Next slide, please. To summarize, the problem is ping DGP best has licensed routes and the data slightly and speed speed in deployment. It's crucial to treat and multi pass. Otherwise, tie all all of them, reflect all of them, install all of them. That's all. Question and the discussion are welcome.

[01:17:00] **Co-Chair**: Sasha.

[01:17:01] **Sasha Vainshtein**: Hi, Sasha Weinstein. I must admit that I do not think that the problems this draft tries to address exist, Specifically, seventy four thirty two explicitly states that the route distinguishers are used in when advertising per ASVPN type four event type one Ethernet thousand discovery routes must be type one route distinguishers with the IP addresses that identify the advertising PEs as their global administrator. In some cases, a sequence of such routes must be advertised with the same global administrator and different local administrator parts so that each of the each this is done if they there are too many route targets to be attached to these routes, and you cannot fit the the result in a single BGP update, which means that all the such routes advertised by different fees are always incomparable with from the BGP point of our view and will not be suppressed by any route reflector. In the case of per EDI, ethernet thousand discovery route, the standard says that they must use the route distinguisher assigned to the advertising mock BRAF and recommends that this route distinguisher should be also a type one route distinguisher. So if we follow this rule or a rule, nothing is going to happen. There is there is a per per AS, VPN type one routes cannot disappear due to best pass selection. And if you you follow the recommendation, which a strong recommendation from my point of view, to use type one route distinguishers for MACVRFs, the same well, this will not also happen to per EVI type-one routes. Since if there is no problem, there is no need in a draft to solve it.

[01:19:36] **Jeffrey Zhang**: Yeah, we'll have to move this to the list. But I do recognize that unique Rd per VRF is a must, not a recommendation in the RFC. We'll take it to the list.

[01:19:50] **Chisheng Li**: Okay, Sanko.

[01:19:57] **Jeffrey Zhang**: We have to move on. Sorry.

[01:19:58] **Co-Chair**: Oh, okay. You have to kick him off. Yes.

[01:20:14] **Himanshu Shah**: Yeah. Himansha Shah from Sienna. I'm represent this draft on behalf of all these authors. And we are talking to other service providers, and some of them has joined in this effort. It's a very small incremental change, so I'll go over it quickly. So what is the motivation? Right? This is currently, the reality is that there there is an MPLS network and SRV six is getting installed, getting more popular, and you will have the migration. So during the migration, the way the RFC ninety two fifty two is written is you need to have a dual BGP session in order to accommodate the MPLS based PEs that are existing today, legacy nodes. And the new node that are doing the service six, they will do the use the RFC ninety two fifty two to signal the services. This this causes dual advertisement. So if you have a, let's say, a million route, you will have 2,000,000 routes to advertise. We want to optimize that, and this proposal that we are presenting will reduce the number in half from today, and you will have a and it reduce the control plane overhead and all that stuff. So what is 90 RFC ninety two fifty two? It's a at it is to for service, signaling for SRV six. It uses the SRV six SID in the service signal within the BGP prefix SID, and there are two ways to do that. One is to use the transpositioning, and the other one is to not use the transpositioning. So when you're using transpositioning, it uses the MPLS service label to identify the MPLS service instance. The when you're not using the transpositioning, transpositioning. So TL is the transpositioning length and TO is the transpositioning offset. So if the if the value is zero, then you're not using the transpositioning and you are you using the SRV six prefix seed, the service instance is identified from there. And the overreaching part, unfortunately, is that it makes the MPLS service label as an implicit no, which is which is what we are trying to, optimize. So I think the main I get the main intention to continue to use the MPLS label in the and the transpositioning is not to accommodate both the services I mean, both the underlays, MPLS and the SRV six, but rather for packing when you are using the transpositioning, which I think that that is okay. But I think there was no need to do that, I in our opinion, of course. And and I think with slight optimization that we are offering, you can make do with just one single signaling one set of signaling rather than duplicate. So what are we proposing? So we are actually, extending the capability when you open when you have the BGP session established, you say, okay. We are going to extend this capability. And when both both peers agree, then you are capable of doing this new new actions, a new proposal we are offering, and I will give you some more details. But what we are doing there is we are preserving the MPLS service label. We are not stomping. We are not making it implicit now. It is leaving the MPLS service label. And I think what has also happened is that it was fine for l three VPN. There was service label only in one place. With an EVPN, there are lots of routes, and service labels are all over the place in different r t one to r t five, and so on and so forth. Then there is now FRR reroute, in in the EVPN. All those service labels has to be made implicit now because now you wanna use the s r v six underlay. So we we we we wanna overcome that. And in that process, we also want to, reduce the number of signals that you need to, do in order to accommodate the both side, both underlay, MPLS and SRV six. But now that we are here, the problem is we we need to be backward compatible because there's already deployments. So this capability exchange is a good way to make sure that, yes, we are, both are capable of this new functionality, and, yes, we will do what, is proposed. Otherwise, you just continue. If you're not capable, then, you know, you continue to progress the way it is done now. Yeah. So this is the this is the semantics we will have. By providing this extension, what happens is that now the ingress fees have a choice. If you are working in a dual plane and there is an hybrid network where you have a number underlay, then MPLS, as well as in SRV six, you you decide what you want to use. Sometimes, you you know, many operators, they start with the if you have extended the SRv six next network end to end and you have a reachability, yes, you use the SRv six. If there are some issues, you wanna fall back to MPLS, the MPLS underlay already exist. And this layering thing, it it really has to be the choice. The overlay shouldn't dictate that thou must use this underlay, which is kind of one or the a way of maybe probably an oversight. But okay. With this extension, it will allow the ingress PEs to selectively use either MPLS and SRV six. And as we have seen, there are many because of the CapEx reasons and the hardware capabilities and all that stuff, there will always be some excess networks which would always have an MPLS. They will not change over. There's thousands and thousands of those, so they will continue to use an MPLS and relay. And if that is the case and they need to participate in the same service instance, you you need to then have to advertise the duplicate service signaling. So we are trying to minimize that. Right? So I think I will now I I talked about this. So let me go through this diagram here. Be with the with the as a with the capability we are proposing here, you would start with an egress PE who has the, you know, the dual stack SRMPLS as well as the SR MPLS or any MPLS. They could be LDP. It's just an MPLS based underlay, and you have an SRV six. This with this, we will it will create a a a extend the capability with the route reflector, and if the route reflector has also been updated, now you will have there are a couple of things that route reflector will have to do. First of all, route reflector has three would have three types of other route reflector clients. One is a regular, route reflector client, which has, the v six session. The other one is, another route reflector client, which is a v six b g p v six peer, but has also exchanged this capability and knows about this extensions. And the the third one is the legacy PEs who are still doing the MPLS v four. So that so in in order to talk to all these different clients, the way it will you do is that it will have the service label. So in the first case where it is just the b g p v six and SRV six, a node that are that exist today without this capability, it will set the service label to implicit null because that is what is required by the ninety two fifty two. If it is if it's the newer ones with this capability, it doesn't have to do anything. And if it's an IP v four client, then the next hop, which was originally an IP extended IP v six extended v four, we'll have to then use the IP extract the IP v four and use that as the next hop. So it will maintain all types of Could you speed up? Session. We're running out of time. Okay. Hurry up. This is this is how we see it. The phase phase zero would be you have an SRMPLS networks. Everybody is doing v four. In the phase two, you are upgrading, and you're starting to roll out the SRV six underlay. Phase three and four, you have this with the newer capability, and, you know, you can go with this thing. So as long as you have an SR which is as the reachability has exist has spanned, you you go ahead and use the SRv six, and you give a give a choice. The main point here is that the legacy nodes that are doing the SRMPLS has not been changed at all. Okay. They are completely unaffected. So, yeah, this is a zero zero version. And yes. Go ahead.

[01:31:22] **Jeffrey Zhang**: Please make if it's quick, we can do it. Otherwise, let's move it to the late minutes. We are really behind that our schedule.

[01:31:30] **Matthew Bocci**: Yeah. I already lost the queue after three.

[01:31:33] **Jorge Rabadan**: Okay. I'll try to be quick. Jorge Rodan. Thanks for the presentation. I have, well, three quick comments. First one, you you say that RFC-ninety two-fifty two is ambiguous, but I disagree with that. So and if you think so, we should probably fill a ruta. The second So comment

[01:31:54] **Himanshu Shah**: so hang on there. RFC-ninety two-fifty two does change the service level to implicit now.

[01:32:01] **Jorge Rabadan**: Yeah. But it's clearly stated. Right? So it's not ambiguous. So it's it's specifying how to do it. So, anyway, the second comment is you you say that you you do this to decrease the the control plane overhead. But by doing this, you disallow transposition, so you're increasing the control plane overhead. So it's it's kind of defeats the purpose

[01:32:26] **Himanshu Shah**: in the first place. Sorry. Can you repeat? Because there is some actions going on in the back.

[01:32:31] **Jorge Rabadan**: Okay. Just focus. Yeah. Now I'm saying that one of the motivations is to improve the control plane overhead by combining Yeah.

[01:32:42] **Himanshu Shah**: Yeah. Reducing the control plane overhead by not maintaining two sessions. So

[01:32:46] **Jorge Rabadan**: my point is by doing this, you disallow transposition, which is basically there to decrease the control plane

[01:32:55] **Himanshu Shah**: Not necessarily true. You've you can use the MPLS label as a part of the service sig s r v six service sig. You just the way it is done for transpositioning today.

[01:33:07] **Jeffrey Zhang**: Sorry. We have to move on. Okay.

[01:33:09] **Jorge Rabadan**: Alright.

[01:33:09] **Jeffrey Zhang**: I'll stop here.

[01:33:11] **Jorge Rabadan**: Okay. I have more comments. We can discuss on that.

[01:33:13] **Jakob Heitz**: Yeah. I'll do quickly. Jacob Horn, Cisco. I agree with Nokia that you are killing transposition. So in a control plane, you're actually increasing the because you're losing BGP update packing entirely. That's one part. And IPv4 and IPv6 Next hop is an issue for the IPv6, IPv6 migration summarization, and you will have to change that. You also have to change the BGP session from v four transport to v six transport, and you have to do it do it on the path. So there is additional unnecessary interruption during the migration, so I cannot I don't see the point here.

[01:33:53] **Sasha Vainshtein**: Sasha Weinstein. Also think this is a very interesting draft. Thank you for the presentation. But I think that there are some VPN specific things here. For instance, suppose that you want to use assisted ingress replication for your in your service six network. So your advertise this in the PSMSI attribute of your type three route. When this happens, such a route cannot be used for MPLS purposes because MPLS doesn't support assisted ingress amplification. On the alternatively, if you want to use some point to multipoint technology, like point to multipoint MLDP for delivery of bomb traffic over MPLS, what are you going to do about that with the service six? So there are some there are things that are incompatible between MPLS overlay and they are not incompatible. You can use one in one place, another one in another place, but if you advertise everything in a thing route, it doesn't It will not work.

[01:35:09] **Jeffrey Zhang**: I I We have to stop now. That's we we are really behind schedule. Let's take it to the list. Thank you.

[01:35:16] **Himanshu Shah**: Okay. It's a non point. So I'm sorry. I can't respond. We'll talk, Sascha.

[01:35:35] **Jakob Heitz**: Thank you. Jacob Jacob Horn, Cisco Systems. This is this is describing the draft, which is, which is adopted already a while ago in s r v six ops, and, the draft focuses on the migration from any technology, basically basically, to to MPLS. So here, behalf of. So the I have basically three reason to be here. One reason is really to share with the best how the customers are migrating from MPLS to SRv6, and these these methods are used widely across most of the most of the s r v six s r v six service providers. Obviously, get the feedback from from the BES and also ask for the BES about applicability of the same or similar migration procedures for the VXLAN VXLAN environment. So this is this is typical typical model of any MPLS network. I'm running some underlay protocol, which here is described as an IGP. Whatever IGP it is, it's applicable if even if the underlay protocol is BGP BGP BGP in there. Sync LDP for label distribution, again, LDP doesn't have to be there per se. Any lay any way of distributing labels, so it's applicable for segment routing segment routing MPLS networks networks as well. So I have three PEs, first PE, second PE, and last PE. And I have one PE as a model and one single route reflector, but applicable for network of any size. So first step or basically preparation sorry. Preparation part is just to enable I p v six routing. You have to entirely enable I p v six routing across the network. You have to enable v six loopbacks to allow the control plane and to verify the routing. And, again, underlay routing can be anything. Second step is to add v six route reflectors. So you need a new set of v six route reflectors. And if I'm say saying v six route reflectors, I mean, this is about the transport address family. It's not what is what is the service address family. So it it it is applicable for all the services. There's three VPN, v four v six, EVPN, basically any any or any any any address family. So this is preparation, and so far, we haven't touched anything anything. Everything is still running over over MPLS. And there is a d day, and you have to start migration of the first two PE. And right now, what are you what are you gonna do? You enable locator on those two PEs, and you may enable dual PE dual PE functionality on those PEs. From that moment on, in every verb where where where it's configured, the PE start advertisement of all the prefixes over over both over both the the route reflector towards the both route reflector sessions. Towards the first route reflector, which is v four, the service prefix is sent with the label. Same center same prefix, same route distribution, same route target, everything is identical. Only forwarding construct is the label. For towards the v six route reflector, everything, same prefixes are sent with the same route target, same route distinguisher, identical prefix, only forwarding construct is the SIT. Ingress PE has to select, And beauty of this selection, it just follows simple BGP best pass selection algorithm. So based on the local preference, it will select either prefix with the label or with the SITs. So initial initial state is set to local preference or for that matter, any BGP BGP attribute for something lower. So here, we have local preference 50, which is lower than default 100, and the ingress PE is not importing or not putting into the forwarding any any prefixes with the SIT. So right now, we migrated control plane on those two PEs, but the data plane is still running over over MPLS. And if you wanna do real migration or, like, the next step, real data plane migration, you just change the local preference to something better than over the MPLS. And this offers Van der for granularity because you can do it per individual prefix. You can do it per address family. You can do it per verf. You can do it whatever way you like. And the ingress PE just seamlessly without losing the single packet, just reprogram the hardware and start forward start forwarding towards the towards the particular particular prefix over over s r s r v six data plane. Super seamless, super straightforward migration, super granular without moving, without losing any any traffic, and it can be done even during during the the during the live traffic. This way, most of the service provider move to automation, and they are automatic they control using the control plane orchestrator, they are just changing the local preference prefix by prefix or a VPN, VPN by VPN. This way, you migrate PE after PE. On one day, you have last PE migrated. All the traffic within the network is running over s r v six, And last step missing is just to remove all the I p v four forwarding. So this is the method typically used. It's described in a s r v six ops deployment deployment draft, and it's really seamless, really straightforward, and really, really granular. I said that there is really zero packet loss, so it can be really done, well, even during during the live live traffic. There is no hardware scalability issue because each prefix is installed in the hardware just once. And, obviously, there we are using the control plane, which basically doubles amount over the route reflectors. But on the PE, everything everything is the same. Only thing which only thing here which might be, like, cumbersome is the you need to migrate everything to s r v six before you remove start removing s r MPLS and MPLS in general. So there are different methods if you need to have part of the network s r v six only and part of the network is still just MPLS because of some hardware comp compatibility. So the the first thing which still concerns the best is the s r v six two MPLS gateway. That's that's applicable for layer three or layer two scenarios, which is basically reoriginating prefixes on the gateway, possible migration scenarios. And there is a there are two more scenarios if some middle network is SRV six and the edges are running just only MPLS. We are using m over m over six, which is described in a in a spring draft for MPLS interworking. And if it's other way around, so Middle East MPLS and SRV six edges, you can use six PE or for that matter, even six VPE or any any IPV six transport. So that's it for me. We are looking for opinions, comments, whatever. And, obviously, we are desperately interested on applicability of the same process or some methods for the VXLAN. Thank you.

[01:43:59] **Matthew Bocci**: Jorge. Sorry. Can you can you stand on we should have mentioned. Can you stand on the x?

[01:44:03] **Co-Chair**: Sorry. Yes.

[01:44:04] **Matthew Bocci**: For the camera.

[01:44:06] **Jorge Rabadan**: Yeah. Thanks thanks for the presentation. The the example that you you presented is super clear, so it would be great if you you can actually put it like that in the draft. I don't remember being an an example that clear. And my my second comment is that I sent an email to the list saying that here we've been working in a in a bunch of documents about service gateways and the specifications. It would be nice if you can, in in the draft, you can refer to the documents that we we have here in Bess, because they they deal with redundancy of the gateways, how you propagate properties of the routes, and stuff like that. So it would be nice to to add them.

[01:44:50] **Jakob Heitz**: Thank you. Yes. We will do that. Thank you.

[01:44:55] **Jeffrey Zhang**: Sorry, we're running out of time. Let's move it to the list.

[01:44:59] **Jakob Heitz**: We can discuss anything offline. I'm happy happy to discuss offline.

[01:45:08] **Jeff Tantsura**: Everyone, on behalf of my co author, Keaton, I would like to present a proposal to carve small space for experimental cases with new route types. Next slide, please. Oh, I'm in church. So, basically, the problem statement, there's no room for experiment. The current policy is actually required, so we can only get new route type being in very advanced state, which usually takes years. Right? So when we develop new staff with quad points, and it's not good being good ATF cities and to squad points. So we would like to have a space that allows for experimentation and potentially interoperability testing between number of vendors. This is nothing new. The RFC eighty one twenty six clearly defines what experimental use ion allocation policy is, and the idea is merely to apply this procedure to new route types. So the proposal is to update seventy four thirty two and allocate small block of values, in this case, 32, to be able to use them as experimental. So, basically, what it allows to do is do faster iterations, and congratulations to all of us. The year is the year of v v p n and data center. It's going everywhere. There's a lot of innovation, and people are really locked, and I see the issues, like, with my eyes. Right? So it allows clean space to iterate, to experiment, and it's a common proximity. Right? 8126 is very clear here. So it's asked to the working group is to review, confirm if you're happy with the block, quickly iterate on it. And looking at Unicast, we have ability to define new Sify on first in first. And here, we have no ability. No one will do new Sify under a VPN IP. Right? So new route type is pretty much the only way to develop new intentions.

[01:47:32] **Jorge Rabadan**: Thanks, Jeff- What are your thoughts about what is the RAW reflector going to do if it is not upgraded and it doesn't understand this? Because so years ago, we tried something, in this working group. We defined, route type two fifty five, and our concern was the route reflector. So if you don't upgrade the route reflector, even if you do, if the route reflector receives this experimental route type, it knows nothing about it. It doesn't even know what the key is and the length and and all that. So it doesn't know if the route is valid itself. Right? So at the time we defined this vendor specific, instead of call it just experimental, we said, okay, let's call it vendor specific and define just a minimum, like, length key so that at least the route reflector can compare routes and and do proper validation, at least a minimum one. Right? So what are your thoughts about using just that this experimental range and and non upgraded raw reflectors and and all those things?

[01:48:40] **Jeff Tantsura**: So upgradability, usually, it's local matter. You could have support for both and choose one you receive. We can describe some of these cases. We work through them practically. It's a valid point, and there are two parts to it. One is actually ability to do this without squatting, which is important. I think we are all good ATF citizens. Another one, how do you proceed from experimental cut point to production one when you get close to the RFC? And if you feel there's a need for that, we can describe number of ways to do this in the draft. And if you want to participate in this, obviously, this is proposal for the working group, and we'll be happy to take any inputs.

[01:49:21] **Jorge Rabadan**: That'd be great.

[01:49:21] **Jeff Tantsura**: Thank you. Thank you.

[01:49:23] **Jeff Haas**: Hi, Jeff. Jeff- In addition to what Jorge is mentioning in terms of how do you make sure it goes through the reflectors, there's a huge pile of, you security headaches that this stuff is, you know, piling on. Minimally, the document has to talk about, you know, how this stuff is explicitly enabled and only explicitly enabled so it doesn't, you know, get out of anywhere. Clearly, with e v EVPN, it's not gonna go anywhere. You don't negotiate EVPN. But if you turn this on in a deployment and you don't have something to limit the blast radius, given how EVPN works today and how it might work with the more generic feature, this thing leaks out and potentially collides with different versions of the experiment code point, and your network just blows up. So I would recommend minimally capability negotiating this. And the second thing I'd recommend is, as part of that, maybe consider putting some sort of versioning information into that capability so that you know which flavor of the experiment you're running at a given time.

[01:50:24] **Jeff Tantsura**: All valid points, I don't think it's recommended to go into wide production with experimental code points. So practically, at some point, you need to go into something that's unallocated. Right? Again, all valid points, and it's really complex topic. Otherwise, we wouldn't be discussing it here. Ketan.

[01:50:45] **Ketan Talaulikar**: Yeah. Ketan Talauli, Francisco. As an individual and coauthor of this draft, as Jeff mentioned, the only motivation here is to have a range for experimentation. This is not for deployment, and this is to avoid any possible challenges or squatting of code points. And that's about it. All other points, feedback, are all valid. It's for the working group to decide. This is only trying to get space for experimental, not for deployment.

[01:51:21] **Jeff Tantsura**: Yeah. So we'd like to keep scope as small as possible and simple as possible. Really, I built the experiment without breaking being good ITF citizen.

[01:51:32] **Matthew Bocci**: K. K. Just very quick.

[01:51:34] **Keyur Patel**: Real quick. K. Patel, Arkas. Echoing everything that Jorge said as well as Jeff said. Sounds sure. If you're going to an experimental usage, then you probably wanna make sure this draft has very tight guidelines as to what an implementer should implementer should be doing as you start to deploy this in deployment. Meaning, really don't pass this kind of NLRIs in the real life deployment. Absolutely.

[01:52:02] **Jeff Tantsura**: Thank you. And we'll be following guidance of 81

[01:52:04] **Matthew Bocci**: Sasha Sasha, sorry. The the the

[01:52:08] **Jeff Tantsura**: Of eighty one forty two to exactly describe the behavior needed here. And please do comment. We are looking for working group inputs to incorporate. Thank you.

[01:52:19] **Chisheng Li**: Our

[01:52:20] **Jeffrey Zhang**: next slide, our presenter is remote. Mosheko, can you can you join and unmute yourself?

[01:52:29] **Moshiko Nayman**: Yeah. Can you hear me? Yes. Wonderful. Thank you for your time, guys. Me see the slides.

[01:52:40] **Jeffrey Zhang**: Okay. We'll move the slides for you. A quick background. This draft was formed in IDR, and we now need to consider if it needs to be adopted here in the BESS working group. So if we run a little bit late, appreciate you could stay a little longer. Go ahead.

[01:53:03] **Moshiko Nayman**: Thank you. So, yeah, this is a this draft, I'm coauthor with Christophe and Israel from AT and T. There was a need for compartmentalized network or break into smaller segments break the network and split the network, sorry, into smaller segments without changing the network design into different AS number. Yeah. Thank you for the next slide. And we wanted to preserve a large scale service provider network as the same AS while splitting route reflector and put it in different islands. So instead of ASBR, we call that domain border controller sorry. Domain border router because, again, it's used the same AS number. So because it's also IVGP to IVGP, we needed to set the next stop self in some scenario, which is something automatically happened on the inter AS VPN. So these are the, I would say, the main delta. It basically deliver to the service provider similar as the inter AS, but but without changing AS numbers. Obviously, the AS passed and preserved, it's the same one flat AS. And not much changes. There is no need for at least for for us and Juniper, we didn't need any change in software. There's nothing new in terms of BGP itself. It's just we tried to standardize and and document it publicly on how to do that safely. And like I said, this is already deployed for the last two years in several locations around the world using this

[01:55:18] **Jeff Tantsura**: technique.

[01:55:22] **Moshiko Nayman**: I I I just try to run fast as possible. Let me know if if there's any question. Some of them, we were addressed on the email groups, which you can move to the next one. So, yeah, like I said, the in the next stop self here is, I would say, possible. Depends on the type whether it's option a, b, and or c. And in the cases that we deployed it in the large scale service provider, they wanted, like I said, to compartmentalize the network. So domain one is not aware of all routes in domain two. It's the DBRs, the border router that ties to each other and the specific and selective routes, which is why in some scenarios, the next upsell the next upsell, I'm sorry, is required. We we did in tested a option a and b. Sorry. Deployed option a and b when option c was already deployed that way in production. Right. And, yeah, this is just a comparison or for every option and the behavior and what changed. And yeah. I mean, Jeffrey, I will maybe ask for questions because I would say that we don't really change anything in BGP or we don't suggest any change in BGP. Yeah.

[01:57:19] **Matthew Bocci**: K. K.

[01:57:20] **Keyur Patel**: Yeah. Real quick. RKIS. Hey. It would be good to for you to, a, present in IDR. B, really, I haven't looked at the draft. I will. But this sort of becomes little complicated with different topologies, and I'd be interested in seeing how you bind the topologies or restrict them so as to prevent the loops occurring. I don't think cluster ID using a single global cluster ID is good enough, but would love to know what those topologies are. Thank you.

[01:57:49] **Moshiko Nayman**: Yes. Yes. Those three scenarios described in a a draft, and it's a single cluster ID on each domain to prevent those loops.

[01:58:01] **Jeff Haas**: Hi, This is for mostly for the room. So IDR already has an adopted document for doing, you know, next top self at reflectors. So the BGP piece of the procedure is already an adopted component. Part of the reason this is being pitched towards Bess is that with that component being handled in IVR, that leaves the core of the scenario back to the VPN, you know, use cases. So as, you know, presenters here are giving, this is primarily a VPN feature. It just works. It might even be informational depending on exactly what the perspective of this working group goes. And the normative piece is mostly handled in IDR at the moment. So maybe that helps the group make decisions.

[01:58:55] **Speaker 3**: Yeah. Gunther from the here. I don't the routing ID here. So the way I look into this, so this work kind of, like, sits between IDR and Bess, you know, from the content there. So it mainly speaks about, like, the inter, you know, the inter ES options, the a, b's, and c's, and about all of those wonderful little things. And as mentioned, you know, during the presentation itself, you know, it doesn't really represent, like, any new office office and so onwards, But it actually it does characterize the work as deployment guidance for, you know, for a single AS and multi IGP domain. And, you know, when look so coming back to the, you know, what you were saying, Jeff, here. When you look in the in the current charter, itself, it sort of says that IDR will normally not publish, you know, documents focused on use cases, frameworks, and architectural definitions. So that, I think, makes the position that this, you know, fits into the ideal working group, you know, a little bit less less strong as makes it a bit weaker. So it is something to consider.

[02:00:13] **Sasha Vainshtein**: Yeah. So mhmm.

[02:00:17] **Jeffrey Zhang**: I okay. So I think we are done with the presentation and the discussion. So are we all good with the this information now, and then we can make continue or follow-up on the maintenance and to decide where this belongs.

[02:00:36] **Matthew Bocci**: Yep. Thank you. Yeah. Justin?

[02:00:44] **Ketan Talaulikar**: I just want to point out that this document was, has been around for two and a half years now. It went through, you know, got into IDR working group option. So I would request that, the best chairs if if the working group is interested, consider doing it in a expedited manner to be fair to the people that are presenting this work. Just a request.

[02:01:17] **Jeffrey Zhang**: Sure. That makes sense.

[02:01:23] **Matthew Bocci**: Okay. Finished just on time. Thanks. Thank you very much. Thank you. And see hopefully see you in San Francisco. Yeah. Yeah. We filled out. I think next time, we need to give people a deadline for the slides.

[02:01:51] **Sasha Vainshtein**: We need tell them to

[02:01:52] **Matthew Bocci**: try out because it was chaos last night.

[02:01:54] **Co-Chair**: I'm trying to

[02:01:55] **Matthew Bocci**: get everything done and open up the slides.