Internet Engineering Task Force Interim Meetings, 24 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-IDR-20230424-1400

Description

IDR meeting session at IETF
2023/04/24 1400

https://datatracker.ietf.org/meeting//proceedings/

A

Where you're going to present the slides.

B

And that your elbows, actually here, He's listed in zuluboli at the moment, okay.

A

B

A

The go ahead, it's a top of the hour. Shall we wait a few more minutes.

B

If we could we're still missing some of the actual presenters, it's working through the list.

A

We don't have prakash I, do season, 10.

B

Yep he's already confirmed.

A

And and ah Hong XI I don't see Hung She, yes, I do. How could you confirm your mic? Try to say hello.

A

Cara says he'll be momentarily, he's got com, connectivity issues, so I think we ought to give it a couple moments. Country.

B

Okay, no response and last of the actually two more sets of presenters we haven't heard from Yi. Could you please test your microphone.

C

B

Hi we can hear you you're slight you're slightly fake, though.

D

B

That is much better now. Thank you.

A

D

Increasing your mic, okay! Thank you.

A

Did we get to Ren shin.

B

Do we see him yet not.

A

B

Okay, so we're short grandchild.

A

Looks like care is in, can you test your mic care.

E

C

A

Good morning, good thanks good morning, they.

B

Can hear you so hanchi is the last person that we haven't heard from.

A

So we will probably give it three more minutes and go ahead and start. We have about an 80 minute discussion and about two hours. So we have time for discussion on each point.

B

Okay, we saw the time she was trying to test Mike give a hungry remote.

B

And she is offline and restarting looks like, and this is why we do all this up front.

F

So as long as we'll do this, can you hear me.

B

You are loud and clear.

A

Great wonderful Alvaro.

B

Okay, once we've heard from hongshi, we can begin soon, I think.

B

Student, that's Iran channel. Here, though,.

A

B

Create an open microphone and we now hear you: okay, good.

A

Thank you we're glad, thank you for uh all our presenters for uh speaking into the mic. This is uh no well. Hopefully all of you have seen it. If not. uh This is a reminder that the ITF policies are in effect, such as patent or code of contact. uh This note is just to point you in the right direction reminder if you're participating you agreed to follow the ITF process and policies.

A

If you're aware of any contribution that's covered by Patent or application, you must to close that fact or not participate in the discussion uh and as a participant in ITF activities. You acknowledge that any written, audio, video or photographic, whatever records of the meeting, will make public and uh personal information you give to. Itf'd is handled as accordance to the ITF privacy policy and we agreed to work with one another. Please, if you've not seen this read it once because we have a little extra time.

A

I've actually gone through it and said, say, see your note. Well, our agenda is meant to cover presentations that didn't make it to ITF. Once in time time slots you can get the materials there you're on the meet Echo I'm sure that uh G and your chairs would love it. If you help with any note-taking, especially if you're a a presenter, please make sure we've got any comments you want to make sure. Are there. Our agenda is ahead, we'll start with anchor we're going to go with first adjustments to standard bgp timers.

A

Then one administrative domain flow spec drafts bgpls draft and constrained RT drafts. So with that we're going to hand off uh the presentation to Anchor, so you can grab. Have you grabbed the slides before anchor and been able to pick them out.

A

I'll, pull up the slides and then you'll have control up, looks like you've got a deck.

G

Okay, how do I grab it? Okay,.

A

You can grab it. I can grab it for you. If you want and then pass control, how.

G

To grab it I'm sorry.

A

Okay, I will get the slides and come back just a minute. Okay,.

A

Let me know if I've got well. Hopefully, I've got the latest one here.

A

G

A

Go ahead and you should have control of the slides. Let me double check for you.

A

Okay, I've passed control to the slides for you. Let me.

G

Know if you have trouble controlling.

A

G

All right, okay, thank you, so uh good.

E

G

On the east coast, in the US and good afternoon, for folks in Europe and good evening for folks in India, China and the other Asian countries uh all right, so this the topic is applying TCP user time Mark parameters to pgb sessions, uh presenting presenting on behalf of myself and the course Robert razuk, uh all right, uh just click on the next page. It's not moving I think I'm not familiar with this Sims.

G

Okay, it's good! Okay looks like there's a delay. Okay, let's uh let me start with uh by talking about what it is the TCP user timer is. It's.

H

G

It is it's a very, very uh basically old concept. It's actually defined in the pgp in the TCP based spec, uh I, see 0793 and also with the latest, updated IC 9293. It basically says you with this timeout you. Basically, the TCP connection should be terminated if it's not progressing using this specified. Timeout duration.

G

So the interim this, uh if you look at Let's uh I, think what is particularly relevant is about the delivery of of application data by TCP. They are basically they are really uh different um types and Concepts one is basically is the transmitted data. It's basically, the the data has been transmitted by the local TCP and it's waiting for acknowledgment and the second one is buffer data. Basically this if the data has not been transmitted, it's waiting to be transmitted because the remote side has advertised a zero size window, TCP window so locally.

G

We can understand anything, although this is there's a slight confusion. I think in some of the in some of the uh the document that reference this gcp user time. It's basically, it didn't really call out the second part, but as far as application is concerned, there's no difference between these two cases. Its application data is not delivered within certain period of time. There's no difference at all right so this that so that the user timeouts would apply equally in both cases.

G

As far the application is concerned,.

G

All right, so it's a so there's a there's at least one implementation that I'm aware of and for other implementations are basically I'm, not.

G

I have not asked people around about other implementation, but there's a there's a Linux implementation. This is just an example, and so it's basically, if you look at it, is the implementation you introduce uh uh a TCP socket option called The tcps Go user at school, Time March. So basically, application can simply call this safe stock option to enable this, the timer value is specified in milliseconds.

G

And also, if you want to Let's retrieve the the time and value you can do a gay stack option using the using the same uh TCP user time options, what it does that, if, if basically for the for the two cases that show in the previous slide, if either of these in either case, if the, uh if the data is a user application data, is not delivered using the specified camera value, uh it basically will return easy timeout, uh the error to the application in the in the TCP, the read or near Circuit read or write operation.

G

It's just like any other circuit errors like if the remote side, a closer circuit you, the application locally, would receive e-packed. So it's this is this. There are. There are a number of errors that the application has to deal with. This would be. One of this would be a new addition, obviously stacking option. There has been. uh Basically there has been a couple of bug fixes to the implementation and which I I, actually um I, basically fix them myself and was committed around January of 2021.

G

It has been actually more than two years ago and a debate. It's shipped in Linux distribution, 5.4, Dodge, I, don't remember the the minor version there and there are two of them. These are the hashtags for the other applications for the other. Basically, uh TCP is stack. Basically, if, if let's say currently, if it does not have a Implement, is that if that has implementation, I would think the implementation. Actually, it should be straightforward, because this is not just. We are talking about the implementation of timeouts, it's basically, they are also.

G

They are typically three operations. You start the timer, you basically reset the timer or you do the measurements. It's uh you know it's. It's really does not require any optimization um or complexity. It's fed forward, there's no magic there, all right so um advisor BEP is concerned. So there's a this. Is this this concept I think fox called? It is the stock sessions for bbp. It basically simply means that PG messages are not delivered for exit extended period of time.

G

This can result in steroids in the writing system, and so this is reasonable and desirable to have a marketing to detect these situations and also terminalization and I mean currently I. Think the problem is mostly mostly speculation due to the lack of Auto automated detection mechanisms in the in the implementation in pgp implementation today.

G

But this this can happen. So this is, if you look at if, if that's a problem definition, then CCP user timer option it's it's actually very good fit because it's specific defined for this.

G

This type data delivery issues, and if this is with this option the detection- and it's it's much more deterministic and precise- it's basically, it can do a much better job than PDP itself, because informal implementation for the implementation of my health is a bgp itself actually does not have enough that much visibility into the TCP State, whether it's interesting transmission mode or how long it has been. It's simply does not know, and with this TCP option that it will require minimum code changes in PDP.

G

Excuse me so as a spell out in your spec. Basically, we are. We have made several recommendations. We, of course, we recommend using this TCP user timeout option and the default time value is that I mean in the graph is basically, as the current specifies five times, the whole timer, but not less than two minutes, and obviously this should be configurable.

G

And another point is that, basically, because when the PDP comes up depends on the the number of sessions amount of data that need to be exchanged, it can be quite heavy computation wise. So it's so we basically recommend that you enabled this enable this option only after UI is received uh from from all the neighbors uh also remains posts, decision establishment and to basically to mitigate some of the possible Force positives.

G

Basically, we say you follow the gr procedures uh for this year, timeout this error and the longer the log, the events and because this is the most most likely attribute attribute to both to the remote to the implementation of the Remote device. You basically, you work with the peer alert, appear, administrator and work with them, basically to uh for its resolution and the next slide.

G

Obviously, your feedback is welcome and we also I would like to request the working group adoption that completes my presentation.

G

So do we take the questions right now or when at the end, it's.

A

G

Okay, yeah, if you have any question, please feel free to ask right now: question or comments.

H

Hi uh Ben, uh you know in the other uh proposal for this uh I'm curious on how you uh came to 30 minutes on your. If you go back a couple of slides. um Oh these were these.

G

Are timers uh I think several of them? We obviously this should be configurable. It's just uh I think as a common practice for most of the uh most of the the time that armor related values and most of the time we recommend the default. So that's 30.

E

G

Of fields like it's long enough for the writing to converge after basically the pgp comes up, but if, if we, if we your particular configuration, basically it requires a longer time. You definitely should should configure that way. So it is. These are not basically hard-coded. They should be configurable. Okay,.

E

G

If, basically, your environment is really a small scale, you probably want to reduce that, because if it takes one minute for everything to converge, then 30 minutes seem to be a very long time.

G

Okay, you know, as we all know, bdp is used basically from the small to to medium to very large scale, so there are lots of configurable parameters this. This will be. One of these several time around the body with uh would be would belong to that category.

A

Go ahead. Randy you heard comments.

I

So let me make sure I understand. Thank you. Essentially, what you're saying is TCP provides this don't further complicate bgp question.

G

Mark, yes, Roddy, that's pretty much. The message there's already exists. You know uh a very nice. You know mechanism for doing that at the TCP can do a much better job than PDP, because the TCP is number is, is the transport for us right for PDP? It actually certainly has has all the information necessary information to deal with it.

I

Sounds good to me. Thank you.

A

Any other comments, questions.

G

You see I was amazed that actually the TCP was developed with 30 at least 30 years ago, and actually the uh the folks actually had a vision about this kind of problem and they actually introduced a magazine for it. That is quite amazing. It's a point of it's a it's another addition to the all the amazing work that has a basically put into the TCP.

A

G

That's the comment, that's it for me. Yeah.

B

So the apologies, if I'm difficult to understand uh so for cases where TCP is misbehaving, and that includes like firewalls. This has good value, I agree, but I don't think it's no. The core use case, that's necessarily applicable I. Think the second presentation will get into some of those details, but I think the this problem space is being discussed, has two partitions one place where ECP itself is misbehaving, which this addresses and other cases where TCP is properly behaving, but the application is not properly behaving basically.

G

Definitely Jeff I'm, just thinking that you know, although you understand in the in the draft I thought of least the example where this could happen, it feels I feel like it's more like a hard crafted scenarios, and you know these- uh it's it's very hard for me to actually imagine this kind of problem would occur without having a park in pgp implementation, because if you look at it, the pgp has its own keep liver. People keep live timer, it also have into whole time the whole timer definitely should have TDM it's hard to imagine.

G

The remote side actually keeps receiving TCP no keep not to keep receiving, keep saving TCP the PDP people lives, but another region, the pgp people live ad, still keeps the sessions up running and the whole timer does not kick in. It's very is I would think this. This is really forced into very, very Corner cases of some kind of either crafted scenarios in the lab or some nasty implementation bugs.

G

This type of visual right, it's very hard to imagine it's actually a TCP issue.

B

Yeah so I'll offer my commentary that for my 28 years, worth of working at bgp I've run into at least three implementations that have no issues with TCP and it's strictly vtsp read applications in the vgp stack, that's the problem, so we have different experiences. You know again, this has value, but I, don't think it's the total solution. Thank you.

G

Yeah I mean we look out today: okay, the network in internet as a engineering.

A

G

Works well. Actually, it's because the bdp has its own keep life as well the whole timer they would kick in. They should right for some for some Corner cases for some mysterious reason. So hardcore fast crafty scenarios, somehow the whole time basically didn't kick it all right, yeah I, don't have any for the comments. Thank you.

A

uh Randy, did you have a comment and then we're going to go on to the second presentation, I'll.

I

Be brief, it seems to me if you're having broken TCP, you fix TCP, you don't includes further up the stack you keep. Clujing and entropy is death of the universe in the long run.

I

J

um Am I pressing the right button.

J

And I have control.

J

uh I can hear myself echo. So this is really neat echo, echo echo. So if I start rambling, apparently I lost my train a lot because I hear myself with a two second.

A

Game, that's fun. um Can you get to the slides? Can you control them? Okay, good.

J

uh All right, thank you so much for spending some time on uh considering scent hold timer we've been clicking this document around for more than two years now and I'm excited to to discuss it with this group.

J

The problem we are trying to attack is uh that in a while we've seen scenarios where btp speakers that are not under the control of the operator, So speaking from my own perspective, this could be my customers or my peering partners, where devices like that advertise, a TCP receive window of xero for a long period of time, and this can show up on certain implementations as hey, slow peers detected or an out cue that never ever again decreases and the Curious Thing is that, because the remote system that has some kind of issue is signaling to us, I don't have any room for new information.

J

We cannot send them a keeper live message now under normal circumstances. We would expect the remote system to disconnect us because they haven't received our keeper lives for some time, but we're dealing with systems that are misbehaving for one reason or another, and many implementations do not disconnect from such a broken situation.

J

Indeed, there are people lives, but they are sort of an asymmetric thing uh in the current specifications. It's not clear. The both parties should verify whether they can sense to keep the life messages within the whole timer period, in addition to confirming they have received them um next slide.

J

So the consequences of this uh are can be quite nasty, as I mentioned this or scenarios that that happen for for hours on end and the internet churns significantly over the span of a few hours. So there I think there's three aspects to this.

J

The inability to live here, HP messages to the remote site means that the remote site is not aware of our latest updates and with trusts, which might mean that the remote site is sending us packets, uh for which we have no routes, and we did tell we did queue up a message for the remote period that we withdrawled routes.

J

um It also means that if, if the session is not killed at some points, the likeliness of us having routes pointing towards the broken tier are outdated because uh I don't think it's reasonable to assume that a remote care that is no longer a progressing btp messages uh is uh only has issues with that. One specific session, but more likely has issues in in all directions and feel you have to disconnect from such a stuck here also hinders our ability to inform the rest of the network that routes no longer exist.

J

So how does manifests in infinite forwarding is, is black holding or routing loops, and that's not great.

J

So we've had it's a two large periods, large discussions uh over the last two years and my takeaway, but this is just my summary and I'm happy to to stand corrected. If people feel that I did not characterize it correctly.

J

uh Some argue that the changes to the finite State machine, the so-called surgery, uh was incomplete, that it didn't fully describe how the FSM should be uh described, and then others said what you're trying to do here is way too invasive and makes uh the FSM unreadable or even harder to interpret it.

J

So I I classify that as criticism of the internet Drive contents, because we can address this by not explicitly updating the FSM but by describing the desired outcomes.

J

um And then other criticism was more targeted towards the concept that it doesn't solve all cases of Brokenness or it doesn't so do so within the promised amount of time.

J

um But by and large I think there were people that indicated it might solve some problems.

J

Actionable suggestions that followed from these discussions uh I think the general consensus was that Central timer should be uh generous in the sense that we don't unnecessarily love connections where systems are just churning through the data and as a transient State signals please hold on sending me more and from the get-go. We have I agreed with that principle, because the this whole timer really is a uh backstop of Last Resort. This it's it's like the last thing you should do in in problematic situations.

J

It should not be something that fires off, uh uh because reset things too tight.

J

um Other suggestions were to change the tone of voice of the internet draft to be a little bit less alarmist, because in our when we originally discovered this issue, I personally considered it more of a vulnerability than as a simple shortcoming and some implementations, okay, and it would also maybe be helpful to document what central timer doesn't solve.

J

Implementation status there are free implementations, open bhpd, frr, routing and Neo BHP. Two of the three are open source and can be inspected, and one is a proprietary implementation written by then cops.

J

To zoom in a little bit on the open, bhpd Behavior.

J

The central timer timeline so to speak, the it starts when the remote system somehow has filled up its buffers to the point where it starts. Signaling, hey my receive window is zero.

J

In addition to that, the local systems outbound write buffer also should fill up and depending on the implementation, this could be anywhere between 64, kilobytes or or some something larger.

J

So this means that the remote peer is not accepting our messages but uh depending on how large the buffer is a a small or a large number of HP messages has to be generated and sent to the remote peer, and if the local systems outbound buffer has filled up, then uh the count the timer starts in open, bhpd caused by the soccer being Unbreakable and once a timer expires. So that's eight minutes from the top of my head.

J

Then it proceeds with the uh uh this connection of the remote, pier and basically does the same thing you would do if whole timer expired so ends to ends. It takes more than eight minutes, even though Central timer is set to be eight minutes now. I, don't consider this an issue because, as I mentioned before these, this is a mechanism that should kick in and really pathological situations that don't seem to resolve themselves in some other way.

J

Well, that's what I just mentioned.

E

J

So maps for continuation of this work is that it is adopted as a working group document, that we gain more implementation experience, because not all BHP implementations operate the same way that open bhpd does or FR routing does so I think it would be very informative to heard from other implementations how they achieve a similar effect, and perhaps we can use that to improve the documentation and it would be useful to get an inm registration for sendhold timer expired in the BHP error code, sub registry of the vtp parameters registry, so that in in local monitoring there there's an event code similar to say, send to whole timer expired.

J

These are some links, I really recommend to working group to take a look at the there is the BHP zero window test. That is a simple go program that you can connect to your own BHP implementation to inspect how your bgp implementation behaves if receive. Windows 0 is advertised for a prolonged time, and this is the program we've used to test whether the open HPD changes were having an effect or not, and the BHP is a window test. Emulates Behavior I have seen in the wild.

J

So it's it's not a intended as a contrived test case. This this I think, is a very accurate representation of uh what what BHP implementations might interface with involvement.

J

um Ben throws a beautiful blog post, where he hunts down stock routes where the tsp zero window, it's uh suspect, so that that might be affirmative and then, of course, there's a link to the internet draft itself.

J

Foreign- and this brings me to the end of my slides and I love- to hear feedback from the room for chairs and and other implementers.

A

Go ahead: okay,.

A

You can ask your questions direct to job.

A

Am I anchor, you can go ahead and ask your questions. I'm, not seeing you in oh or.

G

Okay, are you able to hear me yep, hello, yeah? Okay, thank you, yeah. My concern uh with this approach. I think it's a it's a it's also a concern shared by I think several people on the mailing list. It's basically to solve the subset of the problem as the job listed, the conditions there's several other conditions.

G

One of the big, if is basically the local TCP buffer, is, is full and the only thing this Market would kick in, and that's that's a very if, if we consider this problem as as a series, that's a very big assumption, because the the local bar TCP buffer may not be full, but it is a big important bdp update message use the TCP buffer that will be stuck there for a long time. At least immediately will not be able to detach that's it.

G

The basically damage will continue to work on. So this I consider this solution as a young complete, and it's a subset of the problem that addressed by the TCP this user time option. I, don't think this. This draft is this proposal is actually necessary or even useful, because it's incomplete it does not solve a very important. uh You know btp update message stuck in the TCP buffer.

J

Yeah, so can I react to that.

A

J

Please discussion so I I'm, not sure whether it's helpful to view the our two drafts as competing for the exact same solution, space I think they do slightly different things and operate at different layers each offering an advantage.

J

um The cases we observed in a while were of machines that somehow were able to keep generating keeper lives and send those each keeper life, accompanied with the signal that the TCP received window is zero. So there could not be replies, but of course, keeper lives are not a conversation where you reply to each other.

J

It's it's two unidirectional streams of information, and my my feeling is that the central timer operates at an application Level and offers some value in in the case where the remote peer has a fully functional space stack, but something else is broken uh and and I think. Your proposal is advantations in in the case that there's an issue on the transport layer, so I don't perceive, though, actually exclusive.

G

If you go back to the slides where you list there are this conditions, it would work all these conditions in that situation, as actually the TCP user time option would solve the problem. So so I'm not questioning the problem statement. Actually uh that that part is fine. It's just a solution. I think here. What it is proposal does is the partial solution, and if, if we do the TCP user time or whatever problem are you trying to solve here- is all resolved by the TCP right? You you much more deterministic manner.

A

Okay, anchor working and and job we're gonna go on to John and Claudio, so they have a chance to make their comments. uh Folks, we're going to continue this for about four to five more minutes, so John go ahead. Thank you. Enki.

E

Okay, I'll uh I'll, be brief. I just wanted to add a little color to job's. Okay, I'm, actually gonna put this into text because I'm getting horrible, Echo and I can't talk.

A

Well, John types.

H

Claudio, do you want.

A

A

Because why don't you go ahead and uh Walter.

K

Yeah, can you can you hear me.

A

Yes, I can hear you please go ahead.

K

um So I wanted to say: um I, don't agree with NK that the TCP user timer is covering more than the sandhold timer. It's actually the other way around, because the TCP zero window is not the only way of triggering this issue, because the the zero window only happens when the receive site buffer on the TCP level fills up and and and cannot progress anymore. But if the the remote system is actually emptying the tcp's um buffer all the time but is actually not making any progress on that level, then we would still have.

A

We lost the end of that statement. Claudio. Can you try the your mic again.

J

I send Claudia a text message that that he dropped off.

A

Alvaro, did you have a comment? Your mic is on.

F

Sorry, no I, don't know how.

J

Claudio's trying to reconnect.

A

Okay, John did you want to try with echo or you want to give up on it.

E

uh I can try one more time nope still a terrible Echo I'm gonna keep typing.

A

Okay, we'll pick that up in a few minutes, I think uh I'll if we can we'll take a break later on, but we're gonna go on with the next presentation and I'll try to cycle back for comments after pradash pradash we're gonna pick up you job. Thank you. uh I'm gonna try to give us another time slot for comments later on.

A

Okay, let me pick up the next person. Precaution if you'll be ready, I'll bring the.

F

Slide so that's actually going to be me not for us.

A

F

A

Wonderful, that's great! Let me go ahead and make sure I think check and see if it's the wrong deck, we'll we'll pick.

F

It up nope: this is the right deck.

A

Oh wonderful, just let me give you control they're yours, L Barrel. Thank you.

F

Yep, thank you. Sue and I want to start by thanking everyone who has already looked at this draft and Who provided feedback and questions and comments. um They have been very useful in us. The authors we get together every other week to have discussions about this, to make the text better and also I think to show interest in in this topic. So thank you. Thank you for that.

F

um We had in case you missed the emails on the list. We had posted the version zero of this right before the ATF meeting in Japan. uh There were some comments and a lot of good feedback there as I said, and we posted zero one on Friday I'm going to say up front. We didn't address all the comments because we ran out of time, but we wanted to post something at least to show some progress uh for this talk.

F

um I have at the end of the slides. We put a list of a to-do list of the outstanding items. So please, when we get there, take a look at that. Make sure that if you run up an issue, it's there and and if not, maybe we already addressed it and the slides are going to talk about what the current state of the draft is. So some of the comments that you already made may not be addressed here already.

F

So what is the problem that we're looking at um I I wouldn't really care for us it as a problem per se? But you know the situation that we have. There are many networks, operator networks or big Enterprise networks, where the administrative domain The Entity, who administers the network, has multiple lists. This can be for many many reasons. It can be the network group. This way it can be. There were mergers, Acquisitions Partnerships, other relationships where the span of control of an administrator really goes across multiple autonomous systems.

F

Now we see this all the time in documents from IDR, but also other working groups where they talk about a single administrative domain and where people say okay, the intent of this is to propagate only through a single elevation of domain, which is basically the definition that I talked about before, where a common admissions entity say an operator or just a network operator itself has control over multiple asses.

F

We're calling that not a single initial domain, we're calling it one administrative domain OED. So that's where the OED name of the draft comes by and of course, uh the point of all this is that there is a desire to do better policy control and influence route. Selection across is boundaries using attributes that would normally not go across as boundaries. So that's why that disclaimer goes into a whole bunch of drafts. We want this to be across a single or OED the one other domain that we're talking about here.

F

So this slide basically summarizes what we're doing with the draft. We already have ebgp and ibgp sessions, we're defining in this draft and you type that we called epgp OED.

F

um The naming is, we did it this intentionally, because the idea is for the session to behave as an ebgb session, but because it is part of this OED across multiple answers, with the ability with the optional ability to have um to be able to do exchange of attributes that would normally not go across apgp sessions or there wouldn't be use in the receiving side of the evgb session. So a simple example is local preference.

F

The ROC says you shouldn't send it. If you send it, if you receive it, you should ignore it. So in this case for the ebgp OED session, we're saying it is optional for you to send it and if you're the receiver on the other side, you should receive it and use it because again we're extending that domain across where it used to be uh ebgp sessions again default.

F

Behavior is ebgp, plus the option controlled by policy to send other things across currently The Way, It Is defined in the draft is, is this is controlled by configuration? I know Jeff. You had made the comment about a capability that is on our to-do list to think a little bit. More about this and consider that so, as I said before, this is what draft01 still says we want to follow.

F

Ebgp rules, so attributes like the aspath or example would go, would would be forwarded or would be transmitted the same way they are in ebgp, so the aspath we would add, we would prepend the as right, so just like normal epcp and again, in addition, optionally, some ibgp stuff or non-translative attributes the draft talks about. We have added more of the attributes to the list. That was a big comment that we got from zero zero.

F

We had started what we thought were some of the exceptions, but now we have added a almost all the attributes are discussed there. There are some, for example, that we still don't want to go across the epgp OED session, like originally your ID and cluster list, and- and the reason here is simple- we don't think uh you know. Route reflection uh should span across these types of sessions as well.

F

So again, this is the the Crux of the of what the draft says. It would be great when you go and read it to make sure that what I just said in the slides is what is actually written in the text uh there. We think it is, but you know just just to make sure um the other thing that the draft talks about- and this goes back to the point about the um capability that I made before and Jeff's comment is that you know currently the draft talks about the ability to.

F

um Configure this behavior on not just session by session basis, but on a peer-by-peer basis. uh You know the rationally, meaning that we believe right now and that's why we still have that to do item to go. Consider the capability that um the way 7606 is defined, that we could enable the bgp OED session on one side. If attributes that are not needed would be sent, they would be ignored.

F

In other words, standard dbgp would apply for the receiving end, and the session would remain operational, um so I need I would just want to say this again uh and and that's why I'm going to show the next slide. One of the action items or the to-do list that we have here is to go. Consider um the advantages, the potential advantages of having that capability to negotiate the current time and among one of them may be. You know avoiding some extra errors in there. So um this is, as I promised the to-do list.

F

We almost are almost done with the enumeration of the attributes of all the attributes were missing some like origin, and we probably want to look go look at the container that is used for white communities just because that is already outside of the working group right, it's uh with the ASG somewhere. uh So we're going to look at those, and then you know finish enumerating those. Please go. Take a look at the list.

F

We have right now and and provide uh your comments on those on what the behavior um is or what we're proposing is going to be and again most of the behaviors there are going to be optionally. You may send uh non-transitive attributes across the epgp OED session. uh We need to uh the other item on the to-do list is considered new role definitions.

F

Currently, the draft says that the use of the roles defined in 1934 are not recommended for the apboad type again. You know something we need to go address and think more in our like Wiki meetings that we have. We need to go talk about configuration and what may be configuration requirements that we have someone mentioned on the list that maybe we need to. We want to have a list of other OED Asus in the vicinity. For example, now the draft talks about the definition of one session.

F

There are some use cases that we're looking at where this would be. You say with a stub as because there's a special business relationship there and we would want to just have it there, for example, but it is obvious that we could uh an operator could use ebb OED sessions to connect all their Asus, for example.

F

So one thing that we are considering also is you know what is the effect of that to the place where we have only ebhb session from that place to the place where we have all ABC LED sessions, for example, um if the default is of ebgpoed is ebhp? Well, what happens is we? You know through policies, start allowing things through we're thinking right now that this would be a separate draft, meaning this draft? The current one would talk about the session type itself and then another one we'll talk about.

F

Well, what happens when you use it in specific ways, not just everywhere to connect all your Oasis, for example. You know migration considerations and you know things like that, but also other things that came up around, for example, exchange points or router operation. So that may be an operational consideration, type thing that we put it into a separate draft.

F

um There is a draft that was pointed out on the list that we need to go um think a little bit more and add some text around and preparation between OED and uh the RPG pediatrician announcement draft, um and we need to add text on what we expect to happen with new attributes going forward. In other words, we are listing the current existing attributes and the behavior that is expected from there in this draft.

F

But um the intent is for this draft to say for future attributes um non-transitive future attributes they would still optionally apply to the ebgp OED session type. In other words, my policy and operator can allow those non-transitive attributes to be announced to evgpo the peers, and so that way we won't have to come back and update this draft all the time, and if there is any exception, of course, any future attributes would should or not should must um indicate.

F

What any deviation is.

F

And um there was the other point about uh disjoint the essence. uh There were a couple of people who were talking about um what happens in my oeda SSR, separated by someone else's saying. Yes, well, that's out of scope for for this right, because the continuity wouldn't be there.

F

um So was that clearly that uh at a scope, so what we're looking at is. We are, as I just said, in the process of um addressing all the comments that came from draft zero, zero. We would love for you to go and read the current version of the draft. Look at the this. If you already looked at zero zero and um you know, provide some more comments and more feedback.

F

um We of course eventually would like to ask for adoption I think until we address the zero zero comments, uh we won't be there yet so it'll take at least one other round trip before we were ready for uh working group adoption.

F

So that's it for this presentation. If anyone has comments, I've seen some things go back by the chat, um I'm, not sure. If she is this or not, but any case um comments, questions please.

F

So uh I see uh Claudio on the Queue. If you want to go ahead.

A

I want to warn you Claudia that we're going to only take bgpoa D comments right now. I'll try to fit uh the send Hole uh timer comments at the end of the session. So are you working with the oam comments? Claudio? Yes,.

K

um I wanted to say it I think it's a good idea to use uh bgp roles um for this, to make sure that both sides agree with the the type of the session.

K

um That's the only thing, I wanted to say.

F

Great thanks, uh yes, we're looking into that. uh You know both from the existing roles point of view to maybe potential uh neurals. uh So thanks.

A

Any other comments, uh Alvaro, you might look at the original uh ISO version of bgp 7 uh 10757 for that uh Confederation concept. I think you're sharing some of the same things I'll, send specifics, ready.

F

Your turn, thank you. We didn't want to use the c word, but yes, yeah.

A

I know but uh Randy your turn.

I

um Alvaro I would like some text that reassures me that I cannot signal you to leak things which are um ill advice from a security point of view.

F

I

F

What do you have in mind.

I

I I don't want um in Myas I, don't want you an ebgp peer to be able to signal to get my internal data like multiple pref was your example. I believe I've actually cheated and read the draft I believe that won't happen, but I think some security text is useful.

F

Sure, yes, what you mean? um Yes, we're not changing the behavior of ebgp session, um but yes, I see what you mean that you could end up with the wrong negotiation or something and prompt you to send something that you didn't want to send. um Yeah thanks.

A

Yep and yes, ISO 10 747 is the right number. Okay, um any more comments for Alvaro.

F

Great. Thank you. Everyone.

A

Appreciate the comments our next speaker is uh zinton. Let me pull up your presentation.

L

L

Good morning and good evening, everyone, my name- is Anjin from Huawei technology. uh I'm gonna give a presentation about a flows pack redirect load balancing group Community next slide. Please.

A

Well, I'm going to give you the control for the slides you. Let me know if you can see the the ribbon at the bottom.

L

Oh yes, I can see that all.

A

Yours, thank you.

L

Okay, so uh this is the second time this draft was presented on intf, uh so the last time was itf1 sorting. So it's been a year. I'm gonna do a recapulation about the motivation and problem segment. Also, we made a few updates and uh added some chapters to the draft. After the last last presentation,.

L

I didn't see the search slide. Do you say the third side.

E

A

This is the third slide. I see, motivation and problem statement is that, where you're trying to go now, oh.

L

Yes, I did yeah I, know, I, said: okay.

A

L

May have some delay. Okay, so, as we all know, bgp flow specification allows flow road that carries traffic policies to zero traffic. It's always being used uh everywhere. So in some scenarios we may want to steer traffic to a load, balancing group either ecmp or ucmp. So, as shown in the graph, we might want to do a traffic steering at R1 to R2 R3 R4 in a ratio like a one, two two to two: the ratio could be changing according to network running status.

L

So for now we have a redirect IP extend Community, IPv6 external community and uh we can reach. We can steer traffic to uh srv6 turnover with a Cutler extent community. So, but uh in some in some implementations we can do ecmp of redirect IP actions by encoding, multiple redirect extended communities, but the current set of communities can hardly support either ecmp off srv6 externals, uh nor a ucmp of either types.

L

That's why we wanted to do a new technique.

L

So we introduced the redirect load, balancing group Community, it's an extension to PHP Community container attribute, so it's a new type of a wide community, so the uh the format of The Wider Community complies with the definition in a wide Community draft. uh Besides that it must contest only one parameter: TRV uh within the parameter TRV we have a list of sub-series uh each represents redirection actions.

L

L

Since last time, we made several updates based on the comments. Firstly, we reference on the rephrasing on the atoms, so now we call them sub trvs for reject actions, uh because column atoms could be confusing with the atom's definition of the wide Community itself.

L

Also, we add some chapters about interactions with other redress reactions so away. What we're suggesting is uh to do a configuration control, so the original extended community actions may take a precedence by default after you, based on configuration on the device, the what the redirect group Community take precedence.

L

Also, we add a validation procedures to the draft. uh So each past, CRVs of the within the wide Community within the radio group, Community need to be validated separately and the reject group is considered verified only after all. Past theories are verified.

L

uh The verification procedure for each one redirects to IP follows the normal religion procedure of that also we're thinking about the compatibility with flows backward and two, but uh this Tech. This mechanisms was mainly designed for flows back where one scenarios uh it didn't conflict with uh it does not conflict with a flows. Fact we're in two action wide community.

L

Oh sorry, I forget to move the slides and uh that's it. Thank you and uh more comments and discussions are welcomed.

L

I'm gonna put it one slide back because I forget to show this one. Sorry.

A

Go ahead, Jeff.

B

So I think for your flow spec, B2 considerations. I, don't think! That's really well discussed at this point in time. Oh much like what we have for flow, spec, V1 and all the other action communities that we have uh defined. Currently, the main considerations are: how do they interact with each other, especially if you stack more than one. This is just another addition to it. So I I, don't think this specific proposal changes too much from flow spec V1 to V2. At this point in time,.

L

Yes, uh within the interactions, without a redirection actions, we uh all we talk about is the interactions with the mechanisms that already exist in philosophy one. uh We didn't talk much about interactions with philosophy too, in this draft, so uh doing that we may want to add some new sections later or uh proposing a another drop to talk about use of this influence back way too.

A

I would recommend putting the interactions with the flow spec V2 in this draft. If that's all that you're missing, uh please look at the uh actions that are in flow, spec, V2 and let us know I think that would be better and I. I should say that as a uh working crew participant and not the chair.

L

Okay, thank you for your comment.

A

Do you want to make an additional comment, or should we I go on.

A

B

So please continue I'm just having trouble managing my buttons moment. Okay,.

A

That's fine um I'm going to then go on unless there's any other comments on this flow. Spec we're going to go on to a second flow spec presentation.

A

uh Hang your next give me a moment, while I load up the slides.

A

A

Just a minute.

E

A

Do I have the right slide set up hand.

A

You have control of the slides, it will.

C

Be on the bottom yeah: okay, hello, everyone, my name is Hunter I'm from Bali and I will talk about a few drops. Actually I won't related to the cats communion where traffic theory I'm going to talk about the background and the intention of bgprs, and he will talk about the attention to PVP of those back foreign.

C

I will introduce the background on the cats, so Cass is a new working group on the routing area, the chartered to consider the problem of how the network ads can steal traffic between canines and and the service. The scenario is that one service can deploy multiple service instance in different sites, and the Ingress router can wrote the connected request to the suitable site based on their Computing centers, for example their Computing node or Computing latency.

C

In order to do that, the Ingress need to know the Computing metric of each site due to the traffic theory, and this working group is limited to to the overlay model. This is the Ingress router and the egress router will run on top of Eternal so that the Computing metric will not affect the underlying. What is kind of like a VPN login.

C

uh Actually, we have a existing method to pass this Computing metric using the IDR working group. uh It's called the service metadata. This service method defines uh defines a set of computing metric capacity using the pgp. It's a new pass attribute and if we are running VDP between the site and the egress router and the pgp between the Ingress and the Ingress, for example, this R1 and R3- and in this case the Computing metric of the site can be tested to the R1, the Ingress router and combined with the terminal information.

C

This R1 can generate the final Computing. We are road to steal the traffic to the appropriate site ready, but we are proposing a new solution that we do not want to touch the PCP between the Ingress router and the egress router. So we can use the controller to do some kind of Renee renew the Computing metric on the uh for the control that you connected the connected the Computing metric from egress router. We we use pdprs and for it to distribute the Computing metric. We extend the bgp flows back.

C

This is the basic Assumption of this scenario is that we still use the pgp to pass the Computing metric outside of the Computing side. For example, in this picture, the basic field is running between the R3 and accessory.

C

So first intention into the bdprs to collect the Computing metric from the U-Verse router to the controller. Basically, you are reusing. The uh the ad service method data chart, we reuse the computer Computing metric defined in this route. For example, we have site preference and the capacity index and the node measurement and pass it using the pgprs and then we also add a corner attribute TRV. This corner is just like the the road color, the natural color, to indicate the service level.

C

The different Services may have different price, for example, and we reuse the prefix in our eye on the prefix it attribute for this intention.

C

G

D

Okay, hello, everyone I, am an ECC from technical uh for the next new friends. I will explain the distribution of computing metric.

D

uh We proposed an extension of BHP flows back to distribute Computing metric uh uh in the single World shows the distribution degree of service data using mid B flossberg extension, add a service metadata to the first bag or routine. All its data sent by the b2p prospect controller to the entry node to describe the calculation Matrix.

D

The Computing metric can be described in two ways. The first method is to refer to the original metadata path attribute in in the drafting is the pgp extension for February Edge service metadata, uh the sector method, aggregate aggregate, some calculation attributes and the describers, then by numerical values.

D

This is the the distribution format. Requirements for calculating matrix by education are so infinite. Two include the aggregate metadata type lens and value. Let's order offer my introductor under b2p Prospect extension. Thank you.

A

C

A

C

Or VR, if they have any questions.

A

Okay, is there any additional questions for hung.

A

Okay, we're gonna then go to use again and, if I pronounce that right, I'll go put the presentation up for that. Just a minute.

A

Eugene did I. Did you complete yours? You did this in the same piece. So there's just a minute. I think I've got the wrong slides at my apologies.

D

I I, just uh it's been.

A

A

The slides were con contained in the same slide set, so you went ahead and presented. That is that correct Egan.

D

And to to spend it so I I, don't I don't want to.

A

Okay, just a minute: yes,.

A

Give me one moment, folks, take a mental break while I try to find the right one.

B

Two: she confirms that the presentation that was just given contains shinshin's.

A

That's what I just said did you have any? Did anyone have any questions for XI Jin.

A

Okay, then we will go on with rants uh presentation has ran, uh appeared yet today.

A

There you are Wren, I'm gonna, give you the slide set. Thank you for your patience.

M

Thank you hi everyone. Today, I would like to do the priorities about ISR policies, expenses for RP, bpis and sorry.

M

Yeah, this is the introductions, segmental routing policies, uh all this list of segments that represent uh represent uh South rotate policies and ITF Network slices introduce the concept concept, Network NRP, which is a step a subset of the resources and Associated policies in the underlying Network and the job idea. I start policy and RP defines the extensions to ptps policy to specify the ownership which the SR policy currently pass is associated with.

M

In this stop Movement, we defined a new tra which enables 1008 108 to report the configuration and the state of the RP with the SR policy candidate pass is associated with uh this is the bdprs policycontinence for NRP. In this document we defined a new ISR policy, State Theory. We called it an abstra way to carry it in RP with as a policy a country pass, it Associates is a that is. This is the format of the rptioa rpid is a.

M

Is a global identifier of a Network resource positions.

M

This is the procedures, as a policy currently pass. Maybe in this is, is tested with a specific NRP on the 108 note by a local configuration, PCP or pcpsr policy. Similarly, and then the state and the attribute of the RP is the current part of as a policy is associated with is encoded in the bgpis a tribute field as a policies, data tra, um the iso policies, digital wave, it is defined in draft idea, pdpr assets policy and not change. It can be used to report as a policy.

M

Can they pass a state and attributes, and the RCT array which is defined in our draft is included to report the state of the NRP foreign.

M

L

Hi uh good morning and good evening again, it's me again uh tangent from Huawei Technologies. This presentation is about Road Target constraints for pgp flow and a bgp ISO policies. This draft is an informational draft, so it does not propose to any new a new new piece of Technologies. It's just a combination of existing mechanisms.

L

So uh during a distribution of Sr policies or.

L

There's already an controller used to distribute this, so if the controller Santa flows back roads and or as a policy to an RR, they are need to reflect the rows to all peers and the client will apply an Ingress Road policy, either static or dynamic, to filter those those roads and to give the road a targeted Zone. This procedure may cause a waste of benefits and network congestion.

L

By exchanging bgp, Road Target, roads, pgb speaker could generate egress policies for filtering one or a group of network nodes, so just work out a flows back or F or as a policy ORF.

L

uh Let's see this example in the graph. So if the P1 and P2 Center this row Target membership NRI uh with a with this as number and a router ID to RR uh through the uh row, Target rows uh row Target Ari after receiving the update message, the r will trigger the rebounds of the flows back roads to match the egress policies uh with the exist with a road Target extent community on the roads and updates those roads to the PES.

L

So, instead of using the Ingress policies on the PE, we propose to use the egress policy on the RR.

L

If multiple layers of R are deployed, there are need to advertise all received: Road Target membership in our eyes to the upper layer r, so uh the proposed format of the roads, membership NRI is defined like this. So we we're using a ipv4 address, specify a specific, extended Community as a road Target. uh The subtype is a gonna, be two row Target and the Global administrator is set to zero and the local administrator.

L

Oh sorry, the global administrator is a load identifier which really be the root ID for the up for pgp rotor and the local administrator is reserved for future use, and it must be, it must be sent to set to zero upon sender and must be ignored after receiver.

L

uh That's basically it thank you.

L

Oh I'm sorry I forgot to show the slides again. uh This is my first time to control the slides online uh since I just have time. I'm gonna re-reading this, so uh so we, this is a format. The proposed format of the road Target membership in our eye. So we we're gonna use a ipv4 address specific extended communities as a road Target, so the the subtype is zero. Two photo Target and the global administrator is a road identifier of the node.

L

Usually it's a your ID for a PCP router and the local administrator are going to be reserved for future use and must be section zero for now. Thank you.

L

B

Yes, I appear to be in the queue. Would you return to slide two? Please okay, so my question here is pretty straightforward: I I understand you want to apply. You know to Sr policy routes in flow spec. You know RT constraint, it's very straightforward, I, don't understand what full spec or ref is here.

L

Oh, so, for using these techniques, the flowsback will need to carry an rtxn community on the road to match, with the RDC Road.

B

Okay, so your terminology is you're, trying to call a flow, spec or ref route. This combination.

L

Oh I mean the floors. Back Road need to carries an row Target extended Community to in you know, in order to use this mechanism.

B

Right but outbound route filters are router to router and they'll do not get carried across ground routes.

L

It's just controller to router.

B

Okay, I guess: I need to read the specification more detail. uh I also placed into chat a link to uh ji Dong's node to Target Community I. Think you may find this might be a better fit than a standard. Drought, Target.

L

Oh yes, uh I talked I talked with him, we're colleagues, so uh uh this this mechanisms could also use with no target uh Community yeah.

B

Okay, thank you. Those are my questions.

A

Okay, any other questions for Sen.

A

Okay, thank you very much, then I'm going to allow in case we want to get back to comments that we had on the send timer. Would anyone like to uh provide additional comments? uh Claudio you had questions and I believe Anchor's still here or uh so. Are there any further questions or comments on the sent whole timer or Anchor's draft? We will add it now go ahead. Claudio.

K

Say before was that, in a way the the two drafts are kind of doing the same thing, and um what we could do is like.

K

The important thing is we want to actually detect this and how it's implemented is is kind of open for people uh for the individual implementation and I think uh there should be an agreement that, like both drafts, are working like it's, the technical implementation and I think either either solution would actually work and for open bgpd. The version that I did I'm actually quite happy with the implementation we have and it seems to work very reliable at detecting this situation.

A

Foreign comments for Claudio.

A

And Kirk go ahead.

G

Comments Claudia I think earlier you mentioned that. Basically, you have some specific cases that basically the TCP user time would not work, but the pgp timer would work. I would like to basically see that look at more detail yeah if you can share that that either privately on the mailing list. That would be great second comment is about the open, bgp implementation.

G

Is it correct that job? What the job is showing on the slides is about the open, PDP implementation with basically multiple. If statements that had this condition, it would work basically local TCP Buffalo will be before. Is that the open PVP implementation.

K

Yes, it's more or less uh how he, how it.

G

Works? Yes, it's so it's a bit high level! Okay! That's it yeah! um That's what what I like to point out? I think I pointed out earlier. Basically with that, if statement, basically, if the uh you know it's it's a subset of the problems, I think for you guys to point it out, because if there's a importing the pgp update the message, that's stuck in the local TCP buffer at buffer is not full it's and it's not being delivered by extended period of time. uh It's the same damage.

G

So that's why I I would call it as a as a partial solution.

K

Yeah for us, the big thing is that the BSD Network Stacks don't implement the TCP user. um Get sack, opt so for us.

G

This is currently.

K

G

Solution yeah, you know it's like okay,.

G

Coding of timers is pretty straightforward at that point out. It's always uh probably it does not require that much code. To just add the TCP us into the stack.

K

It's more code than implementing the user, the the sandhold timer in vgpd.

G

Yeah so as as I said, uh you know it's like. Basically it's a it's, uh you know, TCP user timer would be more complete uh for for that issue, because the way that the local buffer CCP buffer is full or not as long as the data is stuck, uh it's not deliberate for extreme pure time. The TCP do the timer would kick in. So it's a more complete solution. That's that's what I like to point.

K

I, it's it's an equivalent solution.

G

um No I keep I, keep repeating myself. uh It's it's easy so that the PDP Solutions solves some cases, but it's incomplete the I. Don't I would not characterize them as equivalent yeah.

K

What what does your solution cover that um the the other one is not.

G

Yeah, basically, what I'm saying that the TCP user timer does not care whether the local TCP buffer is full or not as long as the package is not delivered uh on time or not deliver for extended period of time that time that the TCP user time will time out, but in the PDP based solution, because yeah there's not much you can do you don't have visibility into TCP buffer. So that's you! Basically what you do you say. Basically, if the local TCP buffer is full? Yes, you can.

G

It helps that, but it's a subset of the problem.

G

So so there are differences, but yes in.

I

Some cases yeah.

G

You know it would work, but for other cases you see the pgp-based solution will not.

K

I I think in the end, we're just splitting hairs over something that doesn't really change the aspect of the overall um solution of detecting stock routes and detecting stock sessions.

A

It sounds like you both have some good discussion with one another that you might.

B

A

Offline and and come back and report to us uh uh to the working group via email does: is there anyone else that would like to chat about the uh bgp timers.

A

Any other comments for today's interim.

A

Jeff K or any comments before we hang close.

B

No come inside for me, although I'll repeat this on the mailing list, the missing details that people seem to be talking past each other and the send hold timer and the TCP user timeout values send hold. Timer is fundamentally about black sockets, which can happen in some implementations, even for non-zero windowed environments. You know, basically, if you have a big enough update and you're trying to send a entire update, then you can't fit in the window that can manifest in some of the implementations that way and for the user timeout piece.

B

The requirement is that you don't get an acknowledgment. The things the said hold tight as the tsp timeout authors don't see, the beginning is zero. Winding can happen and you're still getting acknowledgments back you're, just getting acknowledgments back that have nothing in them. You know it's telling you. The zero window is still there, but you first came to acknowledgment within the time frame.

I

G

Jeff I think you are, you are. You are probably talking about the Linux that implementation block, which has already been fixed, I.

B

Am talking about RFC 793.

E

B

If you look under c793 under reliability, it says if the ACT is not received within a timeout interval, the data is retransmitted, the ACT is coming back, you're sending you know a packet, no you're, still sending your keep lives, you're getting X back. You know that says that you know the receivers may have no, not Advanced your window. You may get it. You may continue getting asked back that just keeps telling you the zero Windows there and eventually you know you're still acknowledging their frames, but they won't eat. Yours, no X are still flowing.

G

uh Okay I, thank you, Jeff I think, let's, let's, uh let's exchange, probably I like to understand the specific cases to see, because um this.

B

Will be repeated the stuff in the mailing list, I'm happy to copy and paste the original threads? Yes,.

G

Please please Point down to me to the link. I I will need to think about this yeah exactly.

B

That's it. That's it for me soon,.

A

Okay care anything that you'd like to mention.

A

Here in uh in the chat window, someplace.

C

A

Good from Maya, oh good, great I'm, glad the auto will work well. Folks, then I think we're going to return uh 15 minutes of your day back to you. Thank you very much and we will close the session now.

B