Session Date/Time: 20 Jul 2026 07:00
[00:00:22] Chairperson: Yeah. LeTEAS go. Okay. Good
[00:00:38] Ying镇: morning. This is the I think iTEAS on. Is
[00:00:45] Ji: there? Can you hear
[00:00:46] Ying镇: me over the mic?
[00:00:47] Chairperson: I think so, but the mic.
[00:00:49] Ying镇: Okay. Good morning. This is the LSR working group meeting at IETF 126. We're going get started because we have action packed agenda this morning. Hold on.
[00:01:21] Les Ginsberg: It was working. Okay.
[00:01:23] Tianyang-yang: This one.
[00:01:24] Acee Lindem: Which one?
[00:01:25] Ying镇: The right arrow.
[00:01:26] Acee Lindem: Oh, yeah. The right arrow. Okay. Well, this is the
[00:01:30] Ying镇: first meeting of IETF 126. So please take time to read. Please take time to read the note well regarding, okay, regarding IPR and harassment. Be aware that if you are aware of any IPR, you're obliged to
[00:01:57] Chairperson: disclose it.
[00:02:02] Acee Lindem: ITEAS working.
[00:02:08] Ying镇: As I said before, anybody who's on-site, please log in using the on-site, media tool.
[00:02:18] Tony Przygienda: Close. That one is.
[00:02:21] Ying镇: Some people say say it is, but some people say it isn't.
[00:02:24] Chairperson: Very weak. Yeah. ITEAS very weak. ITEAS working out. I don't think iTEAS enough. Yeah. It needs gain and improve. We need a message messaging.
[00:02:36] Les Ginsberg: Maybe I'll just do it.
[00:02:41] Ji: You see this?
[00:02:42] Ying镇: Yeah. ITEAS okay.
[00:02:44] Acee Lindem: We're gonna need it work. We're gonna need it working.
[00:02:48] Les Ginsberg: Oh, okay.
[00:02:54] Chairperson: Oh,
[00:02:58] Acee Lindem: thaTEAS how it was.
[00:02:59] Ying镇: Okay. Okay. Okay. Right here? Oh, right.
[00:03:12] Acee Lindem: Up and down.
[00:03:15] Chairperson: I was gonna try and go through these fat fast, but now I'm already behind. We have a a few RFCs that we've
[00:03:22] Acee Lindem: gotten through since the last IETF. One thaTEAS actually been published and a couple more. Well, this one thaTEAS on the queue and our Yang documents are soon gonna be on the queue. I think draft-ietf-lsr-distoptflood gonna be scheduled for a tele chat in the very near future. LeTEAS see. New one new document adopted, another flex-algo. We've been talking about these documents for compliance, the yang documents. I guess, since Ying镇's offer, we'll start a discussion on these. We might do that. I don't know. Since we got the link attributes and flood I mean, flex-algo on the r f or approaching the RFCQ, we have an we can make more progress on some of these existing yang documents. If you noticed, a lot of the new LSR drafts have the yang as a as a section right in the draft. So that would be actually a better way to keep up with yang concurrency and protocol concurrency. I don't think there's anything I need to say about any of these. I know probably no. LeTEAS go ahead with the agenda. You wanna bring up the first one? There were some on the existing documents that are in progress for a requesting working group last call, but I think most of them are on the agenda today. Ron in the room?
[00:05:48] Chairperson: Hello.
[00:05:57] Ron Bonica: Ron Bonica, HPE. And I'd like to talk about, using IS-IS to advertise power group membership. These days, iTEAS also called IS-IS support for power conserving path placement strategy. And leTEAS talk about what iTEAS all about before we talk about changes to the document. A robust network has enough capacity to satisfy demand during peak hours. In fact, it has a little bit more to add redundancy. Most networks have daily utilization patterns. They might be more busy at during the day, less busy at night. And that means during off hours, they have excess capacity. Excess capacity increases costs and it increases environmental impact. These days, we care about environmental impact. We don't want to do that. So what are we seeking to do? We've come up with this power conservating path placement strategy. There's a draft about that in TEAS. What it does is during periods of low demand, it concentrates traffic onto the smallest set of links possible, supported by the smallest number of network resources. If you do that, if you concentrate your traffic on as few network resources as possible, you can power down the ones that are idle or nearly idle. Saves power, saves HVAC. Good thing all around. And you can power them up again when they're needed again. Now, p c p p s uses, CSPF. Now, leTEAS talk about CSPF as it is today without PCPS. Each link has a metric and CSPF computes paths that don't violate constraints and that has the lowest cumulative metric. Now whaTEAS the difference with this PCPPS thing? Well, it has a different metric, and that metric takes power consumption into account. So you're still looking for the best path, but you're looking for the best path with power consumption being part of the definition of best. Now this PCP PPS metric, iTEAS derived from power, power consumption information along with other things like, you know, other metrics that you might have used previously. The local information is learned from the platform. You know, the platform knows best how much power it consumes. If you can't pull it off the platform, you can put it on the platform by configuration, and it'll advertise that stuff through the IGP. This is why this working group is involved. We need to advertise this power information through the IGP. And you need to know about power consumption on remote nodes, which means you need to learn that power consumption through the IGP. This draft talks about a bunch of new TLVs that you're using to advertise and learn power consumption information so you can compute the PCPPS metric. And I'm not gonna go into every single TLV thaTEAS in the draft, and we've seen that a few ITFs now. WhaTEAS changed in this draft? First, in previous drafts, we made the erroneous assumption that when a network component is powered down, it consumes no power at all. Well, this is true in some architectures, but not in others. In some architectures, you have a powered up state where it can do everything that it needs to do and it consumes pretty much maximum power. You have a power downstate where it can't operate, but it has enough power to come up quickly and a state where it has it consumes no power at all. Well, we still talk about two states, but we no longer talk about the power consumption of a particular network element. We talk about the power savings potential. How much power could we save if we moved it from the all the way on state to the state where iTEAS not functioning but, you know, can be brought up again quickly? Thanks to Carlos Pignatero for bringing that to our attention. You know, this helped a lot and it made the solution much more generalizable. The other draft, we have a concept called power groups. An interface may rely on some other piece of, hardware in the box. That may rely on some other piece and some other piece. Well, in some architectures, you can turn off not only the interface, but the hardware that it depends on, maybe the line card that it depends on, maybe the packet forwarding engine it depends on. So we have this concept of a power group. ITEAS a hierarchy of hardware that might be able to be powered down. We don't talk about this, power groups in this draft anymore. We make a reference to the TEAS draft that describes power groups and describes this whole, PCPPS concept. At first, this this LSR draft was the only draft, then we abstracted the CSPF part into a TEAS draft and the part thaTEAS generalizable. It'll be generalizable between IS-IS and OSPF and anybody else. ThaTEAS all in the TEAS draft now. Thanks to Les Ginsberg for making that suggesting that change. Now we have an ask, and the first most crucial is code point assignments. We're advertising new TLVs. We need code points. We we need working code to demonstrate industry adoption. We need code points to put out to get industry approval. Also, we'd like to adopt this draft as a working group item. ITEAS been around a while. We have a working code, and we'd like other people to join in the party. And at that, open to questions. We we haven't thought about it. In fact, this is at this microphone is the very first time I thought about flex-algo, but iTEAS an interesting concept. If you could send some email, it might be a good idea.
[00:13:18] Peter Psenak: Okay. Thank you.
[00:13:25] Chairperson: From the from a chair perspective, I think we usually need to get the working group adopted before we do the code point early allocation.
[00:13:35] Ron Bonica: Could we Yeah. Have to do a call
[00:13:37] Chairperson: for saying no to either. I'm just saying that, you know, thaTEAS the order we generally go in. What do you guys what else do you have? Oh, and by the way, you you're an on-site tool. Right? So when you go up to the mic, put yourself in the queue. Oh.
[00:13:54] Ying镇: Yeah. Do I
[00:13:56] Zafar: have to go in? Yeah. Yeah.
[00:13:57] Acee Lindem: You do. AC Lindum, Arcas. There there was a discussion, and I don't know where we came out. I noticed the draft is standards track. Did we discuss about whether it should be experimental based on the discussion with the guys over in the green working group? Because I thought they said they didn't have any I know they I know there was an ask for you to compare it to what they had in their model. Yes. Information model for their information model of
[00:14:30] Ron Bonica: We did take a look and they are partially but not completely overlapping. We would encourage them to to add the stuff that we have into the information model because, you know, iTEAS not like we contradict on those points. ITEAS just that we don't talk about the same topics.
[00:14:49] Chairperson: Yes. I mean, the general I so kind of summarizing where we were with the green hold the green thing last time, the idea, the the eighties and us had come up with was, leTEAS get the input from, green. Mhmm. But leTEAS not hold this work up.
[00:15:09] Peter Psenak: Mhmm.
[00:15:09] Chairperson: Right? LeTEAS just make sure that they're aware of this work and that they've had input on the work so that in case there's, you know, silly differences Yeah. Right, that we align those differences. But other than that, just you know, we just need to make sure that going forward, there's the ability you know, iTEAS IS-IS, so iTEAS almost always easy to extend or change or Yeah. I think
[00:15:33] Ron Bonica: Carlos' input was part of that Okay. Effort. But if there's anybody from green here or actually, I can I can grab the green chairs later? Tony's raising his hand.
[00:15:44] Chairperson: So Yeah. Okay.
[00:15:48] Zafar: Zafar. Zafar- Cisco. So you mentioned that you implemented this, but you were not aware that when you put something sleeping, it takes power. It just give me uncomfortableness that when you the way iTEAS not not the base problem, but the way you have defined hierarchy, how accurate any vendor, how much is vendor specific in terms of predicting. If you can predict when iTEAS down, when iTEAS up, how do you predict about all different components, how much power? So then the second part is that there is a work for the base that is in Ts, and I do believe that there is a dependency on that because this is where we're gonna discuss this part that I'm mentioning about the hierarchy. Is this the right way to model this or there's another way? And and how for different vendors being able to do the same type of encoding.
[00:16:57] Ron Bonica: Okay. For your first comment about the modeling of the power groups, please take a look at the TEAS draft. It goes into that and iTEAS a iTEAS a very abstract thing. You know, a component relies on another component that relies on another component. We haven't found a hardware architecture that this cannot describe. And the I would put the action item on you. Show me a hardware architecture that really exists that this model does not describe, and then we will modify the model to to deal with it. But I need to know before we start, show me the hardware model that I cannot describe, and then I'll enhance the model.
[00:17:40] Zafar: I'll be happy to work with you and talk to you.
[00:17:42] Ron Bonica: Okay. Yeah. Okay. And the second question about the TEAS draft. You're talking about the PCPPS TEAS draft? Yes. Yeah. ThaTEAS I wrote that. As Tony behind you. Yes. They they better be in in sync because one references the other.
[00:18:04] Zafar: ITEAS iTEAS not about in sync. ITEAS about the dependency and iTEAS about the right model that works for all vendors. And honestly, my worry is that how accurately when you go to this level of detail this is where the model matters. If you go to that level of details, then it matters if you can know how much power that particular components of that element. So I'm okay. LeTEAS say, for instance, you talk about interface level, then I know, okay, this is this is a concrete level. But if you go down to the weeds of it, then like you, you never knew that the zero is not zero power when you are putting something on sleep.
[00:18:50] Ron Bonica: Well, of course, Carlos' Carlos' comment
[00:18:52] Zafar: was Carlos' product should have come from you, from you implemented this because you had a problem estimating these things. This is a problem for other vendors too that would be implementing this.
[00:19:05] Ron Bonica: Absolutely.
[00:19:06] Zafar: Is is is this is this the right way to model this? Can I can I actually actually get this information from my hardware? And thaTEAS the conversation I want to have. Okay.
[00:19:15] Chairperson: That sounds like that sounds this is not even a working group document yet, so that sounds like good discussion to have going forward. Thank you. Noted. Thanks. Tony.
[00:19:26] Tony Lee: Hi. Tony Lee, HPE. Regarding the interaction with Green Working Group, we did have an extended discussion with them. They are carrying much more information in the yang model than we are in the IGP for obvious reasons. We don't want to burden our IGP. And we found that there was no conflict, that we did not have any issues, and they had no reason for us to be experimental. So we do recommend going standards track.
[00:19:55] Chairperson: Thanks.
[00:20:00] Ron Bonica: Any more questions? On with the show. Thanks a lot.
[00:20:10] Acee Lindem: Sure.
[00:20:13] Chairperson: Who wants to Ying镇, do you know how to run a poll? I just wanna see if maybe objects to making this working document. Yeah. Yeah. ThaTEAS good. We're gonna run a quick poll show of hands to see if anyone objects to this becoming a working group document.
[00:20:32] Acee Lindem: Yeah. First of all, raise your hand if you've read the document.
[00:20:39] Ying镇: Fair amount.
[00:20:43] Peter Psenak: Okay.
[00:20:47] Acee Lindem: Do you know how to do the poll?
[00:20:50] Chairperson: Do the poll? Oh, okay. I thought you were doing it. Yeah. It was good. Does anyone object to this becoming a working group document? Put it primarily negative. Okay. So now there's a poll. Does anyone object to this becoming a working group document? So yes if you object, no if you do not. No if you think it yeah. Sorry. So we have we really have six or seven people that object to this becoming a working group document. Make sure that when you're voting yes, you mean you do not want this to become a working group document. Okay. Well, thaTEAS an interesting read. Okay. By the way, we don't vote, so this is just to give us a feel for the room.
[00:22:12] Ying镇: Give
[00:22:16] Chairperson: it a minute. Just a minute more. Yeah. That thaTEAS enough. So iTEAS not a unanimous sort of feeling, but we'll take it to the list. Yeah.
[00:22:36] Acee Lindem: This AC Lindo speaking as a working group member. I think this draft isn't too I mean, iTEAS not too complex, especially if you've read the TEAS draft, and I certainly wouldn't object to adding this as a working group document.
[00:23:00] Chairperson: Thanks.
[00:23:01] Ying镇: Just remind people, please make sure you sign in Meet icon so we can
[00:23:09] Wei Chang: I didn't do it?
[00:23:10] Chairperson: Did you pull a poll? Yeah.
[00:23:11] Acee Lindem: I did. I well, okay. Okay. I didn't join the queue.
[00:23:17] Chairperson: Oh, Tony, are you sorry. Go ahead. He's on the queue. Go ahead.
[00:23:22] Tony Lee: Could the could those objecting please come to the mic and explain why they're objecting?
[00:23:33] Zafar: This is a far I'm one of one who objected. The reason is this the the base working piece in terms of how to model comes needs to be discussed. Like, I already agreed with the with Ron that we're gonna discuss that a bit more, and this is on working group agenda. So the LSR is mechanics. So that is the issue here. So I think there's no problem. Let the TEAS go first in terms of his his definition and adoption, and then the LSR can follow because thaTEAS thaTEAS how
[00:24:07] Chairperson: the mechanics works with this. But my problem is with the data model. So you think iTEAS too early to bring the work to LSR is what you're saying? Yes. Okay. No. Tony?
[00:24:21] Tony Lee: Then the objection is well placed in Ts, but not here.
[00:24:29] Chairperson: Well, he's objecting to the document being here. So I'm not sure why. Anyway okay. Was that seven other colleagues that objected, or is there no one else of the eight people? No, no, don't think you objected.
[00:24:55] Tony Przygienda: I object to objectify myself.
[00:24:58] Chairperson: Okay. I think leTEAS move on. Thank you.
[00:25:13] Tony Przygienda: You let me
[00:25:14] Chairperson: know. Yeah. Go ahead.
[00:25:15] Peter Psenak: Yeah. Go
[00:25:15] Tony Przygienda: ahead. Alright. Morning, everyone. Okay. So here's something more to object to possibly. Renamed renamed the draft from the packet timestamping that we were already showing, right, for TED purposes mostly. First, we split the part that had an optional database checksum in Yank that went into a totally different draft. ITEAS a good operational tool, but, you know, it doesn't extend packets. ITEAS kind of orthogonal. But the draft also got renamed because what we're seeing is that the time stamping can be used for replay protection. So the draft has been massively extended. Next one, please. Or somebody have got a clicker.
[00:26:01] Acee Lindem: Click, sir.
[00:26:02] Tony Przygienda: LeTEAS see whether it works. Yeah. Wonderful. Like I said, the YANG database checksum has been thrown out into a different draft, and the replay protection has been added.
[00:26:14] Peter Psenak: Okay.
[00:26:15] Tony Przygienda: Push. Push. Push. Okay. So whaTEAS replay protection? In case you don't know, thaTEAS a sophisticated attack where somebody has a recording of previous packets on the session. Right? And then, periodically, you can just inject packets, replay the packets on a wire to cause havoc. And the simplest one is, of course, we record something like an initial hello with an init, and you wait until the session established. You tier the session down, then you go away. Right? Very hard to track down. Sophisticated attack. Authentication does not help because the packet is authenticated. Right? So how do you deal with that? So there's something which is a state of the art where you exchange something called nonces, which are basically random numbers. You send on a hello random numbers and say, hey, reflect this random number to me. And I reflect you not your random number to you. And then you basically have these two nonces that are authenticated. Right? And only if these nonces match, you run the sessions. So anybody recording the stuff, the nonces will likely mismatch and you just throw the stuff away. There's a bunch of practical problems there. You have to flip those nonces, leave a window open. If you're interested into all the gorgeous detail of this kind of stuff, read the RFC ninety six ninety nine, the the Rift stuff, which has basically nailed to the, you know, most optimal known way today how to protect against replay protection. But ISI is only the best. We also want nonces. We can do that, unfortunately. So for halos, we could. But for flooding, we won't manage that because we run into MTU problems because we have to stick those nonces which are link specific somewhere. Right? And when we're flooding LSPs, we would kind of need an outer envelope for it on the link with the specific nonsense and put the LSPs into that. That will, of course, ruin the whole MTU, for for existing deployments. So thaTEAS you would have to reconfigure the whole domain on the whole MTU. ThaTEAS operationally not feasible. Or we would have to start to invent l two fragmentation, which is a very, deep red hole, I think. Alright. So we do have timestamps. So with timestamps, we can do a reasonable approximation of, replay protection. Actually, pretty good one. ITEAS more complex. It doesn't cover as well as nonsense, but iTEAS something I think worth attempting within the engineering envelope that we have. Alright. So this will be completely backwards compatible, optional. Alright. And what will start to come up is, of course, that the clock synchronization now becomes much more pressing. Before the TET was like, yeah. I have some kind of clock with some kind of precision. I throw it out there, see whether you can do anything with it. Now here, the clock synchronization becomes paramount because based on the fact that we kind of run the same clock and we timestamp the packets, we know whether somebody's replaying or not. So, we have this timestamp and kind of a skew, the precision. Right? So we we changed the encoding a little bit to allow for much better precision on the clock. I think there was also Bruno's comments, or I don't remember, that the precision wasn't good enough. So now the precision is one millisecond. Right? And the skew is less precise, but you'll see. The the encoding is a little bit denser. What is interesting now that we have two type of clocks. We have the precise clock, which means I have a stratum zero or I'm NTP synced. But the reality is that when you're coming up, you don't necessarily get to the NTP server. So how do you get the clock? We could say, well, you don't have a clock until everything comes up, which then is completely unprotected, and we rely on NTP. But what we introduced is something called the proxy clock. So, basically, if you have a bunch of neighbors that already have a clock, the time stamping towards you, you can use that to derive a proxy clock, which is probably not as precise, but iTEAS good enough to get to get everybody going. You'll see the details in the draft. ITEAS just iTEAS kind of a small Paxos thing where you take precise cloths and you take the median of the whole thing, and it kinda go backwards and so on. All the details are in the draft. And we introduced two deltas. One is called the small delta, which basically means take your neighbor's precision, your precision, add them together because iTEAS the maximum skew. Take some small constant. And within this time window, you're willing to accept hellos when the time stamped within this this time window. And we have something which is called large delta, which is kind of the same thing but for flooding because the flooding is far away, SKUs may add link delays and so on. I'm trying to go real fast. I don't have much time. Good. So now the nice thing alright. The present stuff underneath fell apart, unfortunately. So on the there's now two timestamps. Y for halos, one for LSPs. One one y one for LSPs. And the graph would be nice. Because now in the time stamp, when you originate LSP, we carry the originating lifetime. The nice byproduct is that with that, we can basically counter any kind of lifetime attack. We have the RFC that that less wrote, you know, with this, like, double the lifetime, don't accept, but iTEAS just a very coarse approximation. This thing would protect the lifetime perfectly. You will know if somebody's mucking around with the lifetime. So a very rough acceptance picture, which is invisible here. You carry the original lifetime. The thing comes, and you see what is the lifetime on the packet, what is the original lifetime, what is the time now, and you can say whether the stuff fits within the window and somebody's mucking around with the lifetime. Again, very little time. I'm rushing forward. So it all actually quite more tricky than it looks because you also have to deal with the fact that people can go down, reconfigure to run without any timestamps, come back up again without timestamping adjacency, and you still somehow have to bring the whole thing up. Right? So, what you're basically doing is that on the down of the adjacency, you basically flush everything out, like anything you know about the time stamps. And the moment you get the first packet, which looked like it had a valid time stamp within the window you're willing to accept, you remember this time stamp. And from there on, anything that comes with the time stamp, you basically anything goes backwards or follows out the window, you throw away, and that prevents replay attacks because you'll not have packets that fit within the window that are timestamp. And anything which is not timestamped, you will throw away because you've seen that the neighbor is timestamping. Okay? I have to skip a lot of detail.
[00:33:17] Chairperson: You five more minutes. So now
[00:33:21] Tony Przygienda: I don't have enough PowerPoint. I mean, what are you doing? Changing the rules on
[00:33:24] Chairperson: the Don't don't use the five minutes if you don't want it.
[00:33:26] Tony Przygienda: But you need the soccer world cup. If you need to have rules. Okay. Alright. No. I mean, iTEAS iTEAS pointless to, like, drill into a lot of details because stuff gets fairly complex. The draft describes it very well. You're interested. Read it carefully. I mean, we discussed it across multiple authors. We didn't implement it. Right? So there's a lot of mental gymnastics here. But when you start to look at LSP acceptance, it will start to get even more interesting. Like I said, you can see whether the lifetime has been marked around. So thaTEAS a good value add. But now you also have the problem that a router may originate an LSP, throw it out there, and then go down, disable time stamping, and start to issue stuff that is not time stamped. And you cannot say, oh, you time stamped. Now I refuse any kind of topology update from you. So the way it works is that we see from someone a fragment timestamped. Right? And we didn't know anything about it before. And it passes IS acceptance rules first. So we go, okay. If that stuff is within acceptable window, we take it. We we start a timestamp. And from there on, we refuse everything which is timestamp not monotonically progressing. But here's, for example, a very little catch. On I s on IIHs, we are strictly monotonic. Nobody will send two IIHs on the same millisecond. With LSPs, we don't know because with fast flooding, the flooding rate could go berserk. So we cannot be strictly monotonic. So we allow something that is monotonic only. See how subtle it gets. Right? So now you have this time stamp, but, unfortunately, the guy may have gone down, come back up, and he starts to send out things which have no time stamps. So we have to accept them. So although we saw the fragment time stamp, if we see a newer version without the time stamp, we take it, which leaves an interesting attack vector where somebody could record a whole sequence of untimed stamp fragments of the same fragment, untimed stamp over many versions, and basically repeatedly overwrite the timestamp that comes from the source because the source will purge or purge. You will do a newer version with the time stamp, but then the guy has the next higher time stamp that takes you again. So the recommendation, the draft is that you'll be running time stamping and you see that you have to run over an older version, you bump in higher steps. Okay? So so lots of subtlety. And you would think this is complex. The purges are even more interesting. So I don't even put up the details here. Because now the purges, the RFCs we have do not allow to carry the time stamp. Right? So we first, we have to extend the RFCs to allow the timestamp. And the purges interact with the l s LSP fragments. But like I said, thaTEAS definitely read the draft, think about it, and thaTEAS thaTEAS the spiel. Right? ThaTEAS the practical solution for IS-IS Replay Protection as far as I see.
[00:36:39] Chairperson: Yeah.
[00:36:40] Tony Przygienda: All good.
[00:36:41] Acee Lindem: AC Linda Marcus. I think iTEAS interesting that there was previously I I I just checked and I didn't find anything. There was previously no replay protection in IS-IS. I know we put when we were doing all the HMAC drafts, we put it in OSPF, and this is this is the first time iTEAS in ISI, so I think thaTEAS interesting. I also wanted to point out what Tony means by monotonically and strictly on a monotonic. He means monotonic, it means it doesn't ever decrease. Strictly monotonic means the next one has to increase.
[00:37:21] Tony Przygienda: There you go. Here's a math PhD honorary. I don't know. I mean, this is subtle, but it plays a role. Right? So iTEAS very easy to screw up this kind of security.
[00:37:31] Chairperson: Okay, Wes.
[00:37:34] Les Ginsberg: Yeah. So iTEAS iTEAS not true that IS-IS does not have replay attacks. RFC seventy six zero two.
[00:37:44] Tianyang-yang: Protection.
[00:37:44] Les Ginsberg: With with extended sequence numbers was discussed several years ago, and it does provide a replay protection. And it was interestingly enough, it was decided during that discussion that LSPs did not need replay protection. So the the other comment I would make thaTEAS sort of related is when I read the first version of the draft, maybe I haven't read the update, it seemed to me that your primary use case for the timestamps had nothing to do with replay attacks. Now you seem to be saying the primary purpose of the draft is replay.
[00:38:27] Tony Przygienda: I don't think I said that.
[00:38:30] Les Ginsberg: If thaTEAS the case, then I think you need to look at the work thaTEAS been done before and explain to us why thaTEAS insufficient.
[00:38:39] Chairperson: Les, did you when you I don't know if you researched this comment at all, but if you did and you have a pointer to the old discussion on the mailing archive, that would be great to throw on the list.
[00:38:50] Les Ginsberg: Well, if you go back to r f c seventy six zero two, if you can find the discussion back back then, there's actually a reference in seventy six zero two to another draft, a carp draft. I don't know where that stands. I could research that. But this was discussed at some point.
[00:39:07] Chairperson: I'm just just saying if you have the links, it would make it easy for
[00:39:11] Les Ginsberg: everyone to I'll I'll try and dig it up. Yep.
[00:39:13] Chairperson: Perfect. Thank you. Peter.
[00:39:16] Peter Psenak: Peter Shana, Cisco. So just a word of caution here. The NTP clock can drift to the past, to the future. You can I know? You can have different NTP servers. We've had we have seen issues. So Oh, I'm fully aware of that.
[00:39:32] Tony Przygienda: Alright. We recommend people to run at least three servers. Right? Preferably four. Fully aware. Right? And interesting discussion where to take it from there. Right? Do you have to run PTP? I mean, iTEAS iTEAS depends how paranoid you are. Right? Yeah. If you even care about the attack vector. And then the question is, how good can the attack be? And that influence is exactly like I said, it it has impact on on your clock precision necessary. But you don't
[00:39:58] Peter Psenak: want to drop the valid LSPs because of some issues with the NTP servers. ThaTEAS basically my point. We have to be very careful there to not actually create a problem.
[00:40:09] Tony Przygienda: Well, but thaTEAS the thaTEAS why the large delta.
[00:40:12] Peter Psenak: Okay? Well, Yeah. One is large enough. Right?
[00:40:15] Tony Przygienda: Well, you have a better proposal, but basically,
[00:40:17] Ying镇: iTEAS precision.
[00:40:18] Tony Przygienda: Cross precision times something, make it probably two to three seconds on the larger network on an LSP. And and thaTEAS the problem. Then you have this attack vector starts to get wider and wider, right, where you have this couple of seconds, you can accept something which is replayed. ThaTEAS a disadvantage versus the non sys. Right? The non sys do not leave you these attack windows.
[00:40:38] Peter Psenak: Okay.
[00:40:38] Tony Przygienda: Yeah. And if somebody has a good proposal how to go to non sys, we can scrap that, you know, immediately. But through the thinking, you know, I really, really don't want to go into l two fragmentation.
[00:40:52] Chairperson: So my thought I will openly I haven't read this all the way through, but the time stuff is pretty scary looking to me. We've wanted you know, we've had reason. If we had synchronized clocks and we could count on them in IGPs, we would have done a a lot of things. Right? Like, we could do synchronized fib updates. Like, I mean, there's a there's a reason we've we've avoided this because, I mean, you're you mentioned, like, a Paxos algorithm. Are we really gonna do a Paxos algorithm and IGPs to do, you know, simulated clock?
[00:41:27] Tony Przygienda: No. No. Really, iTEAS iTEAS not a full Paxos. ITEAS a very lightweight. Right. Take a median. An attacker has to compromise at least half the peers to actually do something to your clock and, for example, says you cannot run the clock backwards under in so there's a lot of subtle there. I'm with you. But, you know, at the end, it is the customers. If the customers care about the stuff, want it built and deployed
[00:41:50] Chairperson: That that Go ahead. Customers might care about replay protection. The customers don't necessarily get to dictate bad solutions. Right. So I'm not saying your solution is bad, but I'm just saying Yeah. You just because a customer says I want this solution doesn't mean thaTEAS what
[00:42:04] Tony Przygienda: we're easy to call something bad, especially if you have nothing else. Correct? And if you get the is the problem and give them something, then the question is, do you want to deal with the trade offs involved here?
[00:42:15] Chairperson: If you if you give me synchronized clocks, I'm gonna worry about fib updates and, know, micro black holes and stuff way before I worry about replay.
[00:42:23] Tony Przygienda: Well, would be perfect. Well, do we have 20,000 routers with stratum zeros in them? Yeah. Okay. I'm all for it, man. Yeah.
[00:42:29] Chairperson: I'll that I've taken all the time I can. Thanks, Tony.
[00:42:34] Tony Przygienda: Alright. I don't know whether I go to next or Yeah. Because I stay on. Otherwise, you have
[00:42:40] Chairperson: something else. No. I think you're next.
[00:42:44] Tony Przygienda: Well, see. Alright. Alright. So another rename draft. Right? Because we found a much better acronym, and the acronyms are important. So thaTEAS goes to this hierarchical CSNP, not really, rather this Merkle tree ideas, which is not really a tree. I think I explained last time the original reasoning that a very large databases, the CSNPs, are basically becoming, useless given how many of that you have you have to send plus, you know, significant burden. So oh, yeah. I have to click her. Look at this. Fantastic. So whaTEAS new? Right? So lots of, basically, of enlightenment based on practical implementation starting to run the whole thing. And we have an ongoing open source implementation as well on the side. We see how that goes. The renaming hash stands for aggregated SNP hashes or something, but iTEAS basically David Bowie, if you know your David Bowie lyrics. Right? So it turned out that the original model was too simple, just sending the the hashes. It turns out that what you really need is a pretty much analogous solution like CSNP, PS and P. Alright? And I show an example later. So we basically now have two types of hash packets. The complete is called CACH. So this is like that. And, you know, just a little bit of an English stretch, the the partial is called PACH. Alright? So we have CACHes and PACHes like CSNP, PSNP. Same thing. And, jobs actually nicely but persistently notched us towards a completely new hash, right, to go to sip hash, which I was skeptical about. He was 120% right. I showed the results. So we went to a sip one three sixty four bits hashes. I also explained the 64 bits over cautious extension. We added example to the draft, massively restructured the text, and iTEAS probably the first draft that acknowledges in the acknowledgment session acknowledges cloth. ITEAS actually very interesting to start to interest to discuss your draft with cloth entropic from the perspective or of do you see any specification holes? ITEAS actually quite valuable. So clothe got an acknowledgment. And he was very flattered that I asked him to do an acknowledgement to the draft. Anyway. So an example, which is probably totally unreadable. My horse for an example, if you know your Shakespeare. Okay. Richard the third. So this is something, with three k fragments, 100 nodes, about 10% database difference, and that is the initial CACH exchange. And I color it a little bit. ITEAS unreadable. I know that. To show you what is all the interesting stuff that can happen. Namely, you will have packets which are green, green, green, which is the range matches, the hash matches. Life's perfect. Okay? But then you will have stuff where you have mismatched ranges, but the other side will still see see a match. Now why I can say peer mismatch? Because this is implementation code that can look to into both nodes, and they can see will the other node match when I send him that. Alright? So iTEAS kind of like looking to the other side to show me what matches, what doesn't. So you will have CACH packets where the range is green and the hash is green, but the range doesn't match. This range is not generated on the other side. So it has in the sense, you know, go and compare, compute the the comp the hash. You will have stuff where the blue stuff where you have totally mismatched ranges because, for example, one database doesn't have a node at all. No fragments. Right? So you can pack more nodes into a hash. And then you will see how the hash will kind of split that stuff up and the other node will react. And you have, of course, things where, the PRs mismatching on even if the, ranges match or if the ranges mismatch. Right? So the general impression, you see CACHes from both sides. The database is mismatch while things can happen. There is kind of no way to go and match up ranges or or have any kind of no attempt to match up ranges. And clicky clicky. Stuff died. Another bug. Anybody can follow the Microsoft supply line? Okay. So somebody can flip it, please.
[00:47:34] Peter Psenak: I'm
[00:47:34] Tony Przygienda: trying. Yeah. This thing's dead. Alright. So this thing will result in one additional PACH exchange, which are which are equivalent to the PS and P. So the big difference is now before in the CACH, it was just like CSNP. If a range is matching missing, it means I have no nodes. There's a clear semantics. Right? It has the range in front. Things are missing in front. I don't have those nodes, etcetera, etcetera. The PACH is just like PSNP. No ranges. No range of the packet. Each range is independent. They may be unsorted, and they just cover the stuff where I seeing a mismatch and I have to send you more information. So here the blue, if you start to look at the presentation is that it reacts to the other side, giving it a range. Right? And then it splits its own range like, okay. LeTEAS talk in more detail about this stuff that you sent me at mismatches. And in the blue, for example, you see on the right side that it split a range that the other guy sent him over that he didn't have, and one part of the range matches and the other part of the range doesn't mismatch. Okay? Oh, I have I I have to jump back. Right. So from this stuff on at the bottom, the node one, when it gets from node two to the CACH, it finds nine mismatches, two of them with zero fragments, which be basically, I can send you a CSNP saying, here's the range for this node. I have nothing for it. Flood me everything. Right? And some of the ranges, it looks at the range. It goes, I have a lot of nodes. I cut it in half, and I give you two two ashes to be to be more precise. So thaTEAS result in this kind of PACHes. Alright? And already here, when you start to split, you see, okay, we start to talk about single node. So, basically, you end up with seven PSNPs of fragments. Right? Saying like, okay. On these nodes, we don't have a synchronization. We have to synchronize those nodes. None. None of the rest is detailed. Is it worth it? Right? Like, okay. So so you're rambling over all this cool stuff, but iTEAS complexity. ITEAS not overly complex, but it you know, iTEAS iTEAS a good amount of of work to to get the stuff working. So thaTEAS an example that we ran before, which was not such a large database, like three k fragments, 100 nodes, something like that, 10% difference. If you look how many of these ashes PACHes and PSNPs we sent compared to full CSNPs, we only sent about 30% of packets. Alright? If you start to run it on larger databases, 20 k fragments, 500 nodes, about 7.5% difference, you end up about 85% savings once you go really big, like 100 k fragment, 15 k nodes, stuff, really large stuff or even for us, we're running. And 500 fragments different, so iTEAS a classical blip. Right? The link blip blip. Hello up again. The database is very few differences, really. Couple of 100 LS fragments. Then you basically have 92% reduction in terms of packets that you're pushing out the the node. Okay? Now why did we want to the zip hash? That should be halfway readable. So this is the original four original 48 beats Fletcher. The simulation is run over sixty four years, over a 1,000,000 fragments database with 50,000 nodes in the network. The red line is you generate a single CACH for the whole database. Those 70 hashes to cover the million fragments. The green line means you're sending 10 CACHes for the whole database, about 500, 600 hashes. What the the horizontal line says, what is the distance at which a collision will generate a problem? Right? Because the more ashes you send the more hashes you send, the the less fragments you cover. And only within this range you have a hash collision, you will see an effect. If you have the same hash for two fragments which are in different hashes, doesn't matter. You'll never see an effect. Right? ITEAS only they cancel each other if they precisely in the same hash. So the more hashes you send, the smaller the distance at which these things have to collide to matter. Alright. So what what does it mean? The collisions are the blue things. And if this thing is left of the red line, it means that you will be sing sending a single CACH for a database. You will cancel those two fragments, hashes out, which may lead to problems. You you may not synchronize. Right? Duration of this collision is about ten hours. Right? And you see that you have whatever, seven collisions. If you send 10 CACHes, you have something like a 100 collisions. If you go to 48 bit zip, you see how the situation improves already. Right? So if you send one CACH, you will have three collisions over sixty four years, which means iTEAS one ten hours collision once every twenty years on such a database. So almost impossible. You send 10 CACHes, you will not find even a collision. But we went to the 64 bit sip hash, and you see thaTEAS clean, which basically means gives us gives us almost infinite, you know, margin of safety. Because there was a discussion, like, you know, collisions could matter. So thaTEAS why we 48 bit SIP, I think, will be more than enough, but we went to the 64 bit SIP to kind of, you know, quiet the discussion or give people, you know, I don't know, safe, know, fudgy feeling. So thaTEAS the simulation results. Actually, not simulation. ITEAS actually the real code that is being driven, you know, with with according data with different assumptions about note ID, blah blah blah. Yeah. Okay. I think I'm
[00:54:00] Chairperson: done. AC.
[00:54:02] Acee Lindem: AC, Linda Marcus. On slide five, there was a bunch of different percentages. In the table, it says 35% savings. ThaTEAS the previous slide. Yeah. But but in the large example, there's up to 92%
[00:54:18] Chairperson: Yeah.
[00:54:18] Acee Lindem: Of the how how much do you actually save in terms of the p d use used for CSNPs and SNPs?
[00:54:26] Tony Przygienda: Exactly this number. The 92% means if you compare to a full CSNP, you are only sending 8% of packets to synchronize database.
[00:54:34] Acee Lindem: Okay. How come the table has 35 per
[00:54:36] Tony Przygienda: Because the different example is the first example.
[00:54:38] Acee Lindem: Okay. ThaTEAS a simple example. Okay.
[00:54:40] Tony Przygienda: ITEAS kind of the only three k database with 100 nodes. ITEAS iTEAS iTEAS a very small database. Okay. I mean, if you have a small database with a couple of even two, three
[00:54:50] Acee Lindem: k You don't aggregate as much. Yeah. Right.
[00:54:53] Tony Przygienda: That iTEAS not worth the bother. ITEAS not worth the bother. The stuff kicks around probably twenty, thirty k fragments, 10 k fragments. And it also very much depends. If you have, of course, one fragment per node, then the whole thing is not worth doing. Right? Less of the good observation that at such large networks, we'll probably want to issue far more fragments per node, right, because of redistribution, whatever not. But iTEAS kind of an autogonal discussion. I agree with him, but, you know, the more fragments leads to things that we already talked a lot about earlier. Right? Like two system IDs and so on. Okay?
[00:55:26] Chairperson: So I don't have a lot of experience with a million, like, node networks. And I'm curious, what the effect is. Like, what do you when you model this, what is the sort of churn percentage that you model? Like, is it 10% of interfaces every so many seconds?
[00:55:45] Tony Przygienda: No. I churn it differently based on our observation. The more realistic thing is that you basically basically say, you have the lifetime refresh. They start to kick to 65 k, but you have a million. ITEAS not a big number. Right? Just a background refresh. And you then you add to it about, like, assume that every hour, like, one or 2% of LSPs churn because whatever. Link flaps, bandwidth update, bazillion other things. Right? And thaTEAS how I model it to kind of mirror the reality that we see seeing. Right? I don't mirror advanced effects like, for example, the you know, we have this r RSVP bandwidth, the stepping down stuff that we did, which matters a lot. I'm not going to the super advanced effects. Right?
[00:56:29] Chairperson: Okay. Thanks. Mhmm. I think thaTEAS it. Yeah. LeTEAS move on. Thanks. Thanks.
[00:56:36] Tony Przygienda: Thank you, gentlemen.
[00:56:52] Acee Lindem: Okay. I think I'm more awake than I was during the update slides. Okay. For these, I'm Asi Linda from Arcas presenting as a working group member. We had done some collaboration with our partners, Equinix, on this proposal to to provision the active measurement groups sessions similar to what we're doing with seamless BFD. Derek presented this at IETf-one twenty five, and we've had some more discussion requirements and changed the encoding a bit. And there's some options for this depending on what you how how far you wanna take it. And I'll talk about that more later. If you remember right, what we wanted to do was to be able to easily insert new nodes and similar to BSD established active measurement groups. Right? It would initial initially be targeted at stamp and to TWAMP. And I imagine in the future, we'll have the
[00:58:25] Rakesh Gandhi: whaTEAS that?
[00:58:27] Acee Lindem: Oh, I can look at it there. Okay. But it could be targeted towards future. Say we were to have the two way recursive active measurement protocol. What we changed here is we've added a group ID. So you could have the group ID is used to to for having sessions I mean, sessions, having clusters of IGP routers that'll establish these active measurement sessions. And you ask what does this have to do with routing? Well, you use the the measurements from these active measurement protocols in order to do traffic engineering. Similar to with SBFD, you use the reachability to impact routing. Now what we did is we we took the reserve field and we made it this group ID, but there's a lot of different options for what we do with the group ID. And we made the protocol used to be a bit mask. Now iTEAS just a single protocol. So you have one protocol per per sub TLD. Now this is this is this was what I mean, other than asking for adoption, this is what we have. Right now, the group ID is only eight bits. We're thinking maybe we need to extend it to to 16 bits and make it imply both the make it be unique. So you you you wouldn't right now, we're saying that the tuple of the group ID and the endpoint imply uniqueness. Well, well, if we had 16 bits, we could just make that unique. One question was why we just couldn't use the router ID. Well, the reason iTEAS advertised already in the capabilities for IS-IS. The main reason is you won't might wanna measure different paths. You have different endpoints for the paths or you might even wanna measure different data planes and having different data planes for the measurements. For example, SR versus native IP. And like I said, that there's there's there's a number of different ways we can go through these. I'll send an email out to the list of the different ways we're looking at it and encoding this. The bitmap is now just a single eight bit active protocol measurement ID. Act active measurement protocol ID. This really hasn't changed since the last draft how iTEAS used other than the fact that we wouldn't want to establish now that you have multiple group IDs, you wouldn't want to establish multiple sessions using the same endpoints and active measurement protocol ID. Next step, we're gonna ask for working group adoption. And once we get that, I think whatever we agree on for IS-IS, we could just directly put that into the I the OSPF capability router capabilities, opaque LSA and OSPF v three router capabilities LSA. ThaTEAS it. I tried to go fast since I know we're a little behind.
[01:02:38] Tianyang-yang: Rakesh?
[01:02:52] Rakesh Gandhi: Rakesh Gandhi from Cisco Systems. So in t one, in RFC five three five seven, there is a control channel signaling to get parameters from the reflector side. But in STAMP, the control channel signaling is emulated, so there is no way to get the parameters from the reflector. So we are looking at solving that problem because the reflector parameters in STAMP is stable. So to create the sessions, it it will be useful to have the reflector parameters. So we are trying to solve that problem with IGP and BGP extensions, but iTEAS slightly differently than how iTEAS in the draft. So maybe we can sync up offline and see what is the synergy and discuss the problem statements and solutions and stuff.
[01:03:45] Acee Lindem: ThaTEAS that that that would be great. And I'll definitely he couldn't be here today, but I'll include Richard in the discussion too because he's looking at this from the Equinix side of deploying stamp and T WIM.
[01:04:05] Rakesh Gandhi: Yeah. We're looking at the stamp that has no control channel signaling, but you need the reflective parameters and
[01:04:12] Peter Psenak: Mhmm.
[01:04:12] Rakesh Gandhi: ITEAS slightly different way of getting it. And so there is a lot of things common, I think we should brainstorm and discuss how to go about it.
[01:04:22] Acee Lindem: Okay. I'll take a I'll initiate that discussion. Okay. Thanks. Thanks.
[01:04:29] Ying镇: So we'll go to the next presentation.
[01:04:55] Tianyang-yang: Hello, everyone. I'm Tianyang-yang-yang-yang-yang-twenty-two from China Unicom and University of Chinese Academy of Sciences. Today, I'm here to share about our draft- ICE traffic engineering extensions for microburst metrics. Why our network drops packets even when average utilization is low? The main reason is microburst. So what is a microburst? A transient traffic spike causing packet drops even when average utilization looks low. There are two charts on the left side compared steady state performance overview with high frequency periodic fluctuations. We can see that the average is is stable, and the the milli merely second will choose repeated peaks. RFC eight two three eight also mentioned that packet drop, so current result sustained the congestion burst is evenly distributed over time t less than c. We also have a real network data from China Unicom. Let us see the right the figure on the right side. And the the x axis is represent time, and the y axis represent instant speed. And there are four different curves with different colors represent and different statistic window from one millisecond to one thousand millisecond. We can see that in peak millisecond traffic is about four times of average. So the larger statistic time window, the more of the microburst is hidden. So how microbursts are generated and why there is a follow predictable patterns? Here are two figures issues, two course scenarios, microburst. And the first one is speed mismatch. High speed ingress port sending traffic to a low speed egress port, such as and the left figure shows one ten gigabit per second ingress port and one one gigabit per second egress port. And the second one is multiport convergence and such as multiple ingress ports feeding one egress port. As sure as the right figure, two one gigabit per second port and one single one gig one gigabit per second egress port. So there are two root causes. Firstly, excessive oversubscription or sub optional traffic path planning and a not a die create buffer sizing. Here are some background. First, the problem. Existing TE metrics are blinded to microburst. Call screen states, such as delay loss utilization, average over seconds or minutes, will miss miss second level traffic spikes. And active probing cannot scale to the precision. ITEAS person iTEAS prudent to show overhead self inflicted bandwidth and the potentially causing congestion itself. As I can observe utility, hardware now enables the network precision monitoring. More than ten years can monitoring part cues, microburst count at sub millisecond. Generality without aiding probe traffic. And the third x we can extend the IGP and BGPRS with microburst metrics. At the varieties, real time microburst indicators indicators, such as burst account, drop rate, queue depths interval, where as as LSP, enabling in intra domain visibility and the pro package these metrics where BGP areas to SDN controllers, enabling centralized visualization and the proactive control. So why this matters? Microbursts do not always cause drops, but they will affect the data and leTEAS say wrap up for buildup. These metrics expose both loss and the leTEAS say risk critical for finite ARVR financial trading. So with this information, we can make microburst aware pass and the traffic optimization, such as risk, the advertisement, global data collection, dynamic traffic optimization, and long term optimization. LeTEAS see the network topology at the right side.
[01:11:08] Chairperson: In the
[01:11:08] Tianyang-yang: first step, microburser risk metric at the word testament to where IGP extensions. And the second step, unify that data collection by BGP areas to global TD. And the third step controller ex executes primitive path calculation and plus in service the multi traffic steering based on topology and the microburst risk data.
[01:11:36] Acee Lindem: I I have a question relative to this. I'm just gonna interject in the queue. AC Lindum, Arcus, how do you how do the head ends and the controllers they don't know what flows that these microburst correspond to. So how do they know what actions to take based on this advertisement alone? I'm saying you're advertising just the generic fact that a microburst occurred. You don't know what paths to prune, and the draft implies that it can use this information to prune paths or change the the path computation itself?
[01:12:29] Tianyang-yang: Sorry. Maybe I cannot give you accurate answers. Maybe you can email Certainly.
[01:12:35] Acee Lindem: I'll send that to the list.
[01:12:38] Tianyang-yang: Thank you. And then here are use cases and the personal benefits. Distributing microburst metrics where IGP BGPRS provides operators with fine grained network visibility, enabling the following operational benefits, such as proactive risk of visualization and historical births of profiling and the high density warning, and the traffic engineering, such as the might take pass adjustment and the bay traffic routing, and network planning and device tuning, buffer optimization, and the capacity expansion planning. So here are our here is our proposed solution microburst matrix extensions. To bridge the detection gap, we proposed extension to SS, OSPF, and BGPRS to the advertised aggregated microburst matrix. The design adheres to the following principles. First is the aggregate advertisement and the per traffic class visibility, and thirdly, multidimensional metrics. Here are the table is is is OSPF detection, microburst matrix, TRS structure. And nice dives. We are asking for more reviews and the comments from the LSRWT, and welcome interested individuals and operators to join us in future revisions. Thank you.
[01:14:34] Chairperson: Tony. Hi.
[01:14:37] Tony Lee: In your draft in the operational considerations section, you say that operators should be careful about how frequently they advertise this information. Would you care to characterize that in any more substantial way?
[01:15:11] Tianyang-yang: Sorry, sir. Maybe I cannot give you accurate answers.
[01:15:16] Ying镇: Can you send your question to the list, maybe?
[01:15:18] Acee Lindem: Yeah.
[01:15:23] Tony Przygienda: Tony PHP, to use the phrase of my esteemed colleague, which I was surprised he didn't use it, you are just basically dump tracking. You're not using this information for any kind of computation IGPs. They're just using this broadcast mechanism. Not a good idea. Thanks.
[01:15:45] Tianyang-yang: Thank you.
[01:15:48] Jeff Tantsura: Jeff? Justin, so if you want to be able to react dynamically, you need much faster machineries and routing. Low latency, high frequency telemetry exists today. If you want to use it for general analysis, again, by routing, iTEAS not a dramaton. Right? So, use IP fix, whatever is there. So, you are too slow for fast reaction. You're abusing routing for kind of gathering the metrics. I don't think iTEAS the right place for it.
[01:16:23] Chairperson: Thank you. Thanks, Jeff. Thank you.
[01:16:49] Acee Lindem: The one on the right goes forward. Counterintuitive.
[01:16:55] Peter Psenak: Alright. I'm Peter Przanak. I'm going to talk about the DCM that we put together with the authors mentioned in the slide. So what is the problem statement? So the problem statement is obviously not new. We know the congestion might happen in a network. No matter how well we plan it, iTEAS a dynamic thing. And for various reasons, either due to some failures, multiple failures, or some other reasons, congestion may happen. What we try to do is to mitigate the congestion and,
[01:17:37] Les Ginsberg: you
[01:17:37] Peter Psenak: know, help the traffic to flow without being dropped. The DCM is a mitigation tool. It is not a network bandwidth management technique. It is also not meant to be used for a short duration congestions like microburst or anything which is, you know, in a few seconds or even tens of seconds. The the use case that we are trying to address is basically where you have a prolonged con congestion, which you can you can address in in a long term. Okay. So what are the attributes here? So it is a distributed technique, which means that we run it as a part of the IGP, and every nodes in the network only do the mitigation for the congestion that it detects on local links. We do use some information that come from the routers other than the local router about the utilization of the links, obviously. And the reason why we do that is because we want to find a path that is not congested. Sending a traffic from the congested link over an already congested path wouldn't obviously help. So what is the control plane that we use? We use the flex-algo control plane basically because it allows us to easily calculate the topology which is congestion free. When we mark the link, which are congest or links that are congested, we can easily, you know, remove them from the topology, and flex-algo give us all that machinery. We don't need to do any other enforcement. We can use the the seats for that algo to forward the traffic that we are offloading. We do support a case where you have multiple congested link in a network. We can we can do that because of the flexible calculation. And also, what is important and interesting is that the offloaded traffic is natively protected by the mechanisms that we use, you know, otherwise, like LFA or TLFA. So how do we calculate the pass? So when we calculate the pass using the standard flex-algo, you know, algorithm and and and machinery, and we use a UCMP. So we keep the traffic on the congested link, and we move the portion of the traffic to an alternate path. We don't move a lot of traffic. We basically do it in in increments over a periodic intervals where we move a very small portion of the traffic, and then we watch whether the nodes over which we send this traffic are going to signal us something back that their network are now congested or highly utilized in which, you know, we could give us some feedback, and we we watch that feedback before we add some more traffic on the offload pass. So this is described in section seven of the draft if you want to see more details. So from the forwarding perspective, what do we do? So when we want to offload the traffic, we have to somehow enforce the traffic on this flex algo topology that we computed. And the way this is done based on the forwarding plane being in either MPLS or SRV six, we just, you know, push the seats or we replace the seat, the top seat, and then we let the traffic to natively flow. The nice property of this is that we are not just forcing the traffic towards the end of the congested link by some other pass. The traffic takes the native pass towards the destination. So the traffic over the congested link is actually spread around the congested link and it goes to its own destination. So obviously, the first thing that come to mind here is, well, how do we avoid the oscillation? Because if you move the traffic back and forth, then, obviously, there could be an oscillation. We are using two different affinities to signal different things. The one affinity is the congestion affinity. So if a link is congested, the routers would signal that by some affinity, and that would remove the link from the topology that we use for offloading. Well, obviously, if we just use this affinity, it wouldn't be enough because we would overload the link. It would signal that affinity. We would remove it. It would free the bandwidth, and and and the cycle will continue. So we use another affinity, which we call a high utilization affinity. And what it does is that if the link is using a certain threshold of the capacity, which obviously you can define, it will signal it in a form of a different affinity, which would tell the routers that are doing the offloading to not put any more offloading traffic on it. That means the link is not congested yet, but we are preventing it to become congested. And this way, we basically can stop or put some limit how much traffic or offloading traffic we can put on the link. Okay. As as I mentioned, we also use a very small amount to do the offloading incrementally. The the amount of traffic that we offload is calculated based on the lowest capacity link on the path. So we not not necessarily use the percentage from the link, which is for which we do the uploading. But we look at the path, we find the lowest capacity link, and that is where we use our percentages from. And, obviously, there are still cases that we cannot cover with this, and that typical case would be elephant flow where the the traffic that we hashed into these small percentages would pick up of an elephant flow, which would basically then congest the past over which we send it. Then we have some mitigation algorithm basically saying if the offloading path is changing over a certain period of time and times, we suppress it. We don't do the offloading for it anymore for some amount of time or definitely iTEAS iTEAS up to the provider to configure it. So why do we need an ITF work for this? We are using existing mechanisms. We are using flex-algo. We are using affinities. We are using existing forwarding planes. Why do we need any ITF work? ITEAS basically the signaling through the affinities that need some logic which we would like to specify in this document because this is not just a local behavior. We need that signaling to do the local behavior right. So to summarize, we have the the proof of concept done. We have a code. There is quite some interest from the providers. We talked to several of them. They are interested in this. The draft is informational, and we are looking for a feedback. Obviously, there has been the discussion on the list that already started. So but thaTEAS where we are.
[01:25:15] Acee Lindem: I guess I'm only in the queue. Hey, Cindy Marcus. In reading this just the first time, my question was, why a separate flex algorithm and a d you know, an alternate was it DCM flex algorithm as opposed to a single flex algorithm that took congestion as one of the metrics that it used to place and move paths. I mean, you'd still need you'd still need the signaling, but why two algorithms rather than one that handled the congestion?
[01:25:59] Peter Psenak: Which two are you referring to? We are talking about one.
[01:26:02] Acee Lindem: No. You have your regular flex-algo thaTEAS doing the normal routing based on destination, and then you have the DCM Flexalgo. Why not just have the normal one do the congestion?
[01:26:21] Peter Psenak: Because if you do the normal one and you look at the congestion, then if you remove the link, you'll lose the pass. Right?
[01:26:29] Chairperson: Okay.
[01:26:30] Peter Psenak: I So you have your native topology over which you send your traffic, and then you create one which is guaranteed not to be congested over which you do the offloading. And then to enforce the traffic because the other routers on the past don't know what they are doing is we use that algo seat. Okay.
[01:26:49] Acee Lindem: Yeah. I have to think about it more. Like I said, I only read it once. So
[01:26:52] Peter Psenak: Sure. We can discuss. Lee?
[01:27:05] John: John from Huawei. I think could you please go to page seven?
[01:27:14] Peter Psenak: Page 27. How do I know? I don't know. There's no numbers here.
[01:27:20] John: Yes. This page.
[01:27:22] Peter Psenak: This one?
[01:27:22] Chairperson: Yeah. Yeah. Yeah. Okay.
[01:27:24] John: Okay. This page, right, thaTEAS a congested links are excluded from the OFA. So my question is, will this lead to very frequent change in the OFA because links may be congested or not congested because of some of burst traffics. And this also may lead to significant compute computation board on the routers because the routers are needed to recompute the SPF very frequent.
[01:28:06] Peter Psenak: So if you want to do any bandwidth management, you need the information, whether you use it advertising the bandwidth or what I mean, you need to you need to inform the other routers. Now we are trying to get to the state where we are actually creating congested links because we would first go through this high affinity state, high utilization. And that doesn't mean any calculation. Right? ITEAS just basically signaling don't put anymore, but the topology doesn't change. So before we go to signal that the link is overloaded from the perspective what we are trying to do, we have some measures to actually avoid that state to even reach that state. But if the link becomes congested, you want others to know.
[01:28:51] Chairperson: Okay. Thank you.
[01:28:57] Ka: Hello. This is Ka from Huawei. And my question is that you use a Flex-Algo to do the offload. But in fact, the Flex-Algo number may theoretically, it may be one hundred and twenty and twenty eight Flex-Algos supported. But in fact, the device may only support h two sixteen Flex-Algos. So if you use the Flex-Algos to do the offloading, then the Flex-Algo number may not enough to do other algorithms. What do you think about this?
[01:29:38] Peter Psenak: So as I responded on the list, typically, people use very few flex zalgos. If you have hundreds flex zalgos in your network, then I would question the design. Now even if you have few of them, there is no need to do the offloading for every single traffic type. Typically, one would do the offloading for the majority of the traffic, which is your best effort traffic. Right? For example, I'm just giving a theoretical answer here. ITEAS up to the people to decide what they want to offload. There's absolutely no need to do the uploading for every algorithm you have in your network.
[01:30:20] Wei Chang: Hello. Wei Chang Chang from China Mobile. Yeah. I I think iTEAS a very good solution from operators' perspective. I have a simple question. In your draft, you mentioned the the DCM does not handle the just to handle the the long life, the contrasting. So how can you determine that is a microburst or long lived contrasting? So how can you determine that has
[01:30:56] Peter Psenak: So alright. So there are many parameters, and some of them are mentioned in the draft. I tried to put as much as I could because we did a lot of experimentation, you know, with this. We didn't just come up with something that we think may work. We actually did a lot of experiments, and and we have something that we believe may work. So you can you can decide what is going to be your rate interval in which you measure the convergence, and then you have the offloading interval is the the the the interval at which one you want to move the traffic, either add or or offload or remove the offload restore. Now, obviously, you need to set up these parameters reasonably. You cannot have your sampling frequency to be lower than your offloading frequency. Right? So but you can you can really define this. My view of this is that you don't really want to do the offloading every second or even five seconds. You may want to do it maybe every thirty seconds or every sixty seconds. Do it slowly. Make sure that the network can actually signal you back. Right? So iTEAS up to you what you define. We are not talking about reacting in seconds. This is not the use case. We know we can't do it. Right? So I would say tens of seconds is probably the best you can do.
[01:32:14] Wei Chang: Sorry. Furthermore, so you know congestion is a change frequently. Right?
[01:32:20] Peter Psenak: Yeah. But we are not interesting in that. We are not interested in short spikes in the in the in the link utilization. We are looking for a use case where I have a link. It is typically used 50%, and suddenly, it is being becoming 95. That is the use case, and it stays there for hours.
[01:32:37] Wei Chang: Yeah. My question is that even for hours long live congestion, maybe it will go over at some time. Will you go back Yeah. The original
[01:32:50] Peter Psenak: Mhmm. Yeah. We we so so we we offload and we restore. We look at if it goes back to a certain threshold where we declare iTEAS not anymore congested, we will slowly move the traffic back. But, again, slowly, not in one shift.
[01:33:01] Wei Chang: Okay. Thank you.
[01:33:04] Ji: G. From Huawei. Yeah. I have a question about the type of this document. You say iTEAS informational or standard track?
[01:33:13] Peter Psenak: Well, I guess iTEAS too early to talk about this. You know, honestly, I'm not the fan of the drafts which don't specify anything which is needed for interoperability. So I would never write a draft like that. Here, you may you may even argue there is no protocol extension here, but we need that signaling.
[01:33:32] Ji: Yeah.
[01:33:32] Peter Psenak: Right? Because if that signaling doesn't work but, I mean, I can see some people saying, no. Well, I'm fine. Right? Because, strictly speaking, there's nothing new here. We are using everything which is already existing. But I think to describe the behavior that we need to make this solution work, that is why we put this draft together. Now whether this becomes whatever type, I don't really care at this point.
[01:33:55] Ji: Yeah. I I also think this is some new signaling in this mechanism. Right?
[01:33:59] Peter Psenak: No. There's there's nothing new from the protocol itself. Yeah. Not ITEAS more of a procedural thing.
[01:34:05] Ji: Like this high utilization affinity, if it is signaled to other node, they need to understand the meaning and to do this, like, stop sending more traffic. This is something not the time in the past. Right?
[01:34:17] Peter Psenak: So if you if you go to the draft, there's this section eleven one, which I call a mandatory requirement. This is basically what this draft is trying to say. All the rest is local behavior.
[01:34:28] Ji: Yeah. So they need some interoperability with other nodes. Right?
[01:34:32] Peter Psenak: For for a correct functionality, yes. But there's no Okay.
[01:34:37] John: Yeah.
[01:34:37] Chairperson: Thank you. Jeff, you're you're you're you're the lock. Just consider ITEAS a privilege.
[01:34:44] Jeff Tantsura: Peter, have you looked into interactions with kind of local marking, things like ECN? Router is going to do something when I observe the congestion. Right?
[01:34:55] Acee Lindem: So But
[01:34:56] Peter Psenak: I guess that is more for, like, a data center where you need a fast reaction. This is more for a van network, which doesn't need that fast reaction. We are not talking AIDC here. Not at all.
[01:35:09] Chairperson: Okay. Anyway, Jeff, you you were after the lock. You're a chair. You know better than that. Thank
[01:35:17] Peter Psenak: you. Thanks.
[01:35:22] Chairperson: Okay. Can you hear me?
[01:35:27] Chairperson: Yes.
[01:35:28] Chairperson: Hello? Okay. Okay. Good morning, everyone. I'm Tao from China Income. And I'd like to present to this presentation. And first, I will recap the SRV six egress protection mechanism briefly, which is in the in RGGWG chapter. Then I will spend most of time on the edge being coding over this draft because the two jobs have a tighter relationship. Okay. Next slide, know. Okay. Help me to the next slide. Okay.
[01:36:14] Acee Lindem: ITEAS just human nature.
[01:36:16] Chairperson: Pardon? Someone heard me change it to the next slide.
[01:36:22] Ying镇: You have control.
[01:36:23] Chairperson: You should have control.
[01:36:26] Chairperson: Oh, okay. I can. Thank you. Okay. LeTEAS start with the mechanism. First, in the I've seen nine eight double five. The top ridge independent loop of the alternate and protects the transit nodes and the links, but it does not protect egress node or the egress link. To fill that gap, the RTGWG jabbed as r v six egress protection defines the mirror seed that is end dot m endpoint behavior type 74. When the primary egress and just like the fecal and the PA fails, iTEAS a protector PB use uses the mirror seed, vape contest to reproduce the PA's egress forwarding table. So the protection mechanism itself is already defined. And so I want to repeat it in detail here. Now leTEAS see whaTEAS whaTEAS missing for the point of the local repair. We we can call it a p I r for short and to per computer a backup pass. The protector must first signal the protection relationship. Concretely, PB must be the tube, PB, PA, and the mirror seat, plus the protected locators through the IGP. Now no IGP encoding. ITEAS just the fullest. That gap exactly what the lead job fails. The SIS and OSPF with three encoding. So to be clear on to be clear on scope, the this tech talk is about the IGP encoding only. The mechanism and the door end behavior and PLR procedures all live in the RTWG draft. Okay. So, conversely, what must the the IGB carried? Look at the top bridge, primary Egress PA and its protector PEB. When PEB fails the PIR, in this figure, iTEAS the p one here. Needs a backup backup pass to PEB. And that pass is keyed by the mirror seed. Two things must be advertised. First, the mirror seed itself, s r v six and the seed, and the door m behavior 74 configured on PEB and identifying the favor contest that replaces the failed PA's egress forwarding table. Second, protected locators, the locators over the primary egress PA. And and the one key design decision and granularity we advertise at a local level, not per seed and per services. And this is a delivery located located level gradually keeps the with high information compact and bounce IGP flooding and the convergence cost. That is the complete requirement the encoding has to meet. Then here's the encoding at a glance. Both the IGPs follow the same pattern with only minor syntactic differences. We'll use the existing SRV six locator TRV as the parent and the existing s r v six and see the sub TRE as the carrier for. And he's in the RFC nine three five two for this. So and RFC nine five one three for OSPF v three. Into it, we add exactly sub sub tier V for SS and sub tier V for OSPF v three. Next, exactly one protected locator's container. Okay. LeTEAS start with the ISS. In order to deliver the mirror seat sub tier information. We'll reuse the s r v six and the seat sub tier way. Sits inside the s r v six located tier way of IFC nine three five two. Its fields are already defined in IFC nine three five five two. I want to repeat it again here, but we should focus on the endpoint function. It must be 74 and dot m. Then the seed fields, it is the 16 octides mirror seed here and must not be zero. And, critically, iTEAS sub-trov carries exactly one protected locators, sub-trov, not zero, not more than one. Then the protected locator sub sub tier way type leads to be designed one, such as the one. Here, we suggest the one. It has a one architecture locator size running one to 128 bits, followed by the locator value, one to 16 architects. Variable length, multiple locator entries are allowed, and any trailing bits must be zero. ThaTEAS is the complete it is a different definition. And then the six slides are just more or less the same to the easiest or straightforwardly, and so we don't And the second one, the last field and the nest container and the pandatory. And the one advertised over is it and the two advertised over p f v three are defined in the patents. And so, finally, on IAN code point request, we request code points in both register For SS, a new registry for protected locators, sub sub tier way with suggestion value one. And for OSPF with three, a new register for protected locators sub tier way with suggestion also value value one. Okay. To summarize the leads draft to define the SS and OSPF with three, HP coding for the s r v six mirror seed egress protection information. It complains the RTGWG magnet is dropped. And here is the key message. This draft must be kept in line with s r v six egress protection. Okay. And so what do we ask the working group? I think we have the full full request. First, please consider the adoption by ELSA, and the second, on the theory formats and including choices. And the third, help us align with the RTGW drafts finalization timeline and both coordinate the IANA assignments across both drafts. Okay. Thank you. I'm happy to take any questions.
[01:44:11] Acee Lindem: Speaking as working group chair, see. There was one comment from us that you could reuse some existing sub TLVs. Did you I didn't see you responded to that yet.
[01:44:29] Peter Psenak: Oh, you did?
[01:44:30] Acee Lindem: Okay. Yes. Okay.
[01:44:31] Chairperson: Yes, Elise. We did it.
[01:44:32] Acee Lindem: Oh, it changed it. Okay. Thanks.
[01:44:33] Chairperson: See that. Okay. Thank you. I
[01:44:38] Acee Lindem: think that well, I think I think especially since this has been in routing working group for seven years, maybe we can ask for adoption on this one. I mean, the companion doc document to do the egress protection. Then we won't have to see that picture with p e a and b and p one and two.
[01:45:03] Ying镇: Okay. I see.
[01:45:04] Chairperson: Okay. Okay. Thank you.
[01:45:09] Chairperson: Okay. Thank you.
[01:45:13] Chairperson: Who's who's presenting next? Who's presenting this? Shradda, Tony? Ah, Shradda.
[01:45:29] Shraddha Hegde: Yeah. Yeah. Can you hear me?
[01:45:32] Chairperson: Yep.
[01:45:35] Shraddha Hegde: Yeah. So this is the new draft on originator sequence number checksum. I'm representing a little on behalf of my coauthors. So we look at the problem statement and a brief into the solution. So the problem that we're trying to solve is information moving across fragments. So if you see on the left side, there is a fragment one with sequence number s one, and it has adjacencies one, two, and three. And imagine a new feature is being enabled on the router. It could be for example, s r v six is being being enabled on the router. So additional information such as adjacency SID has to be associated with the adjacency. So and all three adjacencies, you need to advertise an adjacency set. So the size of these each of these PLVs grows. And there is not enough space to accommodate all Excuse me.
[01:46:40] Acee Lindem: Can somebody pull the back door closed? Thank you.
[01:46:44] Chairperson: And if you leave, please shut it after you leave.
[01:46:49] Acee Lindem: Okay. Sorry, Shardra.
[01:46:54] Shraddha Hegde: Yeah. So if you see on the right hand side, there is this fragment one has been now changed to sequence number s two with just two adjacencies one and two, and adjacency three has been moved to a new fragment two. So this is when this happens, the node which moves this information into another fragment will update both these fragments and then flood both of these into the network. And on the receiver side, because of the asynchronous nature of the flooding, it can so happen that on the receiver side, it they arrive with a certain time difference. Either first one could fragment fragment one could arrive first or fragment two could arrive first. If fragment one arrives first, then it it appears on the receiver that, you know, adjacency three has gone down and has been removed. And so it will trigger the SPF or or TED update or the BGPLS updates. Whatever action in the router takes on the changed fragment, you it could result into undesired behavior, such as route flap or next stop change and so on. So the idea here is to is there there's a new TLV being proposed, which is called originator sequence number checksum TLV. So it what what is being sent in this TLV is the checksum of the originators self generated LSPs. So you can see iTEAS a 64 bit SIP hash computed on LSP ID sequence number and size of each LSP fragment of the originator node. So when so this this t new TLV is included as part of each of the fragment, and then this information is being flagged whenever that LSP is reoriginated. So, yeah, so this sending procedures when the an LSP fragment is reoriginated, the sequence number checksum is calculated on all the self originated LSP fragments, and this information is included, LSPID sequence number and size of the each LSP. And there's an order to it. It is in the increasing order of LSPID. So all the self fragments as well as well as the pseudo node fragments are covered. And a node should not reoriginate fragment when only this this TLV changes. Right? Because leTEAS say fragment one and two are changing, but there are also other fragments, three, four, five, which are not changing. But in order to in include the changed see, check some there's no need to originate and flood those fragments as well. So only the fragments which were the really the other information except this o c OSNC TLA has changed. Those need to be changed and flooded and OCNC recomputed. So on the receiving side, when a LSP fragment contains this TLV, so the receiver computes the check sum sequence number, check sum in the same order that is prescribed on on its local database plus this received fragment. And if the checksum doesn't match, then it it it can wait until change fragments are arrived. And what actions you it it takes, whether it delays SPF, whether it delays state update, that is up to the implementation. Implementation can choose to take any of these actions. And there must be a configurable timer for the upper bound so that the wait time is not infinite and which will be resulting into database being not being synchronized. Okay. Then the the draft talks about some of the concern on handling continuous churn. So one point is there is a upper bound on, you know, how long the receiver waits configurable upper bounded digital timer, which kind of prevents, you know, the conversions being too long due to the continuous churn and the c check sums not not being in sync. And then there is also a section on like, if there is a continuous churn, and then it can fall back to the normal processing and not on the receiver side, it can fall back to normal processing and not really look into the checksum matching checksum because, you know, when there is a continuous churn, iTEAS it may not really help doing all these calculations and affecting the conversions. Porched LSP, so iTEAS recommended to include this in the Porched LSPs as well, the OC OSNC. And on the receiver procedure, procedures for the purge LSPs would remain same as in as in for other LSP fragments. So there was some good discussion on this in the mailing list. And based on comments received so, basically, the comment was from less was which is very valid. Like, if there are three fragments changing and and the third fragment has arrived, and the first two fragments are are having older checksum, then it will never match. So although as per this draft, it will fall under the default timer and then would get computed, but I think we can do it do better. And then we have had some discussions on including a global sort of a ID, which kind of tracks each of the transactions. So we will update the draft with the relevant information and then send it to the working group for review. And there is also a sort of you know, you you can optionally do it only when you when when there is a when the sender has movement the information moving from one fragment to another. So that could be indicated in the TLV with the flags. So on the receiver, you know, action can be taken to only look at the checksum when there is this flag set. So those are the details that we will update. And on next steps, yeah, we will once the draft is updated, we'll share with the working group, and we'll request for more review and comments.
[01:54:03] Peter Psenak: Go ahead, Chris.
[01:54:07] Chairperson: Okay. Thanks, We're gonna try to fit one time permitting, and that one is first up is process ID. So I don't know who the presenter is.
[01:54:24] Acee Lindem: We had some really good discussion on this sequence number. I mean, this fragment checksum or whatever, hash draft. I think leTEAS just keep up the good discussion.
[01:54:39] Zohua: Is that okay?
[01:54:40] Ying镇: Hello,
[01:54:42] Zohua: everyone. I'm oh, I will introduce very briefly. Hello, everyone. I'm Zohua from China Tech Out. I will introduce our draft about IS-IS precise ID verification. As we all know, I iSisisisisisisisisisisisisisisisisisisis protocol instances running on a single router. It does not affect our serve as a criteria for iSisis neighbor agency establishment and is not transmitted to to neighboring routers and does not appear in any IASI's PU. Importantly, IASI's Potash ID to typically use that for route control, such as root redistribution or root filtering. That means where the IS size for SAS ID is locally significant, the routing control logic bound to it is globally affecting. The motivation is as follows. Operated networks typically adopt a hierarchical design model consisting of axes, core, and aggregation layers. To achieve routine installation, a single ISS domain is used within each layer while interlayer while the root import or export is controlled via ISS process ID for operators such as the Tano Telecom to ready to reduce configuration and maintenance complexity. So interface within ISS domain are usually configured with the same ISS process ID, where different domains use different ISS precise IDs. In that case, if the ISS precise ID within domain is misconfigured, it may lead to routine loops with difficult troubleshooting because the ISS agency remains up. Here is a simple topology of channel telecoms IP network. Like, leTEAS focus on the IP metro network part. So agree aggregation layer deploys the IS-IS domain domain x with processor two, and the core layer deploys the ISS domain y with processor one. If the interface on SPAN one that connects to SPAN one is misconformed to belong to process two, This causes the super span one's roots to be directly advertised to alief aliefs through span one. And under the same time, if the span two is still advertising the received aliefs roots to span one, It causing the routine loops. So feasible solution is to verify why does the I ISI's process ID within domain are consistent before establishing an ISI's adjacency. So our document proposed the two options. Option a defines a new process ID IPLV, which carried in the ISI's hello p d u and contains a 16 bit process ID field. If both eyes in circuit support the process ID TROV, the process ID carried in process ID TROV will be verified alongside the area address, the system system ID, and other validation information during the IS-IS agency establishment of precise. And the option b extends the IDTROA. RFC eighty two zero two defines the IDTROA to carry the instance identifier and IT IDs. The ID TLA identifies the unique instance and instance specified topology or topologies is carried in all iSisi's I d PDU. And iSis PDU associated with the standard instance must not include an ID TOA except where noted in this RFC. So our document extends the applicability of ID and introduce a new sub TOA to carry process ID information. It permits the standard instance to advertise the ID TROA with ID zero in the ISS Hello PTU, and a new process ID sub TROA is specified to carry the process ID within ID TROA with the same format as option a. Additionally, option b could smart the precise ID verification by merely upgrading the extension for the standard standard instance without requiring for multi instance capability. So we are now looking for discussion from a working group. First, which option is better? Option a or option b? And second, that the same requirement also accepts for OSPF. We'll come for suggestions and comments, and we will continue to improve the document. Thank you, Robert.
[01:59:36] Chairperson: Go ahead, Les. I think you might get the only comment given the time.
[01:59:40] Les Ginsberg: Okay. So, basically, I don't think this is a good idea. ISS already has area addresses to make sure that instances only form adjacencies with the expected peers. You're simply adding information that the protocol has no use for and maybe iTEAS nice to have for management purposes, but it doesn't belong in the routing protocol.
[02:00:07] Chairperson: Tony, do you wanna
[02:00:11] Tony Lee: Ditto. Process ID is really an operating system concept. ITEAS got nothing to do with the routing protocol, and it should be 32 bits at the very least.
[02:00:22] Ying镇: Do want to say something quick?
[02:00:27] Chairperson: Okay.
[02:00:27] Ying镇: It you want to say something quick?
[02:00:40] Chairperson: Worked for everybody else, but just talk.
[02:00:43] Sasha Weinstein: Is it on? Okay. Sasha Weinstein. There is already an a published RFC eighty two zero two, which describes IS-IS multi instance. I wonder why this shouldn't be used in this case.
[02:00:58] Chairperson: Well, that was his option b, but and it look I don't think we're out of time.
[02:01:02] Acee Lindem: AC Linda Marcus. I was just gonna say the presumption here is the routers don't support multi instance. But if they have to support this new CL TLB, they could use the multi instance TLB and only support one instance. And you're problem solved. Thank you. Thank
[02:01:22] Chairperson: you. Alright. That is runs us out of time. So Yeah. Thanks, everybody.
[02:01:29] Acee Lindem: Oh, we got some action items on, especially, it seems like there's a real the power yeah. We didn't finish our agenda and and on the power group getting bringing that to a resolution.
[02:01:44] Chairperson: Well, we did finish our agenda as far as what we plan to it. To fit. We may we we were talking about possibly doing an interim. If if there's interest on the list, leTEAS see where the the drafts that were in, time permitting, how they're received on the list.
[02:02:02] Acee Lindem: Yeah. We gave a agenda shortfall warning.
[02:02:08] Chairperson: Thanks, everybody. See you at the next one.
[02:02:11] Acee Lindem: Or the interim if we have one.
[02:02:21] Chairperson: Be careful. This is gain on this thing. I I don't think that thaTEAS gonna be the case. And and I suspect it I don't know if you noticed my comment, but when I said, like, there's eight, you know actually, Ying Zheng had a good idea of, like, come up at yo. Please come up to the mic. Was that you that said that? Yeah. Yeah. Yeah. Because, like, I think you're it was a a lot of plus ones from the same
[02:03:01] Ji: Yeah.
[02:03:01] Chairperson: At at email address.
[02:03:06] Acee Lindem: Hey. There's our man.
[02:03:08] Ying镇: Hello? Are you are you on vacation this week? I don't know. You you never need to retire. You just take another vacation.