Session Date/Time: 20 Jul 2026 09:30
[00:00:05] Jeff Haas: I'm trying to get something done about it. And that was also the day of PFD. So here I am, you know,
[00:00:26] Prasad Miriyala: I think my first one was a new. Okay. Okay.
[00:00:33] Jeff Haas: We're gonna get started. Welcome to b f d. First time we've met in a little while. Please sign in to the blue sheets, know and such that they are so that we can meet maybe again in, you four or five years if there's need to.
[00:00:49] Reshad Rahman: I'm Jeff. Have a shot over here. Yeah. Just in case you forgot, it's been a while.
[00:00:53] Jeff Haas: It's been a while. You haven't seen our faces very much. So since we last met, we did meet in Singapore as the last in person meeting. We do keep the status on the Wiki. You know, probably the most exciting thing that's happened since then is that we've rechartered and that we finished all lingering work. You know? So at this point, we have discussed what do we actually do about this. One option is that we simply shut down. One of the recurring conversations over the so called short life of the working group that Alex Zinin promised me would be three sessions twenty years ago is that on top of, you know, the periodic, you things we actually do in b f d, you know, we end up being the consulting group for the IETf for all uses of b f d. And, you know, I think there is about a 150% more documents outside of b f d touching the technologies than inside the working group. So we're gonna call that a good measure of success. One thing that will make this an interesting conversation is as we're working our way through the various AI, you data center type stuff and AI networking, Congestion protocols are going to overlap with what b f d does. So be interesting to see if this is work that, you lives somewhere else, maybe in the new fan working group, or do they decide that some of it maybe goes to existing b f d expertise? In terms of new work, we are taking several of our documents to full Internet standard, and this is mostly what we're gonna be talking about today. And, you know, in terms of work that we have finished, you know, since we last met, now we have unsolicited b f d and unaffiliate b f d echo, b f d for large packets, b f d stability, optimization, and the meticulous auth stuff that lets us do stronger crypto for when it's, you necessary. We've set the stage for all this sort of thing. This was a very bumpy ride through the security ADs in particular because, you know, this was a challenging mechanism to write. We had to take basically something that was, you know, better than nothing. But if you talk to security people about better than nothing, they start making very unhappy faces. In terms of, you know, work happening outside of the b f d working group, you know, we got extensions for VXLAN, you know, MPLS extensions, VPN fast failover for multicast, know some PIM support, and know some of the work that we have includes things like support for Geneve, point to point LSPs, and RFC for b f d strict mode. One of the things to mention here is that we do have you as part of fifty eight eighty two, this is the RFC that's been the generic advice on how to implement b f d for various protocols. And back in the day, that we thought it was pretty straightforward. What we have actually discovered since then, both in, you know, OSPF and BGP, is that vendors, making their choices about when VFT procedures apply causes interrupt problems. So there's been work to do VFT strict mode for both of these protocols. As mentioned, the o s p f one is done. The BGP one is hopefully gonna be done very, very soon, but the main consideration is that we have overlapping state machines. For the most part, fifty eight eighty two is very useful in the sense of when the session goes down, kill the thing right away, and now that's been very successful. The main headache that we have is when do you actually start this? And more importantly, if you prevent one state machine from getting started versus the other, the ordering does matter. As long as it's consistent, it's been fine. So one of the things that we're gonna ask the working group to take a look at as part of the fifty eight eighty two work as we're gonna be discussing is do we need to do some maintenance on the procedures, you know, to be more, you know, better advice about how do we actually coordinate these things. Terms of, you know, what we're here largely to talk about today, you know, ITF has a, you know, at the moment, two level standards track. We largely don't do, you movement to full standard even though we have things that have the level of maturity for it. And as part of, you know, this, we've decided to try to help wrap up a few items, you know, get some of the RADA folded in, and actually get the stuff, you know, published as a full standard. You know, one part is that it's you know, very happy thing in terms of, you know, maturity of the protocol, But it also means that all these minor implementation things have been rolled up and, you know, if we do end up shutting the working group down, one of our tasks effectively is to try to get as much of the wisdom that we have, you know, embedded into the document series for the future as we can because, you know, I personally want to retire at some point. So we want to make sure that whoever the next person is actually understands what's going on. Thankfully, the the work for b f d to do this stuff is very small. The twenty twenty six procedures basically say that we have to take care of outstanding errata, which are very small. We need two implementations, of which we have more than two, plenty. Where things become interesting is its per feature. So if we have unused features, which we'll be talking about, over the course of the next couple of sessions, those should be removed. And once we've actually rolled everything up and have a BIS document and have implementation reports, you know, if we've decided that what we have is complete, now we can just simply advance, though. That's what we're talking about the next couple of presentations. Pause here to give us a moment for agenda bashing if there's any need to.
[00:06:53] Reshad Rahman: So I have a question. Maybe, Katan, you know so in cases where features have one implementation, I mean, if there's none, it's easy. If there's 10, like most b f d stuff, it's easy. If there's only one, do we remove it from the from the full standard?
[00:07:15] Ketan Talaulikar: I don't know the answer to that. I'll get back on it. It's I yeah. I'll get back on.
[00:07:29] Reshad Rahman: It's me first. Right? Thank you. So I am not Alvaro. Alvaro is on a plane right now, so I'm presenting on his behalf. So Alvaro is, taking care of 5880bis and 5881bis. So it was, five eight eight zero, which is the base document, was published long time ago. It's been updated by many RFCs. All the other b f d RFCs, like five eight eight one, five eight eight three, and all that, have normative references to this one. And there's a few errata, which I think I'll talk about later in the slides, which have been verified and held for document update. So the objective is to change this to full Internet standard, and that's a the last paragraph there is basically a copy paste from yeah. It's it's you know, the criteria is it should have no significant changes with respect to the base doc, no outstanding errata, no unused features, and as Jeff said earlier, and two independent interoperating implementations with widespread deployment and successful operational experience. The good thing about b f d is that, well, it's used everywhere. The current status of the zero one. So the first, rev zero was basically a a copy of five, eight eight zero. References have been updated, using XML v three. There's an implement implementation status section which have been added. Those errata mentioned here have been incorporated in the document. So following the guidance of seventy nine four 42 implementation, you know, we need implementation status section. Three reports have been received so far. Alvaro, he sent email to the working group. There's those three ways. I think he prefers PR. I think that's what he said. But, you know, those three ways are good. That's how you can send information report. I know there's people working for different people here, so it's very important that, you know, we get those implementation reports to be able to advance the document.
[00:09:56] Matthew Bocci: Sorry. Matthew, Is there a time frame that you need the implementation reports by?
[00:10:03] Jeff Haas: Yeah. So we're looking for if things are going at the current pace, we're hoping to have this actually on the way towards last call before the upcoming IETF next, you know, next IETF. If we can do that, you know, that's sort of your deadline to set up, in terms of the implementation report. The way it's likely to manifest is that it's just something gonna go into the draft. It serves, you know, to be advised to ISG, and it's gonna get dropped out from the RFC editor. What I've been telling people in different channels is that you know, you're a major implementation, this is a good thing for you to get listed into minimally for marketing purposes. But we were we really are looking for the technical end of things. Sooner is better than later.
[00:10:44] Matthew Bocci: Okay. And I I guess, sorry, follow on question. I think you've already answered it. Is is there any plan to preserve those implementation reports beyond dropping off the draft? Are they gonna go in a wiki or something like
[00:10:54] Jeff Haas: They absolutely they absolutely can go on the wiki. Whether or not they get preserved into the RFC is going to be partially up to the ISG. K.
[00:11:06] Reshad Rahman: Yep. So that's the three ways to provide information. The next steps is, you know, review incorporate implementation reports. So, again, please send those. Update IANA consideration section. I believe Amanda from IANA has been sending emails around for the various docs, so that has to be updated, and then address the reports which are HfDU and editorial changes, if any.
[00:11:34] Jeff Haas: So I I think there's two points to highlight here for 5880 specifically. The first one being, you know, the demand mode. You know, it's the slide before it said, well, it says only one implementation. Technically, it's three because Cisco has support for, you know, this in all three of their stacks. We need very sure to pull the people supplying the implementation report. Is this from three distinct code bases? And from, I believe, the 2026 perspective, that's good enough. Now, clearly, the ISG will have opinions about these things, and we'll see how that goes. So if it's the case, for example, Matthew, that, you know, Nokia's implementation supports no demand mode, that will be particularly interesting to us as one of the options. The second thing to discuss, and we'll get into this a little bit more heavily when we talk about fifty eight eighty four, you for MPLS, is that we have had traditionally across IESG review. Feel feel free to sit down it unless you wanna make it standing. The headache that we've always had for b f d talking to the ISG has always been three things. Thing number one is the transport people get freaked out by how fast b f d is and want to make sure that we're regulated. Clearly, history has shown we've done a good enough job there. But this does come up every single time we take a document to the ISG and they look at it fresh. Second piece is also security. We have thankfully gone through, you three security related documents with this IESG, so this is very fresh in their head. And I think that we've actually done our diligence to address that as much as we can. The one open point that I think oh, did you wanna speak at this point?
[00:13:21] Ketan Talaulikar: That was the last ISG. One sec AD has there's been one change.
[00:13:27] Jeff Haas: That's true. We got Chris instead. Okay. Well, that means we get training wheels yet again. But the the the last piece that I think is a point for this, you know, working group to spend some energy on, and I think the place we're gonna have most of our interactions, is operational considerations. Now we have, these days, an r f c fifty seven zero six bis, which is trying to actually update what IETf as a whole does about operational considerations. B f d, across the entire document series, is very weak about this stuff. And, you know, in some of the extension documents we've had, you know, as we tell them, it's like, this is just an extension document. Please, you stop trying to change, you the base history of things. Now is the time for us to document those sorts of things if we need to. The advice that we've generally gotten from is that, you know, we should go for minimal changes if we can. But, this is a place that there is a little bit of room for, you know, growth if we, you know, find the need for it and very likely a place that will get pushed back from, you know, ops reviewers. So at the moment, there is no specific task here, but, please take a look at the documents within that light and see if you have thoughts. Jeff.
[00:14:46] Jeffrey Zhang: Jeff, on NVIDIA, could you please provide, like, Wikispace or something to publish the reports? Because I'm using the FRR, and there could be variety of different people publishing for open source steps. So would be very useful to see what's already been published here.
[00:15:02] Jeff Haas: It's in the draft itself. Oh, okay. Yep. Attached to the appendix. We were using a you know, one of the formats specified by RFC. Thank you.
[00:15:16] Ketan Talaulikar: Okay. So this is about the operational considerations part. And since this is move it's not just a base, but we are moving it to Internet standard, which means that everything in there has been matured and deployed and, you know, that's the spirit. So whatever goes in the in that document as operational constraints should also be at that level. The other option is that if the working group has interest and appetite to write a separate informational or DCP, whatever is appropriate document as operational considerations for b f d. Invite feedback from this working group, from ops working group, and see how that goes. It serves the purpose, but it doesn't necessarily hold back this work. Again, this is just a suggestion. Nobody can mandate that work to be done by the working group. It's up to the working group to decide.
[00:16:19] Jeff Haas: Okay. Well, we'll see if that actually holds up through ISG review itself. We know how this often goes.
[00:16:27] Ketan Talaulikar: That would depend on when this comes before the IS. That is a different work that's happening, and I think everybody should be aware of fifty seven zero seven. 66. 6. Yeah. Yep.
[00:16:44] Jeff Haas: Jeff, you're still in queue. Did you have anything else?
[00:16:45] Ketan Talaulikar: No. Okay.
[00:16:48] Jeff Haas: Next. And yeah. K. We'll move on to the next slide. Take away.
[00:16:58] Greg Mirsky: One.
[00:17:02] Prasad Miriyala: Sure.
[00:17:05] Reshad Rahman: Oh, so same. This is 5881BS, and I'm representing Alvaro. So 5881 was b F d for I p v 4 and I p v six single hop. Again, published in 2010, verified the Rata exist. There's bunch of normative references on this one, and that last paragraph, again, is is a copy from the previous one. It's, you know, two independent interoperating implementations, widespread deployment, successful operational experience, which, as far as I know, should not be an issue for most of the features of this document. That two similar things. So zero zero was a copy of five, eight eight one, and this is updated references, x m l v x m l v three formatting, implementation status report, and and the errata errata. So this one, we've had no reports yet. It's obviously an issue. We'll keep, sending email to remind people. We know this takes time, but this is something which is, again, widely used. And, I mean, we we know there's multiple implementations can deploy. And, again, Alvaro prefers GitHub, but all three are good. That too similar as as the previous one. Incorporate the implementation of the reports, none received yet. Update IANA. Amanda sent an email for this document too, and any editorial changes deemed as needed. And this is it.
[00:18:53] Jeff Haas: Okay. Any questions here or online? Okay. We'll just keep officially moving through these steps. The there should be on the chair slides if you're looking for the Wiki link. It's part of the IATf wiki, you know, portions. I have your clicker in a second.
[00:19:23] Xiaomin Hu: Hello, everyone. I'm Xiaomi from ZTE.
[00:19:26] Jeff Haas: Great.
[00:19:29] Xiaomin Hu: So then this presentation is about, I would say, 58, 82 bits, just like in the previous two. This overview of this draft, as Richard has already mentioned, the intention is to republish this draft as a Internet standard. And this I've seen it describes the generic application of PFD protocols. Compared to the published RFC, in the base document, the changes accrued six points. Number one, mandate errata. There are four verified editorial ones. All the four have been incorporated in the this draft. Number two, this draft added section 12, IANA sec considerations. This document has no IANA actions. But to make it complete, I added this new section, IANA considerations. Number three, this draft added a section 13 implementation status. Till now, there's only one report from on this this one, implementation implementation report. Number four, I added section 14 acknowledgements to acknowledge the guidance from the walking chairs and our AD on this work. Number five, updated section 1.1 to the latest template. In the latest template, this section include the reference to, I would say, a 8174. Number eight number six, update to the author's affiliation and contact information. Okay. I'll go through all the four quickly. First one, it's about LSP expansion. It should be a link state packet, but in current RFC, it's label switch pass. That's not the correct term. For this one, the reference to the section 3.2 should be a reference to the section 4.2 because I checked the history of this RFC. From the history, you you can see that in version zero four of the working group document, it introduced a new section, section three, but reference to the section 3.2 was not updating. So I think that that that's the cause to introduce this error. The the this error is similar to the previous one, just a round reference to the section. Similar one. Okay. This is the ZTE's implementation report. I talked to my colleague in ZTE who implemented this, and they helped me to write the implementation report. This slide shows the implemented features. Most of the features in this RFC have have already been implemented by ZTE. This slide shows the unimplemented features. There's no master level features unimplemented. For the shoot level features, there are several features not implemented by ZTE. First one, it's about session state. His services is not implemented. Second one is about admin downstate. This one, I explained in more detail in next slide. Third one, it's about adjacency establishment. In ZTE's implementation, BGP doesn't support a strict BFD mode. Only OSPF and ISS supported. First line is about interaction with graceful restart mechanism. I explain in the next slide. For the main level feature, there are two I implemented just like the previous should should the level one. Yeah. So this is the information experience from ZTE implementer to section 3.2 at the main downstate section. If only a static route system wouldn't notify the client of the local admin done, but it would notify the client of the remote admin done. So that's the current implementation of ICT. To the section 4.3, interaction with graceful restart mechanism. BFT packets are sent in the forwarding plane in ZTE implementation, and the graceful restart wouldn't be aborted due to BFT session failure as current implementation To section 10.3 1.3, OSPF virtual link and section 10.2, interaction with b BGP. B f d authentication is recommended in the RFC, but it's already implemented. But but to the knowledge of the implementers, they think this feature is not widely used. Yeah. Okay. So it is about another draft draft I've seen fifty eight eighty three base. The intention is similar to previous one. This RFC describes the use of the PFD protocol over multi hop pass, including unidirection links. Compared to the current published RFC, this job to include the changes here. First one, edit the section nine, information status. Only one report till now. Added section 10, acknowledgments, to acknowledge our working group chess and AD for their guidance on this work. Third one, updated section 1.1, similar to the previous one, and also affiliation and the contact information also updated. This is the ZTE's interpretation on this RFC. Only only one thing I want to mention that for the master level feature section three issues, the unaffiliated b f d echo is implemented when the echo packets are encapsulated within SRH. So I think for the this feature, maybe that's different with current app, say say, there's a must. Yeah. So currently, in ZTE's implementation to b f d echo function, only unaffiliated b f d echo is implemented. For affiliated b f d echo, it's not implemented by ICT.
[00:28:12] Jeff Haas: Okay.
[00:28:14] Xiaomin Hu: After some productive discussion on the mailing list, change is proposed. You can see our current text that says, finally, echo function must not be used over multiple hops. Intermediate hops would route packs back to the sender, and the connectivity through the entire pass would not be possible to verify. There's a a new text proposed by Richard to say that the must not is available in in any environment where the packet encapsulation of forwarding behavior could cause intermediate code node to return echo packet back towards sender. In such cases, connectivity through the entire path would not be verified. That that that's very correct. That's acceptable for me. But but I want to say something more about this feature. So I added some text after each other proposed text. Yeah. So that's for discussion. Next steps, ask for more information reports. Now revise this draft to draft based on information reports and received comments, and then working with last call. Thank you.
[00:29:48] Reshad Rahman: So since we're here and we have some time, I think, could you go back to the previous slide and maybe let people read? I mean, if anybody has opinions, strong opinions.
[00:29:59] Jeff Haas: Oh, I got it on. So the the thing I'd offer for this section, we have two things that we are worried about. As you're adding into here, implementation experience shows that people do echo mode and it's not directly connected in a, you know, link level sense. My experience, at least for the implementations I'm familiar with, is that from a IP or, you the outer level encapsulation sense, it's still regardless of how many hops away the outer encapsulation is, the inner encapsulation is itself single hop. It's going to the end of a tunnel.
[00:30:36] Xiaomin Hu: Yeah. You're right.
[00:30:37] Jeff Haas: So if that's the common scenario, we probably want to adjust our text to reflect that fact that it's still within the context of the tunnel, single hop, which means we keep the previous language in some respects. The motivation to do that, during the original, you know, work to rfc, this feature, is that the transport ADs at the time were incredibly concerned about echo mode being used as an attack vector on other devices.
[00:31:12] Reshad Rahman: You know,
[00:31:12] Jeff Haas: the idea being you can turn on echo and basically DDoS an adjacent system. So the restriction for single hop was there as much for security as it was for, you testability.
[00:31:26] Ketan Talaulikar: Mhmm. Yeah.
[00:31:28] Jeff Haas: So if it's acceptable for us to, you know, talk about this as single hop that might be tunneled, I think we get the desired behavior discussing, and we hopefully do not have to relitigate these security considerations.
[00:31:43] Xiaomin Hu: Yes. As far as I know, there are scenarios. For first one is, as as you said, that is a a outer header and an inner header. For the inner header, it's actually one hop. Mhmm. But as I know, there's a there's another scenario that's only one header. And then with SRH incorporated in into the header and also support the this kind of Mhmm. Body hops. Yeah. And I think one of
[00:32:18] Jeff Haas: the interesting conversations that we'll have to have, and this will be conversation with the ISG as well. You know, SRV six effectively is a tunnel, but it's also just as much just normal IP routing. So what will the security ADs have to say about the scenario? So I think this will be the interesting discussion.
[00:32:41] Xiaomin Hu: Okay. Yes. You're you're right. Because I actually can also be seen as a tunnel. Yeah. Okay.
[00:32:51] Jeff Haas: Ted?
[00:32:53] John Scudder: Since you were asking for a review of this, so while you guys were talking, I did a visual diff, and it looks to me like all of the new words are just starting with in other words. You just added that on. Is that I I think that's right anyway. My my opinion is that isn't necessary, but it it doesn't hurt. Like, it I agree that the in other words is a correct restatement of the rest of it. So I I tend to prefer keeping things short rather than having them be long. So I would encourage you to consider whether you really need to say the same thing twice, but I agree that you said the same thing twice, and it it's not you know? I I wouldn't fight either way.
[00:33:36] Jeff Haas: And I I think the consideration is we're trying to say that tunnels might be involved. And the in other words, you know, is trying to nudge us into that piece of the discussion. The existing text about single hop, multi hop, you know, doesn't really discuss the scenario at all.
[00:33:53] Ketan Talaulikar: Mhmm.
[00:33:57] Jeff Haas: Maria?
[00:34:00] Maria Matejka: I'd like to say, Maria, from BIRD, I'd like to say that on my on my side, it's a good idea to say in other words because it means that when I am reading the RFC the first time, I can check, have I actually understood it correctly? This is something I am complaining about a lot in different working groups where they read write it from the bottom from the beginning to the end, and there is no single checkpoint where I could say, well, did I actually understand it correctly? And when the when the thing goes like, this depends on that and this depends on that, then I ask question which looks which looks feasible. But it's it doesn't work because somewhere else, I am it it's it's in violation of something two sections before. And if I don't remember the whole text, like, completely precisely, I am go completely lost. So please keep it.
[00:34:58] Reshad Rahman: Thank you.
[00:35:05] Jeff Haas: Okay. Any other comments or questions? So I think, where we're at, you know, you've highlighted for, your implementation. There are several shoulds that, you know, don't have support. For at least two of those, I know that HPE Juniper's implementation does actually have support for the admin down and also for the graceful restart procedures, so we can cover at least two of those. Part of what we'll have to look at in terms of the twenty twenty six procedures is what level of support for shoulds need to be there to keep a feature within the RFC.
[00:35:45] Xiaomin Hu: Okay.
[00:35:48] Jeff Haas: K. Thank you for the presentation.
[00:35:50] Xiaomin Hu: Thank you.
[00:36:06] Prasad Miriyala: So good day to everyone. So this is Prashad. I'll present, fifty eight eighty four biz. Next slide, please. So, yeah, fifty eight eighty four is a little bit slower than the rest of the RFCs because it has some, I mean, nontrivial work more than the other RFCs because, primarily, it merges two documents. I think this is slightly more than one one base document. Therefore, I started off with or rather what we have currently is essentially a single document, the zero zero bistraf that merges the two RFCs, fifty eight eighty four and seventy seven twenty six. Both were published, I think, in the 2010 and 2016 time frames. So a a lot of the text or the flow of I made sure that the flow of fifty eight eighty four does not get affected because it flows quite nicely, and and and that flow has been retained so that the readability aspect of the previously I mean, previous speaker was also alluding to, I hope, has not been damaged. But please provide comments. Definitely, seventy seven twenty six adds clarity or rather, you know, seventy seven twenty six came into being for essentially clarifying primary ECMPs scenarios, I'm not mistaken. And that has been kind of, if I can say the word, we've been into the flow of the fifty eight eighty four document. So 78 some seventy seven twenty six, you know, had some background text which which got removed. Craig, do you want to wait or you're you want to go now, whichever you have called?
[00:37:47] Greg Mirsky: Let me wait. I'll wait.
[00:37:49] Prasad Miriyala: Okay. Sure. Sure. Sure. And and therefore, you know, the background sections of 7726, which which kind of gave the, should I say, the the redundancy, those texts have been removed. And now we have a single document that has both the text of fifty eight eighty four and seventy seven twenty six. This is the first part or the base part, but it has more. Next slide, please. Yeah. So three erratas have been published for 5884, and and I think all the text from the three erratas have now been included into the distraught. And, of course, an implementation section has been added to the appendix. I have not pushed a bit harder on the implementation reports, primarily for the simple reason that I want the base text to kind of settle down. And and once we have the base text settled down, then we can probably go a little more, you know, a little more deeper into the implementation reports. But for now, I'm kind of withholding. I mean, I they're still welcome. Don't I mean, I probably should clarify myself. Please send the implementation reports, you know, if you have implementations anytime. But right now, I'm a little more focused on getting the base text ready if if that's okay. But there is an implementation report report section added to the appendix. The full specification of the protocol was derived from August. The IANA code points, there was a comment from Amanda. I think that will also be included in the IANA sections. So the seventy seven twenty six does not, thankfully, introduce any new IANA considerations. Therefore, the base fifty eight eighty four IANA consideration holds. I believe that's true for security considerations as well because, you know, there was only a small corollary of security considerations added to the seventy seven twenty six, which I think have now also been incorporated into the best draft. But I definitely will complete back on on on the overall flow of the combined text. Next slide, please. Yeah. So these are the details of the errata. I probably won't go into the details of the errata, but but, you know, the numbers are there. I think, you know, some of them are editorial changes. Not all of them are. Some of them are. At this point, I will pause and refer to one issue that, you know, I forgot to mention here. I should have mentioned here. Thanks to Richard for pointing it out as well. Is that there is a discussion that is pending on the loopback address. I think this primarily comes from the issue that was raised in the b f d wiki. I'm sorry that I did not include it, but there is a discussion in the b f d wiki about I think Greg had raised three points. Probably, he he probably talked more on that. So I kind of there's one thing that needs to be resolved, which is the issue issue pertaining to the loopback address that should be used in the in the we have the packet. So that's something that definitely we can have with the question here and, you know, on the list as well. So that's something that definitely needs to be settled down. And this is probably one of the reasons why I kind of held back a little bit on the implementation report. Right now, the only way I have suggested for the implementation reports was to be emails, which I still prefer as the first choice because some of them are complicated. I will make one point about implementation report, surely. I don't know if it's covered in the next slide. Please go to the next slide quickly. Yeah. Okay. So I'm not going to talk much about this, you know, the the this is just saying that the seventy seven twenty six main aspects have now come into the draft. Next slide. Yeah. This is the this is the one. So there is a template, okay, for implementation reports that have been added into the draft. And this includes some questions regarding coverage of 5880. Now this is a repetition, but I've put it on purpose Because I think that for implementation for, you know, b f d or MPLS, some of the aspects of 5880 may be I I don't know how to say it. Maybe slightly different compared to the way You know, to put it right there, an MPLS LSP interface or or, you know, LSPs being represented as interfaces is not the same as a physical Ethernet interface or a whatever, you know, physical media interface. And therefore, implementations might have some additional considerations that they may want to highlight. They may have implemented actually or not implemented, you know, or, for example, I'll just give you an example just to illustrate the point. The timers involved in b f d or LSPs may be different from the timers that normally b f d runs on simpleton interfaces. And therefore, I thought that people may want to look at this as a total, you know, look at not just fifty eight eighty four alone, but look at fifty eight eighty plus in the context of fifty eight eighty four. And therefore, there is a bit of redundancy. But I think that redundancy is acceptable to make it, you know, or rather to understand the completeness sake for MPL SLSPs. And this is where I request feedback from the working group as well. If people think that this is worthwhile exercise or not, you know, this is what is only one person's opinion. Yeah. I think mostly that's it I have completed here. I don't know if there's another slide. Yeah. Next steps. Okay. So yeah. Next steps, of course, comments and implementation notes. Nothing new here.
[00:43:19] Jeff Haas: Okay. I'll make a quick comment about the implementation report then hand over to Greg. So in terms of the redundancy or at least the perceived redundancy to fifty eight eighty, that's okay. We're far more concerned that if we actually have the redundancy and we have contradictory information, you know, then there's some concern. Yeah. Greg, go ahead, please.
[00:43:41] Greg Mirsky: Thank you. Thank you, Prasad, for driving this work. Yes. I think that bringing fifty eight eighty four because it's merging with the seventy seven twenty six, it's a challenge. A couple things that I think that we'll be working on in the next versions of this project is that section eight probably might be improved because it includes still includes some text. This is from 7726 referencing original 5884, and that probably can be improved. Some of the text can be removed. One of issues that is would probably require, working group attention is what happens if, their remote b f d entity re sends back LSP, echo reply, with the b f d discriminator. It's local once it's already sent the b f d, control packet. So, because, in 7726, I think that we did not address, what happens then, whether, their, peer, ignores it, compares it with the b f d control packet it received already, or what else? And, yes, the question of using loopback addresses for I p v six. That's something that been discussed recently in one of the b f d related drafts, and it was a very interesting discussion. And some work being done, with the ISG because, their IPv4 mapped, loopback addresses from one twenty seven slash eight range are not really a look back in IPv6 sense. So that will be interesting. And one question I have is the merge of offers list of two RFCs. So how that would be handled. Thank you.
[00:46:26] Prasad Miriyala: Yeah. The authors list, I don't have a I'm sorry if I spoke out of turn.
[00:46:32] Jeff Haas: Please go.
[00:46:33] Prasad Miriyala: Okay. So I don't have a I mean, whatever is the guidance of the working group, I am, you know, willing to follow-up, won't follow-up. That's it, I can say.
[00:46:42] Jeff Haas: Yeah. My my personal inclination is that we go for the merge. If this pushes us over the five author limit, that is a limit the bias she has, you know, been happy to waive, you know, for these circumstances. So I don't think that will be a consideration. And, Greg, we do, appreciate your attention on 5884. We know you've had a lot of comments on, you know, edge cases for procedures over the years, and we've made very sure that the, you know, GitHub repository, when it was created for 5884, was bootstrapped with, you know, several of your issues. So we're looking forward to your review there. With particular regard to the discriminator ambiguity about, you know, what does LSP ping actually pass in and what you do if there is inconsistent procedure, I agree that there is room for clarification there. This is something, Prasad, that I suggest even though it's not necessarily a conformance item in the current r f c. This is a audit point that we'll want to know for trying to craft cleaner text for this, and this one has to be informed what by what implementations actually do. So when we get the implementation reports, you know, we'll hopefully also get a channel back to implementers at the various places that can tell us what do they do in these ambiguous situations.
[00:48:10] Prasad Miriyala: Yes, Jeff. And and, I mean, not on the record, but at least still, I think this is the top of my head or recollection. I I could be wrong here as well. I think the most guidance that I got was or rather the feedback that I got was was essentially to say that if the LSP echo response did have a discriminator, then I think it's probably silently ignored. Definitely, the b of the control packet takes precedence, but this is just my recollection.
[00:48:37] Jeff Haas: Yeah. The discussion we've had in the context of MPLS mailing list was that the procedure in 5884 is, you know, very normative and very clear, but this is still an edge case of what happens when there's inconsistencies. And the answer may simply be we stick to fifty eight eighty four. You know, effectively, this is the must that we follow. Anything else is maybe a notification for, you know, syslog or something like that. This is what experience will tell tell us when we actually talk to the implementers. I have a extended conversation about the loopback network, but, John and Matthew, why don't you go ahead and make your comments first?
[00:49:19] John Scudder: I hope I'm not John's better. I hope I'm not stealing your point. I've been asked a couple times about, because I was on the IESG when this document was advanced, what the heck is going on with that loopback thing. And I, a few weeks ago, went back and refreshed my memory by looking at the the email from that time. And I believe that it's as simple as, one of the Internet ADs said, oh, look. This thing is not actually allowed per the letter of the law in I p v six, so please fix it to be legal. And, we in this group, basically, after gnashing our teeth and saying, really, do we have to, did so, and nobody really thought through all of the consequences of it. Probably, if we had it to do again, what we should have said is then the I p v six specification is wrong because this is what the implementations actually do. Please go fix the I p v six specification. And if this is what the implementations actually do, we probably still should do that. So that's all.
[00:50:36] Jeff Haas: Matthew?
[00:50:39] Matthew Bocci: Yeah. Matthew Voci. On the on the kind of lack of information on what to do with the the discriminator and the LSP ping echo reply. Yeah. This this as as an implement to this has come up in the past as an issue. I think we need to make sure if we're gonna decide what to do with this, that the implementation report questions need to explicitly say what do you do if there's a gap, not just say, do you comply to this section? Do you comply to that section? Because you're not really complying to anything.
[00:51:14] Prasad Miriyala: That's a fair point, Matthew. I think I will add that. Definitely. Thank you for that.
[00:51:18] Matthew Bocci: K. Thanks.
[00:51:19] Jeff Haas: This is a case where we'll be creating no additional procedures. So that's it. The implementation reports will be guiding us there.
[00:51:28] Matthew Bocci: Yeah. Totally agree. Just don't don't put new text in there, obviously, because of it, but it's just really useful to know for implementers what everybody's doing without having to go out and interrupt test with everybody and, you know, reverse engineer it and things.
[00:51:41] Prasad Miriyala: Mhmm.
[00:51:43] Jeff Haas: So to add on to the loopback discussion, I did manage to have a extended conversation with Eric Vyncke and that, you had been the source of that of this discussion. There were two core points. Now the first one is that the the b f d working group had been invited to review what was going to be ninety seven eighty, and I think it was the primary reviewer in that context. After the feedback had been supplied, this stuff happened after the fact. So, you know, this one of the bits of advice to Eric is that when we make these sorts of changes in the future, let's close the loop and make sure that the prior reviewers were given another pass through things. And exactly as John's saying, you know, the the sort of core of our discussion was that we've had these procedures both for LSB ping and also for b f d for this loop back network for some time. So they're shipping code for it. Eric's sort of core point, again, wearing his int a d hat, is that in an IPv six context, anything that's a mapped address is effectively, you a unicast address from the IPv6 addressing architecture. That was sort of his motivation for that point even though the mapped addresses basically say, do what IPv four does under the covers. So there's probably still room for the various I p v six groups to do something about this. What's sort of interesting is it's created the second problem at the other end. The new 100 colon address is not from a prior I p v six architecture, you know, address range for Unicast addresses. It's completely new. And part of the registration procedure for that includes things like, you the forwarding behaviors. What's an interesting headache that v six implementers are aware of is what do you do with things that are not specified in the architecture? Do you treat them as nonaffordable, affordable? And experience generally suggests that most implementations don't treat it just like another unicast address. You know, these special behaviors are added after the fact. So I've been having parallel conversations with people like Jen Dankova, you know, covering things like should 6man or somebody else get the new 100 network into the procedures as a non forwarded thing? How do we basically notify the entirety of every I p v six user across the planet that you have a stack that needs to change, go for this behavior? So they they've created another interesting headache for themselves. Eric did point out that, you know, this network is also used for things like BGP, real time black hole procedures. So this will eventually happen in stacks across the planet, but for the short term, you know, we have this unfortunate ambiguity. The final point relevant to 5884 is that Eric was leaning towards, yeah, we we've sort of said that we needed to fix this anyway, and here's what we did in 9780. But Eric was reminded that, the procedures for moving stuff to full standard is that we have two interoperable implementations. In this case, there are no implementations on the plan that do 5884 of this 200 network. So it's very likely that at least Eric will allow, you know, his, stance to say leave things as they are even though he's uncomfortable with it. But he also highlighted, prior BIS documents that, have added stuff as part of moving forward. So this will be, I think, a little bit of a struggle point with the ISG. I don't think there's anything hard here. We'll either be supplied to, you know, use text from 58 from 7880 9780 into 5884, in which case, you know, that's easy mode, or we leave it alone. Past that point, I I do wanna specifically acknowledge, you know, Prasad, you know, you've taken the hard to know piece of work out of this series. Thank you very much. And in general, thank you to all the editors that have actually taken up this work, Xiaomin, Alvaro. This is not necessarily the grand scheme of, you know, RFC work hard, but this you know, the details will be very important. Matthew, are you still in the queue?
[00:56:11] Matthew Bocci: I'll do it by the way.
[00:56:12] Jeff Haas: Okay. So unless there's other stuff, we are actually running on time. We have have five minutes left. Is there any other conversation points? I'm not seeing anything else. So we'll go ahead and, get the minutes up to date, within the next week. Again, our key components are let's get to the implementation reports in. You know, we should have one coming in from HPE very shortly, and that will help, you know, clear up some of these things, you know, for some of the specs that only have one at the moment. And, you know, at least my personal goal for the working group is if we can have, you know, all the implementation reports in, say, within the next month, we have enough time to hopefully work through everything except for some of these more interesting fifty eight eighty four problems. And if we're lucky, we can, you know, get the last call started prior to the next IETF in San Francisco. That said, you know, this working group was supposed to be short. We'll hopefully keep the the task to actually do this, you know, within a reasonable time bound. And if we're very lucky, by end of year, we'll have some brand new Internet standard. Okay. Thank you, everyone. We'll talk to you online.
[00:57:33] Jeffrey Zhang: No.
[00:57:37] Jeff Haas: It's actually live.