Internet Engineering Task Force 109, 16 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF109-LSR-20201116-0500

Description

LSR meeting session at IETF109
2020/11/16 0500

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

A

A

B

Is anybody using on jabber.

C

uh I've got the oh.

B

Yeah, that's the chat window. Oh okay, I got the chat window. We can just uh that's. Oh it's it's it that is jabber. Okay,.

C

Yeah, that's chamber, so um yeah. I don't think we need a scribe right. I I don't think so either that's more useful when we're not virtual.

C

uh Keep trying to reply to people.

C

Zhen zhang is still having problems, but I don't know how much longer we can wait for people to get this fixed. um There were test sessions, so I think we do need to start pretty soon, though right yeah.

D

C

C

C

All right everybody, so this is the lsr working group as the screen share shows and our agenda is up there.

C

Does anyone have any problems with the.

C

C

Okay, so um I will bring up the status slides.

C

Let's see if I can do that.

C

C

um There are a couple people saying they can't hear even with chrome, I I don't know what to do, though. I don't think we can.

B

Just hold the meeting up, no, I don't know what to do either. uh I had a problem with that for about maybe they could have updated to big sur and there could be problems we don't even know about.

B

C

There's a there's, a reporting problems.

C

And I'll do that and then we'll start see if that.

C

C

Okay, uh yeah, if you want to start ac, okay next slide,.

B

Okay, this is, uh I guess, the first meeting of ietf 109.

B

be aware of the note well and that, if you, uh by participating in this meeting, registering to participate in these meetings, you are obliged to disclose any ipr that you are aware of.

B

Also, I mean it it's it's wider than that you can just kind of look at the slide. I know you've seen most you've seen this many times before.

B

Okay, next slide.

B

Since ietf 108 virtual, we uh have three rfcs the isis invalid uh tlv handling that was good to finally get that all documented and get the iana updated as to what tlvs were valid for which uh pd pdus and these two, uh the two app specific link attributes uh drafts both for isis and ospf.

B

uh These are these are good, as especially as we spend a lot of time on these. Those people know that we are involved in for ospf. It allows us to get down to much many fewer lsas for all the different applications that we're going to support. I mean uh so this was this. This is great that these are done next slide.

B

We have the same drafts with missed references, the two yang models ospf and isis, and the tunnel end caps. Now the tunnel end caps appears to me moving along in idr. They got a new editor. Thank you, john and uh it's uh hopefully it'll be published soon and that'll go now another thing about these giraffes. These three drafts- these are the last ones that don't have lsr in the name. So after this we'll have finished all the work when we had separate isis and ospf working groups, next slide.

B

I guess we have these two that are waiting on the segment routing, bgpls segment, routing extensions, the isis and ospf uh elc advertisement. That's entropy label capability next slide.

B

The we completed the last call on the isis rv6 extension.

B

uh We just completed the flex algorithm working group last call and the prefix originator is pretty close to pretty close to complete or we had some uh discussion fun differences with the similar document in isis just recently, but that should go forward as well. Next slide.

B

uh I think for the ospf and isis segment routing the base, the mpls based segment. Routing yang models are also ready. I'm an offer on that we'll we'll probably last call them before the next ietf. Additionally, the reverse metric, that's uh augmentation to the isis yang model. That's on the rcq. I think I uh I'll I'll working group last call that one probably with before uh within the next few weeks and extended lsas. I think this is also ready.

B

I'm also offer on that.

B

C

Yeah, I was gonna um mention my mic didn't unmute last time, but on the on the prefix originator, um I'm shepard on that one and it's it's ready to go when it went into work. In your blast call there was some contention over some use cases being removed and that got resolved. The use cases were removed. um So uh if, if anybody uh we'll be doing we'll be ending the last call very soon, so if there are any more objections, then please post them. I don't believe there are.

C

I think that it's ready to go, but just in case get get your objection and fast.

B

Right: um okay, we have uh these existing working group documents, the dynamic flooding.

B

This it seems that at least we might have some implementations in progress. It's it's a foundation for other drafts.

B

So hopefully we can have some good discussion on that one during during the next uh couple months and maybe working group, let's call it the hierarchy.

B

We probably won't move forward with that right now, because it's a pretty complicated, uh not complex, but it's a it's a major protocol uh enhancement. So if nobody's going to implement it, I don't know that it makes sense to work in group, less call it and move it forward, and then this is. This is one.

C

B

C

That you might you know that it really does help, maybe to get some implementations or that's right.

E

Right patient experience.

C

B

And we have uh the flooding algorithm, one one of the one of the a documented flooding algorithm for the distributed case. That's based on the first draft. The flooding uh on dense graphs, draft slide.

B

We have all the let's see. Is there anything that was an accomplishment? We decided to go forward with experimental drafts for flooding reduction and we accepted three pieces of work, the area proxy, the flood reflection for isis and the isis ttz we also have. uh I probably shouldn't have listed the second one. This is a mistake: shouldn't be a new working group document. It's been a long time and uh I need to make sure I saw that the offers re refreshed and make sure there's still interest in this. It's pretty much just a protocol maintenance.

B

Draft where the where for pc we have pce and the capabilities this, uh whether you know where the pc, the pce capabilities of uh of a server and a cloud and clients, and what this does is. It allows you to also just discover what type of security is supported.

B

The yang model augmentations for this first cut of augmentation supporting drafts that weren't in the ospf model.

B

We probably won't go forward, we'll probably want to get at least a few more uh augmentations in that before we publish that or go at least go forward before you last call next slide.

B

And we got these uh working group documents.

B

Let's see if there's any yeah there's one one, these are ones we added since, in the last since the last ietf for right before the last ietf, the ospf b3 extensions for srv6, I believe there's a reference to that in flex algorithm.

B

So we might want to give that a priority, um and I, as you as I don't know, if anybody's implemented it uh I'll start a discussion on that one. Just because uh there's a normative reference in the flex algorithm draft.

B

A lot of these other ones like reverse metric and link bundles, there's things that are in isis that were putting the comparable function in is into ospf.

B

You can see, I must have thought that the ospf sr6 extensions was important because I listed it twice and we just accepted isis rfc 5316 bis. This allows you to support uh 5316 in ipb6, only networks, the gm gmp os extensions in in ipv6 only uh networks. Previously you required it required the routers to have the encodings required the routers to have an ipv4 address next slide.

B

We got quite a backlog.

B

We, I think, all of these we'd, like all the uh the offers have asked for working group adoption. I think, there's a good reason to adopt all of them the flooding parameter advertisement. I expect that to generate working group discussion again, but it's definitely been presented enough times and it's time we.

B

Discuss it, you know, discuss it and possibly adopt this document.

B

Or some form of it and I believe, that's all yep.

C

uh Any any comments.

C

If not we'll move to the flooding results.

C

C

Okay, what happens when I close the window? Oh.

F

F

Okay, go ahead.

G

uh Yeah, uh hello.

H

Yep we can hear you.

G

H

G

Yeah, I'm yeah.

G

C

Yes, we can hear you.

G

Okay: okay, uh shout out stop started; okay! Thank you! uh Okay, uh hello! Everybody here in yangon from javi, okay, next page, please.

G

Okay uh right now, itf irsa working group have several drops really related to igp flooding processing. So there are two directions: one is to reduce flooding amount by using flooding top logic and another is to reduce transmission and speed ups flooding. So we try to do some testing planning tests and hope it can provide some help to optimize igp flood. This is the menu so the first I introduce our motivation and the test scenario and the test case.

G

Finally, it is our conclusion next page, please so, let's test adjust adjust some lighting parameters, try to achieve minimum flooding time and the minimum retransmission amount, okay, what they are, what we adjust at least here. The first parameter is window. It is similar with the interface rsp receiver window in flooding, speed draft. It is the threshold of retransmission queue and the next one is tx interval. It is to control the transmission timer. The last one is interface tx interval. It is rsp sending speed.

G

So the process of our test is similar with plotting speed draft, but we don't implement the draft. Just use configuration to simulate the process that the standard side receives. Those parameters and we check the result so next page.

G

Please, okay, I introduce our test case here.

G

We have three test cases and the case one want to find the impact of retransmission interval and the case 2 want to find the impact of interface rsp receive window and the k3 is based on the is based on the kit 2 and under the dynamic read, control is added, and here we in our test case, there are three kind of device: tester sender and receiver, the tester generated, 20 thousand rsps and the senate sender, the thunder flatters rsps to receiver, and we have serious scenario, single link, parallel link and dual home network.

G

Okay. Next page, please.

G

So the first is case one we change the tx interval. It is a retransmit interval in this case. No interface are sphere, is a window and that the interface tx interval is 100. Rsps per 100 milliseconds text interval is started at 5 seconds 3 seconds and 5 seconds we can find the flooding timer is similar.

G

Run time is similar. The impact of risk factor to the flooding timer is small, but small tx interval will increase the retransmission amount. Okay next page, please.

G

So the case tool we test interface rsv receive window. Now. This test case is only execute on the scenario y single link. Here we have two kind of read: default rate is 100 rsps per 100 milliseconds, the minimum rate is 10 rsps per 100 milliseconds interface. Tx interval will be set to default rate in default and the site to minimum rate. The number of unacknowledged rsps reached threshold, the interface as prereceived window.

G

Through this test case result, we can find the one proper interface rsp receive window can effectively reduce the number of retransmit rsps on the interface, but the flooding time is not so good. So next page, please.

G

To k3, based on the case tool, we change the interface tx interval from static control to dynamic control.

G

The process is if the number of unacknowledged rsps reach interface rsp, receive window decrease the rate by 50, otherwise increase the rate by 20 percent until 200 rsps per 100 milliseconds.

G

Here the interval is one second, you can see the number two and the number three the flooding timer improvement is obvious and number four. They think the speed keep reaching, because the standing rsps have not reached the series hot, so dynamic, randomical, speed adjustment based on the static window, significantly reduce the rsp flooding time and the number of re-transmitted rsps.

G

So, okay, next page, please.

G

Based on these three test cases, we get some conclusion the first one is. The sender should be aware of the capability and the processing status of the receiver to control the floating time under the number of retransmission, and the second is if only the static window is used to control the retransm transmit rate of the sender. The number of retransmission can be reduced, but the flooding time will be prolonged if the window size reside is too small. The flooding time would be too long.

G

If the window side is too large, the upper limit of the window cannot be reached and the flooding speed on the interface keeps reaching until maximum adaptive learning is required to obtain an appropriate window site. Dynamic adjustment of the flooding of the sanding speed based on the appropriate window, can achieve better flooding time and better rsp transmissions.

G

It is our conclusion next page, please.

G

So uh actually uh we are keep on uh put more effort. We have put more uh more effort on the flooding process. uh We will keep on doing it. So actually we also need more input and the suggestion about this. This test yeah. It's all any.

G

C

uh Yeah go ahead. Les.

G

I

This is leskinsburg from cisco. uh Just a couple of quick questions. um Did you do any uh adjustment to is.

J

This guillain, can you hear me.

I

Sorry, can you can you folks, hear.

C

Me yeah I, unless I can everyone I mean we can hear yeah. We can hear you but you're cutting in front of us.

C

So hey can I.

K

Get any special equipment used for the testing or.

C

So christo I still have the floor here. You you do. I suspect he can't hear us.

I

Okay, so the the question I want to ask is: did you do any adjustment to the psnp.

I

Response time, because there was a presentation last time from sarah and tony that indicated, that that made a big difference.

G

Right now, in our test, okay, ipsnt, its interval- is a constant in the standard. It is five seconds, but right now, in our test, we set it to 800 milliseconds.

G

We think it is already small enough and we try to send that act as soon as possible.

I

Okay, uh second, quick question: is the the receive window that you talk about? What you're actually doing is just monitoring the local retransmission queue for each interface, correct.

G

Yes about about this issue, actually we also discuss it internally.

G

Okay, we need to get uh get this kind of control, so the kill size and acknowledge the kill size. It is one condition and how to say that. Also, we also can get some feedback from the the the receiver side. All of this is possible because sometimes, especially in ss, some scenarios, no enough information to control it.

G

Sometimes on some interface, we we can just check the the secure side, some condition. Maybe maybe we needed the receiver side feedback. Some some information.

I

Okay, I just wanted to clarify what you actually did in your test. Thanks.

G

Okay, thank you.

L

C

When he turns his audio on um when he turns his mic on, he can't hear anymore, apparently.

C

Yes, we can hear you.

C

K

Can you hear me.

K

I'm gonna turn it.

K

C

uh Yeah, just uh try asking your question in jabber, uh we've got about a minute left bruno, go ahead.

E

Molina from orange, do you hear me yeah, yes, and thank you for the test uh very useful, uh similar comment from compared to lesser.

E

When you lose a test with a static window, it would be useful to uh to acknowledge the lsp, the receiver xp faster, as as illustrated by uh sarah on turning uh one or two years ago, because it allows allows you to have a dynamic acknowledgement on the dynamic adaptation of the other windows.

E

If you, if you want to do more tests, you would be interested to so to acknowledge uh clsps every every every few hp's sarah antony proposes.

E

E

C

M

C

Is from jabber now is: was the testing done with a software-based uh simulation, or was it done with hardware.

G

So about next step will we will keep on get more suggestion and try to do more test case and right now, for the case 2 and k3, we only tested the single link.

G

Maybe next time we will confirm, we will test it on the on the parallel link and the dual dual home network, because in the in the singling the the parameter adjustment is simple, but when the tester test device, how many peers, so it means all of this all of this parameter.

G

Its adjustment will be more difficult. I I think, next step we will test test, complex scenario, uh pyro link and uh and dual home network. Even some. All of this kind of scenario is mixed.

C

Did you did you use a hardware like router hardware, or did you use a software simulation.

G

uh uh They test it in huawei hardware, uh okay,.

C

Thank you that was, that was gehan's question. Thank you. Yeah yeah.

H

C

C

Okay, um we need to wrap this up. Unfortunately, uh the song.

C

Yeah, you can't be heard so we're going to move to the next one, um because we're two minute two or three minutes over.

H

Yeah g g's going to do it uh jay's going to she's going to do it. Okay,.

N

H

Thank you again, okay, thank you. I mute my mac.

N

Hi ac hi. Chris. Can you hear me? Yes, okay, great okay! I will present this on behalf of youtube because we have some natural problem. You cannot log in to this meeting.

N

Okay, okay, so this topic is about using flux. Algo for second routine based vtn here are the draw. This is a zero version version zero one, and here are the closers. Okay, next page.

N

Okay, here are some background about this work. uh We introduced uh this term of vtn in the draft itft's enhanced vpn. Basically, it is a virtual android network with the required topology and resource characteristics, and then we introduce the term resource aware seeds in draft itf spring resource, aware segments so that src's can be used to represent different sets of resources allocated for the packet processing.

N

Then we have this sr4 vpn, plus described in the spring draft, as iphone has vpn. Basically, it describes the mechanism to build as a base region with a resource, aware series.

N

Then we think this draft is more focusing on the control plane mechanisms more specifically how to use flux, algo based mechanism to distribute the information for the region, specific topology and resource attributes to natural nodes and also can be collected to the network controller.

N

Okay. Next page, please.

N

Okay, this is uh the mechanism we use in this draft. Basically, we reuse the flux algo id as the control plane, identifier of a vgn, so that we can use a flux, argon mechanism to describe the topology constraints of mvtn, and we can also use the isis extension as segment routing extensions to advertise the algorithm, specific prefixes or srv6 locators.

N

Then we also need some mechanism to advertise. The t attributes associated with uh hvtn here are the extensions we use. We use the iss l2 bundle with some extension to advertise. These t attributes for each vtn, and we have made some uh small extensions to our the l2 bundle to make it uh applicable for both physical and virtual member links. We introduce a new flag, we to indicate the member link of virtual links, and so that we can associate the vtn with one or more physical virtual member links in a bundle interface.

N

We need to use the admin group or the extended admin group to correlate a flux, algo and the member links so that the key attributes and the seed attributes advertised for the member link will be belong to the corresponding vtn, so that the everything can have this kind of kind of information for the controller and for the computation of the past.

N

Okay, next page.

N

Here are the updates in this version. Basically, we didn't make a significant change to the mechanism and the mechanism is stable since the 0 version. In this version we add some description about the forwarding plane behaviors about waiting, specific prefixes and adjacencies.

N

We also add a reference to the itf spring resource, aware segment draft, because the resource overseas are used in the data plane of this sr based vtn. There are also some editorial changes to improve the readability.

N

Let's page, please, okay, then, for the next steps. uh The authors think this mechanism and the content are straightforward and is stable so that we would like to ask for working group adoption of this document.

N

Okay, that's all thanks.

B

uh Jade, just uh speaking as chair, can you can you start a thread with some more uh with some more discussion on this draft before we uh see if people get people to read it and socialize, and I know it's been around, I read it and I understood it all, except the need for the v flag, wasn't clear to me that part of it wasn't clear, but.

N

Okay, you mean we can start to have more discussion on the mail list and then have the adoption started on the list.

B

Right- and that was the this- was the first time I'd read it I mean I read it rather quickly. I see we have peter on the queue.

N

B

Go ahead, peter.

O

Can you guys hear me.

H

O

Okay, okay, I I commented on this earlier on the list. The way the constraints are being used for the bundle. Members is very it's saying: the complete truths.

N

Yeah, yes, I understood type peter. I think we had a discussion on the list and we will explicitly explicitly mention that uh restriction in the next version of this draft and I think that's a good point. Thank you.

C

Okay, uh ac, by the way, I'm muting, so I can type so if you want to do the handle the queue that'd be great, I I think we're ready.

B

C

B

Yep, okay, I think we're ready for the next presentation again yeah. Let's take this. Let's take this discussion to the list. I don't think too many people have read it in the interesting time. We won't use the show of hands tool.

B

So next on the agenda is another vtn uh draft, this time using the informational draft just using multi.

B

M

Okay, can you hear me.

B

M

Okay, thank you. Should I stop right? Yes, go ahead, okay! uh Yes, this uh presentation about using iss, smart topology for some ranking based uh vtn uh beating uh uh the hustle vpn is a enhancement to existing vpn service to support the needs of new applications, uh so it can be considered as a revolution of traditional vpn, uh but with additional subspecific commitments such as isolation and performance guarantee, so it may be using uh using 5g transport network slicing and other genetic generic scenarios.

M

M

This is background. uh The draft proposed to reuse the mrtid as a control plane, identifier of vtn soviet, has been introducing the previous slides.

M

So it is a virtual panel network with the required quality and reduce resource characteristics.

M

M

Resource awareness segments is defined, resource awares in state, so src can require different set. Results are looking for packet processing. Your third graph is about the second routing for enhanced vpn.

M

It is uh described the mechanism to build srv service srbs the meetings with resource awareness, so in this uh the mechanisms described in this document assume that each region has a dependent apology, so that reaching can be identified using the corresponding mit and tips.

M

M

This is the introduction of boxing mechanics of this draft.

M

uh Fc uh 5120 has been defined to create a dependent policy in our network, with a single access domain, a set of independent topologies that we call empty topology, I'm at mt. This magnetic station can be used for variety purpose,.

M

It's also been created specifying custom customized attributes of each product each topology, when each vting has a dependent network topology, the mit id could be used as an adding fail of beating the control plane office. 86 67 describes less extensions that need to be introduced for sound routing operating on mps data plane.

M

The draft srv as the ssrv6 extension describes the assets initiatives to advertise topology specific nasa basic location analysis.

M

So in order to perform in order to perform the constraint basis, pass computation for utility on the network, controller or integrated nucleus nodes. The network resource attributes associated with each btm needs to be advertised when maximum link bandwidth sub tv is carrying the mt as an idea of topology.

M

It indicates that amount amount of link bandwidth value to the corresponding return. The bandwidth allocated to a meeting can be exclusive for service, carrying the credit. Only return next.

M

So this document was present in the itf 108 me as a working group based on the discussion and the suggestion from the working group. The document type is changed to informational and the descriptions about the forwarding plane. Behavior is added in new text continuous results, aware state are used in a data plane of srvtns, so the draft of spring resource aware segments is added to the reference section.

M

We also made editorial change based on comments. Next.

M

So, for the time being, the content of document is stable. Document type is now informational. The previous one is standard track, we're matching it to the informational. So we would like to ask the working group to adopt this document.

M

This document received a lot of comments from different people in within amazon. We really appreciate that. Thank you. This is.

B

B

Any comments on the draft anybody.

B

I think this one's more straightforward than the other one. uh I guess we could. We could put it in the queue for adoption. Myself, that's my opinion, speaking as a working group member, but we can. uh I I think we could do it. The only question would be and would be whether it's needed- and I think it's good to have an informational draft explaining this.

C

Myself, uh so we have a few minutes and nobody's in the queue. Do you want to try to use the hand thing?

C

Okay, yeah, all right. uh Do you remember how to do this? Okay, show of hands tool all right, so the the question. If there's a show of hands tool on the left side, uh the question is: uh do people support adopting this draft?

C

Okay, so, like I said, there's where the participants are normally listed, you click on the little bar chart and then you can raise your hand. Looks like people are understanding it.

C

um We have the 15, 16 voters, voters yeah, we don't vote, but we raise hands.

C

C

Everyone will see the results when I hit it and I think I don't know if people see it right now.

C

B

C

Yeah, because only the chairs can see it, I think.

B

Oh yeah, I think only the chairs can see it.

C

Oh joel joel says: they're visible, okay.

C

Awesome great, oh, it's! It's still changing all right.

C

uh There are a bunch of people in the queue now do you want to call them out.

L

B

Remove from I can't remove myself from the queue can you remove me.

C

Oh yeah, no, I mean, I think we should have called them to talk.

L

Yeah yeah, no, I'm gonna, I'm gonna again.

B

Do you want to send audio.

L

K

L

Okay, we can hear you, can you hear me? Yes, can you hear me.

P

Yes, can you hear me.

K

Yes, I can't, I can't hear anybody else.

L

C

uh Can we move to lower.

L

Yeah lower, can you send audio hello.

L

Can you hear.

L

L

Lower can you you can speak lower.

L

Sorry I yo you're asking me something yeah. You were in the queue you. Maybe it was a mistake. Oh okay, that must have been a mistake. Thank you. Okay,.

C

Okay, all right well we're out of time on this slot. uh Let's move to the next one, um so we it sounds like we can ask for adoption on the on the list. It was pretty well supported in the by the call of hands too, uh not necessarily that'll get adopted, but you know it's worth probably putting it out there all right. Let's, let's move on, I think thank you.

H

C

This will be you ac.

B

Yes, I'll try and go fast.

O

B

Okay, okay, you can move forward I'll talk to this on the next slide. Okay, this is a very old draft that we dropped work on the transport instance and uh there were really two motivations for reviving it. The first one was there's the mechanism, and I applied the known as the gen app uh graft or the generic isis instance. Rfc 6823 did go forward and it seems like a recurring theme now is to advertise using the igps to advertise information. That's really not related to routing, so we revived it next slide.

B

There's a number of use cases, uh some of them being present at this ietf or past ietf, some that are in the queue where we want to where people are proposing to advertise non-routing that information in the in the in ospf, and that would be one use case. One this is one use case on here- is the multi-axis edge computing for service discovery of uh servers, supporting various services.

B

uh Another one we've also had some people some discussions of running, putting more information into lsas, so the information could be exposed across areas now right now, there's a number of ways: you could do it, you could run more bgpls sessions, but another way to do it. You could use the transport instance and send uh this information from other areas just for bgpls purposes in the transport instance session.

B

These are hypothetical. This draft isn't about this, but uh next slide.

B

So what is the transport instance? A transport instance is a is a pair of a parallels parallel session, or I mean you, you have you set up separate, ospf adjacencies and you do not send normal routing uh topology on them.

B

You can do this and you can use the same links because the ospf packets have an instance id already ospf. B3 has always had one, because but ospf v2 you'd use rfc 6549, which supports, is an extension to the packet formats to support an instance id.

B

So you can differentiate demux the packets when the ospf packets, to the the regular routing instance and the transport instance, as as a as a the relationship to normal ospf instances it ships in the night you may want to use, depending on the information, that's being non-routing information, that's being transported, you may want to have the condition of reachability, where you wouldn't want to use the information unless the node that advertised it was reachable in the uh in the in the uh in the normal routing plane in the plane.

B

uh That depends on now. How strict you want to be is dependent on what this application data is, and you could also, uh if you didn't, want to impact the packets on the wire, you could make these lower priority for the transport instance next slide.

B

Okay, uh one thing about the transport instance: it does you don't install any routes, so we will have the topological lsas just so you can debug it, and you know uh you know what uh what for routers make up the topology for dissemination of information in a transport instance, but you wouldn't have any of these other lsas and you would not install any routes into the rib next slide.

B

Now one thing that's interesting about this: you can support sparse topologies. In other words, you don't have to have the same ospf routers connected to one another. I mean you don't have to have the same set of sessions for the transport instance as your normal ospf uh instances, and you can also support the concept of a pre-configured ospf neighbor. That is more than one hop away, so you have a remote neighbor, which is pretty powerful because you think about it.

B

One of the problems with uh putting things in the igps is every router gets it when only a small subset of of the routers need to get it with the transport instance, you could say have a controller and it could have ospf remote neighbor sessions with only those ospf routers that need to have this information whatever it is now, the concept of multi topologies for routing is inapplicable, but you could have even multiple transport instances for different types of data with different types of different topologies.

B

When I'm for disseminating this information next slide.

B

We're using the same encoding that we use in all the ospf tlbs, it was dates back to rfc, 3630.

B

And it was carried into the opaque lsas well in ospf v2 you could you'd use the opaque lsas and in ospf b3, because ospf v3, it's very easy to allocate new lsas in a backward, compatible fashion. You'd, preferably uh define new lsas for this data.

B

Conceivably, one could use the extended lsas and piggyback on the normal ones, but I think it would be better to keep this information separate. We can take it as a case-by-case basis.

B

As applications are defined to use the transport instance next slide,.

B

I think this is the last one. Here's just one that we had talked about. I talked about with yin xen is for this multi-axis edge computing to identify the servers, and you could put this in no an ospf v2, opaque lsa and an ospf v3. A new lsa type uh you'd identify the servers by their application address. That's the address and you'd have have a service id for the type of services, and then you'd have uh cpu usage and the thresholds.

B

This is just one example, but you could use this for many different things.

B

B

Okay, we're going to see if there's interest in this and right now we're not asking for working group adoption we're just going to uh ask for comments and see if people are interested in in using this uh aizen hello.

F

So how about put the information in one independent, top tier way, which can be only be included, included in the router lsa?

F

So we can. We need not define the separate otp instance.

B

I guess it depends on what the information is that you want to put in the router lsa.

F

Yeah, currently you you just mentioned some information related to the server, so I think it has a similar application for another job that provided by the linda. So I think we can think we can try to put the information in an independent dialog. I think it may be more simple for your solution.

C

Yeah, I think that this should be discussed on the list for sure, especially in the context of some of the presentations today coming up later, that I think you're referring to okay, uh okay, less.

I

Just um I didn't realize until just now that you had revived this um 6823 introduced uh an application identifier with a registry. You know to control the assignment of the applications.

I

um Do you think that that concept has any relevance here.

B

Yeah, let me look at that. We'll look we'll take a look at that.

I

And you know, maybe we could we'd have to change things a bit, but maybe we could share the registry between the two igps.

B

Yeah, okay, thanks, you know uh robin was in the queue too. I I removed him by.

B

Mistake see he's back in the queue go ahead.

C

C

Q

C

Yes, we can hear you, okay,.

Q

Okay, they say I have the similar the concern as a hygiene, because, from my point of view, because I introduced a instance because I think there is a problem- the complexity for the network evolution, because this may introduce more configuration because we know the pdp- they always use the same session to support the different services.

Q

So, from my point of view, maybe we can also take the similar mechanism and also use for the better network evolution and also reduce the possible the cost of the igp.

Q

So that's my comments on this. This uh draft.

C

Thank you guys, I don't know, do you really think that you fix things you're in the queue again? I I do we're we're four minutes over, so I think we have to cut now and move to the next presentation.

C

Yes, we can hear you.

D

Okay, all right, I I think I fixed the issue.

K

It seems similar to, like I guess, like an isis multi topology, I guess or let's say flat salary. Would it work? Let's say in conjunction with it like, let's say the layering concept, where you can do like multiple sparse instances um and let's say if you had flex algorithm as well, would it um could you use it to leverage, I guess in some way or maybe instead of using a normal identification? I guess leverage flex, algo or I guess, use this in conjunction. I guess possibly request algorithm.

B

I I I don't think so, because, because this is about distribution of information, not computing different uh paths, the transport is for information that isn't for routing. Okay,.

C

It's it's. It's actually really it's a direct analog, an analogous draft to what's in isis, gen app, I don't know I have the rfc off the top of my head.

K

I got you so it's really just transport. I guess right. No routing construct.

C

All right, we need to move to the next presentation, thanks ac.

C

Thanks this is.

F

C

Flex algorithm: yes, we can hear.

H

P

Barack canaria will present this for me.

B

Okay, that's great.

C

C

R

Hello christian, can you hear me, I can't hear your voice christian. We can hear you yeah. Yes, we can hear you okay, yeah. So let's get started. Welcome all to the presentation. This is from juniper network presenting the draft flex algorithm in ip network. On behalf of the authors next slide, please.

R

So this is the agenda of today's presentation. We will go through over the introduction use case and propose solutions and that will be covered in the next slides.

R

Next slides, please, okay to the introduction so currently the igp flex, algorithm compute the constraint based part to the segment routing data plan, which is like sr mpls and srv6.

R

So, therefore, the igp flex algorithm cannot be deployed in the absence of srm, pls and srv6.

R

So idea of this draft is to extend the igp flex algorithm, allowing it to compute the constraint based part to the ipv4 or ipv6 prefix in the ip networks.

R

So the with the with this graph, we can deploy the flex algorithm in the ip network in the absence of srmp less than srv6. So this cover the intention of this draft next next slide. Please.

R

Now, how do how do we associate prefix with the ipflex algorithm? This can be done in via the egress node procedure, so the loopback interface is associated with one or more ip addresses right. So each of this look back address is associated with the flex algo, so we can associate one loopback address with the ipflexalgo.

R

So if packet sent to that loopback address associate with the particular flex algo, it follow the constraint based path calculated by igp during the computation. Otherwise, the packet follows the igp list, cost path.

R

Yeah next slide, please.

R

uh So one more thing like association of this address to the ipflex algorithm implementation independent operator, is free, free to choose existing mechanism or any new mechanism for the ip address to the flexelgo association. Now coming to the advertising part of the ip flex algorithm each participating node advertise an ipv algorithm sub tlv. This is new subtle. We defined in the draft, so the for the isis. This sub tlv will be present in the router capability tlb and for the ospf it will go as a router information lsa.

R

So the participating router by ascending this tlv intent to participate in a particular ip flex algo throughout the domain. Next slide. Please.

R

So advertising the flexible definition, all the router participating in the ip flex algo must agree on the flex, algo common flex, algo definition, the selected node within the igp domain advertise the fed, which are agreed by the old node and for the ipflex algorithm. We can leverage the fed protocol machinery defined in the internet draft ls reflex algo based on the section 5, 6 and 7.

R

So the this new ipflex algo will use the flexalgo machinery, which is already well defined in the fade algorithm.

R

Next slide, please.

R

So we have set the common ground by advertising the fed and the ipflex algorithm throughout the igp daemon. Now we have to associate the prefix with the ipflex algorithm and we have to advertise reachability throughout the igp so to be able to associate ip and ipv6 prefix with flex algorithm a new top level tlb defined in the isis.

R

This tlv are the ipv4 algorithm, prefix, reachability tlv and ipv6 prefix ipv6 algorithm prefix, reachability tlp. We cannot use the existing uh prefix switchability tlb because by default it is associated with the algo0 in the igp right. So we have curve out two new tlv for the sending the reachability of ip flex, algo tlv.

R

So this new tl we share the same uh set of the sub tlv space defined in tlb, 135, 235, 236 and 237. The point to note here is like the whole sub. Tlp of this tlvs can not be applicable, for example, prefix prefix segment. Identifier cannot be part of this ip flex algorithm.

R

uh So now let us look at the body of this tlv it. It has a metric and the associated flake algo and the prefix and prefix length and the bunch of if there are presence of tail v, it will go in sub tlp fields.

R

uh Just the point to note here is: I have not defined the type and length at just a moment yeah. So the point to note here is like uh due to the space constraint in this slide. I have not defined the type and length field of this new tlb, but it is well present in the draft here next slide, please.

R

So. Similarly for ospf, uh we have to define a new tlb for the ospf v2. This is la, and this tl we go as a ospfv to extend opec lsa for the ospf topologies and it has like empty id, algorithm, prefix, matrix and other sub tlp of that tlv.

R

Next slide, please so now on the calculating part of this ip flex, algorithm tlv, algorithm graph right so as we know that the ipflex algorithm is yet another replication of this flake algorithm.

R

It follows the same procedure of the calculating the constraint path defined in the internet, draft ls or flex algorithm in the section 10, 11 and 12..

R

So when the ipfx allowed to compute to a node, it must use the corresponding flex, algorithm participant participation, algo and it compute the constraint based part which is independent of the underlying sr or srv6 path. Algo, if present, and this iplex algorithm can use the lfa protection mechanism which is well defined in the igp, also the s, the sr segment, routing, flex, algo and the ip flex and go go parallelly in the network. If there is a need arise, they cannot interfere each other because they advertise different flex will go okay next slide. Please.

R

So since the this graph used the existing mechanism of the lsr flex algorithm and that is very stable as of now so, author would like to request for call of call for the adoption of this draft.

E

R

Please the author would like to thank you ietf for giving opportunity to present his draft. I would like to ask for any comments.

R

Suggestions, so thank you once.

S

C

Yes, uh ac you're you're in the queue okay, okay,.

B

Yeah yeah: this is ac. uh Why did you define a new top level uh tlb for ospf extended prefix lsa? Do you mean.

B

I guess I guess I I was wondering why you just didn't you use the existing one, I'm not saying it's wrong. I was just wondering the the the reasoning.

R

uh For the ospf right.

R

So you mean to say we can use the existing ospf tlb for the same, but that that is a specific to the algo zero right.

H

B

R

O

We can, if I can jump here, we can't use yeah, because the existing one would advertise delga, zero reachability.

H

C

N

Can you hear me.

C

K

Trying to test before the next.

D

The question I had was: um how would.

K

um I guess interoperability work with uh segment routing I think you may have mentioned, but let's say that you wanted to use this and, let's say with srv, let's say with srv6, which you know reuses the ipv6 data.

K

Could this used in conjunction or how would this work, I guess with the uh flex algo, that's uh that's utilized for sr. I guess. Would there be any benefit or reason to do that.

R

So I think voice was not clear, but let me repeat it like the gyan was asking: how do we? How does it benefit to the.

D

Srm pls srv6 so, let's say using it with srv6, um since I think since srv6 uses the ipv6 data plane, could this be used with srv6.

R

But this this, this draft is independent of the any existing srm plus or srv6 right, maybe the operator if they doesn't want to run- or they don't have this hardware capability. They can use this.

R

You know software based uh programming in the hardware and can achieve the same level of the data plane, separation or the network slicing.

P

May I add to that yeah so long as the addresses that you bind to flex algo are different from the locators that you bind to flex algo. You should be able to run them both at once, but the question is: why would you ever run them both at once.

K

I mean, I guess if you had multiple topologies and maybe you had later, you know different layers if you're running isis, multiple apology or different instances, but I agree it would be very corner case that you would do that.

C

um Correct me, if I'm wrong here ron, but I I thought this is kind of like an alternative to sr right.

P

Yes, uh that's why I ask: why would you ever run them both at once.

D

D

C

Okay, thanks bruno you're up.

E

uh Thank you for the presentation. I haven't read: draft001, sorry for that. The question is specific to isis on ipv6 and when writing draft all zero zero. It seems that what you're trying to do, which is useful, is already available.

E

It is currently called srv6 flex algo, but it does not use any uh srv6 srh sr, it's only ipv6 so um for ipv6, it's already available. So why do you need to define a new tlv for isis 1966.

R

So you mean to say why there is a different tlv for ipv4 and ipv6 in isis.

E

No, I mean why there is a different leds between ip flex algo ipv6 on srv6 flex, algo.

R

um Okay but see the srv6, I was so yeah hello.

O

R

So the srv6 of tlv has like the subtle ways like ncd and other stuff right which are not applicable here right. So we cannot use the same tlv of srv64, ipv6 or maybe.

E

R

Can you add anything.

O

Yeah, I I guess in theory one could do that and use the locator tlv without the seats that is not prohibited at the moment. So one can do it. I don't well. I don't think that would be from the encoding perspective. That would really be something that I would prefer, but you know, theoretically, you can advertise the locator without any sid and treat it as ipv6 prefix.

O

Whether we want to do it or not. I would rather not to. I would prefer to have a clean encoding and not mixing things, but in theory you can do that.

T

So locators locators are uh are not 128 bit right here. It's.

O

Okay, recent address.

R

Yeah, but that cannot be a 128-bit address. I guess yes,.

O

Okay, well entirely, it has a prefix and a mask, so it can be. I'm not I'm not uh suggesting me to do that. I don't like it, but you know in theory, one can do that.

E

But by siri do you mean that some implementation would not support or.

O

No, no! No! No! I basically bruno what you're asking is why we are not using the located tlb right. That's.

E

O

Well, as I said, one one can do that, I don't think we want to do it, but the functionality is there. Yes, okay,.

C

C

Peter did you have something else to say no yeah, okay, tony you're up.

C

You will have to unmute yourself the little mic up in the left side.

A

There we go hi, I noticed you just published the dash 01 draft with less than 24 hours before the meeting. I was wondering if you could quickly summarize the changes.

R

So in the draft zero on right, we have merged the in earlier draft. We have, I mean we have not counted the empty id. We we have four different top level tlv. Now we have merged to the two tlv, the top level tlv of the ip v4 and ipv6 header, which contain the empty id of 12 bits and some reserve bit. So with that we can use this. We can reduce the number of top tlv to 2 and which also cover the mtid multi topology instance.

R

Also, I think, other than that there is just editorial changes, not much.

C

Okay, thanks g europe.

N

Okay, yeah, I think, uh can you hear me.

E

N

Okay, uh I think I send some comments to the list uh here I want to restate: uh can I think, basically, you defined a new application to use flux, argo and my question is: can different applications use the same flux, argo id and, if so, can the past computation result be shared or the past computation should be done for each uh application, even if the id is the same.

R

No, I think uh it's not good to use the same flux algorithm. Then there is a conflict happen right which one to prepare for the forwarding.

O

R

O

So, strictly speaking, perfect, you can it's completely bad and need rest of the calculation for each application, nothing to see to use the same flex algo it works.

N

Okay, but the competition uh for the same flashlight with different application will be different. The result yes right.

O

And if you read the draft, the latest version me just publish it. There's a section that describes that.

N

C

Okay, thanks uh we're out of time, so we're gonna cut the line right here. Your last stop.

R

Very quick thing uh is uh ketan, talalik or cisco. uh I I actually support the flash. uh You know new tlvs and encoding not to mix with the existing reachability and even the srv6 locator. I think this is also because uh for srv6 the participation is advertised by the sr algorithm, whereas here we have the, you know uh ip algorithm.

D

So I think it's better to keep them separate, just cleaner.

C

Thanks ac, did you have any comments on the adoption uh request there? Do you think that's ready for that or I I.

B

You know you know this, this generated with applications and using in parallel with srv. It generated a lot of interest already, you know, probably over 100 emails.

B

um I think it would be ready for adoption just based on the interest. That was my opinion.

C

Okay, unfortunately, we don't have time to do the show of hands, so um it sounds like we we may be moving forward with that. Then.

B

Yeah- and I I was just gonna say I I looked again just when, uh as we were speaking and I agree that separate tlvs or our top-level tlvs are the way to go for ospf.

C

Okay thanks prague.

D

Thanks. Thank you. Thank you. So much.

B

A

B

B

J

L

We can hear you.

J

Oh, thank you, uh hello. Everyone. My name is jali wang from huawei and nice to hear you guys all and I will present less new draft about the idp extensions for advertising, the hobart hub options, header processing action and next.

J

Please, okay, so uh as specified in rsd820 the uh hubble hub option. Headers is only examined and processed process processed by nodes along a package delivery path uh if they are exp explexity uh configured to process. So in less draft we considering to signaling the nodes capability uh to process the uh hubble hub option, header so um based on the rfc specified.

J

We notice that the nodes may be configured into several options: the first one, maybe it's configured to ignore the hubble hub options, header and second one is job it and another option is assign the packet to the slow processing path. So here we see that the problem is different. Devices can be configured to process the options header in different ways, and we found that there's a a lot of service to use this hubble hub options. Header such as the iom and another one is the alternate marking measurement.

J

So so we think that if node are not configured to process this option header, they may ignore them or drop this service package. So it will result, it will not account for all links to performance measurements and will result in the packet loss.

J

So this document and define them defines a way to signal the configured processing action of this hub hub options, header and using the isis and ospf so by advertising uh less information.

J

This can be helpful for uh entities to gather less information and based on this topology and to come calculate the process for specific services uh requires the hobart hub options. Header next page, please.

J

So uh in let's dropped. We first first defined the hobo options: header processing action. As we see english, the first figure we defined the hobart, hope, processing action, uh information forms of uh three uh field. The first one is the eight bit action flag field and the second one is the 8-bit maximum extension header lens field and the last field is the 16-bit service flag.

J

So the action flag, we use the higher highest order, 3b to indicate the uh supported, processing action and the the max extension lens field.

J

We indicate the the length the maximum length of the extension header can be examined and processed and the node or link grand granularity and the last field is service flat. uh It's to indicate the supported services uh requires the hub hub options, header uh here we we, we defined two uh bits, the one the the first one is to the ion tris option and another bit is the the alternate marking method and on other beats, we will reserved for future use.

J

J

So, uh based on the definition of the first processing action information- and here we propose the extensions to the isis protocol and we defined the node processing action. Subtrees sorry extend it to access router and capability to and another extension is the link processing action action sub theory and to indicate the actions of the interface or social associated with the link.

J

So uh in yeah, in this document uh we define because we define the node and link processing action uh theories and we we need to mention that if we all the uh interfaces or social was associated with links supported the same processing action. So we we need. uh We need just to advertise the node capability, tlvs yeah and the list page. We shoot the signaling processing action using the ospf.

J

Similarly, we extend the nodes, processing action theory and the link processing action. Sub tube is extended to the the the os ospf router information pack osa and for the ospf version two. uh uh We defined the link processing action, sub tvs of the extended link tov and for the ospf version 3. We extend it to the e-router ls tv.

J

Next, please please. Yes, this is all the content in this dropped and the comments are very calm. Thank you.

L

C

Yo uh hi ali, so this is this- reminds me a lot. This reminds me a lot of the ifit one, which I also sort of had issues with. um I noticed the latest ifit uh draft uh now mentions uh using the information for path computation.

C

One of the complaints uh before was that this was sort of you know, capability stuff that didn't that had to do with oam and not routing right, and so it wasn't appropriate to put it into the routing protocol.

C

So you know, I guess my first question with a follow-up based on your answer is: are you going to use this uh to determine routes through a.

J

Network uh thanks for your questions and and thanks for your comments for the I think I dropped uh in the last meeting and for this draft we we want to mention the motivation is to advertise the the whole by hope processing action, not the iphat capability. So this is not the same. uh The problem we think and because we're considering the the nose or the interface uh supported the processing action for the callback hub uh header, it's uh may uh affect the the past and computation.

J

uh For example, if we we, uh if we have the service using or require the hardware hub, header options, we need to determine where we need to know which nodes or links supported to process this extension header. So this is not the same. I mean.

A

J

With the I f8 capability.

C

Yeah, no, I understand it isn't, but I I'm just thinking I'm putting to throw like an operator hat on and I'm looking at this and I'm wondering like you know, I buy a bunch of routers and you know- and I want to do oam on them and do I really want my traffic being determined by whether I've upgraded my line cards or do I want to just upload my line cards and uh and then use my oem uh software right? I just I you know, I'm not sure.

C

I believe the use case that you know that I really want my network uh paths being determined by whether I've got an updated line card or not. I I mean I'm not saying that it's not that it wouldn't happen. It's just it's. It feels a little funky. That's all um thanks.

J

Thank you. Okay,.

L

Okay, loa: are you in queue, loa.

L

Number four.

B

Okay, I guess I'm in- I guess I'm in queue next, so these are all these oem techniques. I didn't look them up, but they're inbox they're in band techniques right.

J

In statue yeah.

B

In in yeah in situ yeah in band, okay, yeah.

S

B

And so the basic proposition that chris was getting at is that these you're going to compute only those paths that support these oem techniques, because you need the uh performance that data to measure your slas or something of that nature. I.

B

L

Okay, you go ahead. Ron.

J

uh Yes, that is the one case uh we mentioned in the draft, but I think there's a lot of use case use the hobart hub options: header, okay, yeah.

B

Yeah, but the only ones you have bits for the uh are the oem techniques, so those are those will be the ones you're you're advertising today.

C

I think we need to cut the line uh right right right ron go ahead, yeah go ahead.

P

If the only application for this is past computation, couldn't you achieve the same thing with link colors.

C

Yeah ron, actually I want to answer that. That's what I thought uh I I thought you know like okay, so I I've got line cards. I just mark my interfaces that support this right and and I'm.

P

Done that's where I was going with it.

C

Gee you're up last yeah.

N

This is jadon and, to my understanding, this documentary aims to advertise some generic attribute of the packet processing capability regarding the hub option. Headers. I think there are also other use cases in addition to the iom or if it functionality such as some traffic, which may need to carry the hover hop option header to for some processing, behaviors required uh on each hop along the path.

N

So well, we have another draft in the six man actually related to this uh hub option. Header extension, so I think this can be a generic mechanism, and maybe some application would require to select the route based on this capability.

C

Yeah, maybe we can see how that goes as that moves forward to see if there are, you know that that moves forward some other options, we've got to move to the next presentation. Now we're going to run out of time. Thank.

B

C

B

I think uh uh jin's gonna present for uh for the offers he's in the queue.

B

Let's see how that works. Yeah or I see I love itunes in the queue too hello. I see.

F

Are you presenting yeah, I I let let me try to make repetition for the passive interface attribute. Okay, thank you.

C

F

Oh, thank you. So uh this is the third time to make the prediction so next slide.

F

uh Yeah we uh so we want to hear uh information. uh What what do we want? What's the proper one to show you know, passive interface are used commonly in the network. uh Here we just list three three scenarios. The first is in the data center, so they are used for the villa interface. Let's say in the layer two broadcast domain and the second scenario for the interest boundary.

F

They are used to protect each domain from igp, flapping and called by our command, and the last scenario is described in our in one drop that provided by linda for the edge computing scenario. I think it is the same as scenario as the ac has just created, but currently there is no suitable place to advertise the pencil interface and their associated attribute. So we want to find some place to put this information in in the protocol. Okay. Next, please.

F

uh They also investigate the existing possible solutions for iss. They are held defined by link attribute subtle. This sub theory can only be carried within the tlp22.

F

This glv is used to describe the attached loader, but for passive interface. There is no no idp router, so it is not suitable for for for the information to contain that in in this subjective way, uh ospf v2 also have one link type in the ultra lsa.

F

The type 3 can be used to flag the passive interface, but there is no other place to put the interface attribute and ospf v3 has removed the type 3 link type. So, as we said, it is necessary to extend the opioids mutual history and iss to transfer the passive interface and their related attitudes. Okay, next.

F

Please so here is the eq. Actually two excessive propeller, currently rc 7684 defined or fpv2, extend the link opec lsa to contain the additional link recipe of the tlv, and only the extended link theory is defined, uh so we propose defined, extend stabling theory to contain the subtleties related to the peso interface attribute.

F

This is the format of the theory and the existing subtle, as defined in the itf logistic, can also be included if necessary. We um we have defined one new sub tlp in the in. I will describe later our next slide.

F

So this is for ipv3 for ipv3 and it finds.

F

It easy to defined the uh lsa in tlv tube, so it is easy to expand uh we. Similarly, we propose to define the root router stub link till we can uh to describe a single literal, passive interface.

F

As as the rooter link theory, this theory should only be contained within the extension router lsa. It can also reuse the existing subtle defined within the deleted ospf for registry next slide.

F

Yeah, this is for the isis extension proto uh proposal for isis. As we have discussed on the main main list, we can only define one new top theory to contain them to contain such information, so they define the uh theory at this format, and the uh related, releasing subject can also be included, is necessary.

F

So next, please next slide please.

F

So uh in this document we defined one newly a new subtlety to contain the ipo address information that associated with the pacific interface, for example, the the the server's interface address.

F

There may be several addresses to associate to connect with the passive interface, so we use the existing sub objects to include this information, and we also because this sub theology and the future news of the love is associated with the sub link can be both applied to the ospf and iso may proper to define one independent, legitimate code point which can be delivered by both igp protocol.

F

So next next slide.

F

Yeah, this is a for the practitioner so and we also discuss on the main list, so uh here just want to hear easier and I recommend for this job and can it be adopted w working group document. Thank you.

C

Okay, oh well, I'm in the queue I wanted to back up just one. Second, the previous. uh My previous comments on the other uh presentation, yali those were made as a working group member. I I'm supposed to say that each time- and I I sometimes forget- so it was just my work. Remember as well as these comments are as a working group member. um You know, I I'm curious about some of the use cases.

C

It seemed like on the mailing list that there was like one use case where it was inter, inter as and that you know there was some discussion that that was already covered by tlb and then there's a reference to like linda dunbar's uh draft, which I went and read, which was about sort of like using passive interfaces to describe load balance, load loading on servers with anycast addresses, and in that case it's it's like you know. Why? Wouldn't you just advertise the anycast as a prefix and attach that you know the attributes to that prefix?

C

Why would you call a server a link so anyway, it just seemed to me like there's it's. It seems weird to be using a link in these cases when you know if it's enter a s, there's already something for that and if it's servers, then why not use the prefix.

F

F

So I think the uh the information provided by the traffic described in by leader is connect to the connected scrap link. So I think they are suitable to putting too into the into this special interface attribute.

C

Yeah, I guess my point was I I think that drafts are wrong. It's describing a server and then anycast address and and then trying to attach the information for it to a link, but that just doesn't why not just do a prefix for the server okay, we can discuss it more in the list.

B

Okay, ac did you have account, I'm gonna be quick too. I the thing I'm thinking here right, rather than coming up with a generic uh way of advertising, that it's a stub link you're using the fact that it's stubbly to make inferences for these use cases. Why? Wouldn't you just advertise?

B

You know, because what you're you know that you have this inner ass thing. Why? Wouldn't you just advertise this as an inner as boundary or something like that or whatever your use case is, and we can discuss this on the list too. I think this is just when we have nine minutes left and you got one more presentation.

F

Okay: okay, let's discuss it in our main list.

B

Thanks and I'll review the update I'll take a look at the updated. When I see you just updated it in the last you told me you were going to do this, but when the window opened yeah.

F

We have open, updated the job, but I'm not not seeing the notifications on the main list.

F

C

C

K

Can you hear me? Yes, yes, okay, all right, so this strapped up, pua, prefix unreachable announcement.

K

Good next slide,.

K

So the motivation behind so really the main problem statement. I guess where this draft can be beneficial is in cases where you want to have a converge. The data plane so like so instead of again relying on control, plane, convergence uh to speed up the data, plane, convergence and one of the really the big use case for this would be for, uh and if you have a um your bgp next top attribute convergence.

K

So let's say: if you have external peers and where you, where you're marking your uh your your bgp next hop doing the next hops self. um So in that particular case, and you have a link failure uh being able to detect that link failure quickly with a with a advertisement with the negative advertisement saying the link is down and allowing your um if you're running, let's say bgp like pick core in the core, your hierarchical fib can converge quickly, um noticing that data plane failure and then you can and you're able to converge quickly.

K

Another use case for this draft is with um with summarization, where you have a area, a igp domain. That's subdivided into multiple areas, and you want to have you want to be able to switch the data plane, convergence from from one a b or your primary abr to the secondary audio, so that that's another use case and then within a within an area either link or node failure, so intra area link or node failure and being able to with this negative advertisement uh this prefix unreachable component.

K

So when a component prefix goes down being able to converge that data thing quickly, next slide.

K

Go ahead and excellent thanks, so this is a typical uh just a service provider core! You have edges here there you go yeah just that that one sorry, the previous one.

K

Yeah there you go there, you go okay, so so, let's say you have a typical service provider core and where you have the edges to uh you know you have bgp overlay services and you want to converge the core quickly um and where you're running, let's say be, you know, bgp pic pick edge at the edges and you're running, let's say bgp core, but the hierarchical fib you're doing a next top self to the route reflector.

K

So in that, in that case, you're you're rewriting the next stop to the loopback, but the loopback is always up so you're you're in the core. Your core doesn't converge as quickly because you you've done a rewrite to the loopback. It's it's something! That's! It can really exist at day, one you know with pig core and and to work around that. What you end up doing.

K

Is you end up having to advertise all of your external prefixes into the core which creates a bigger fib, so this work around what it does is with this with this negative advertisement, it converges that data plane quickly. So now you're doing this prefix unreachable advertisement of that link. That's down and you're able to converge the core quickly onto that um onto the new path.

K

K

So this is a topological um uh layout of a multiple areas where you actually have the uh pua convergence with multiple areas uh go on to the next slide.

K

Now so here in this scenario, this is a uh an inter area scenario where you have two avr. So in the center of the diagram, you have um router one and router three router router, three or router, two router four and they're, both abrs or or l1 l2 routers, and you have a a link: failure when that happens within the area or node failure. In this case we have t1, you know, went down on the left on the right side, and here we have s2 on the left side.

K

So in that case, what ends up happening? Is you end up having a summary advertisement that gets advertised by the adr so like on the right side? You have route r2 and r4 they'll advertise a summary back towards area one and on and on and on the left side you have s2 went down, so you have router one and router three they're advertising a summary. So in that particular case when, where s2 has gone down and the prefix is no longer reachable, you still have traffic that kind of heads back towards s2.

K

um You know comes up to r1 and r3 if they're both active primary um and then the same in the other direction, you would get an icmp back the other way, but you got traffic um going in that direction.

K

The other caveat and part of the problem statement is cases where you have component prefixes that are part of a summary where you have a false positive. That happens where the components are there, but then let's say the component disappeared and there's no and there's no component prefixes, but but the uh but the summary route is still advertised. So in that case you made black hole traffic um in those cases. So this what this does is with this negative advertisement.

K

It converges a data plane quickly, so you don't risk any any uh black hole. Traffic next slide.

K

So so, in this case this is the inter area scenario. So, where you have a node on the right side, t2 has gone, has gone down and you have a so. You still have a summary route advertisement that gets advertised by r2 and r4 into the background area: zero and then back over to area one um and and then so. On the left side, you have the summary gets advertised back over, but but now because the uh link the node t2 is down, um you have traffic that will flow because the summary is still present.

K

So you you have traffic that flows up to r4 r4 will send and we'll send an icmp back, but you have that data traffic that comes over to r4. So in a scenario where, let's say there is a partitioned, the network is partitioned or something happen.

K

Let's say r4 is not reachable, but he was reachable for a period of time, but became unreachable and the component prefixes were present and they're present on r2, but they're not no longer present on r4 and if we're still sending the summary route, you end up having a um a situation where you end up hole in traffic um so with this so go go on the next slide. So that's that's a use case with the node failure. I'm going to next.

C

Yeah we've got one minute left, I don't know if it'll cut us off or give us five minutes.

K

Okay, all right, thank you. um This go on to the next slide, we'll just go into uh skip a couple. Slides go to the next slide, all right. So this slide. This is a case. That's fine! That's right! Just keep it on this one. So, with.

E

K

Unreachable advertisement: what ends up what ends up happening is when you have that node failure happen so like on t2. The node failure happens. So now a prefix unreachable advertisement is sent. You know from from um from the abr, so r2 on r4 they detect and they send that the pua advertisement out towards, through the backbone over to area one area.

K

One sees that and then the route when, when it's flooded out to area one, they install a uh in the fib in the data plane and that's where the data plane, convergence happens and and all zero to black hole, the trust of the traffic. So no traffic is sent to that route and that's really for the abr. So let's say if, for some reason, let's say, there's a partition network r2 is down he's no longer reachable.

K

He doesn't have any component prefixes, but he's advertising the summary for for whatever reason, because there was maybe a race condition or something but he's advertising. The summary our four is still up, but we don't want any traffic to go to our two. um You know black hole in traffic, so in that case the data plane it converges on the left side so like also the routers on on s1, s4, s2 and s3. They end up.

K

You know poor programming into their fib, the um the to black hole that uh that lsa that's advertised to set the next stop to all zeros, so, basically, um not using not using that summary advertisement for that free for this, for that prefix. um So no traffic goes that frequency go ahead. Next slide.

C

We're gonna get cut off soon.

K

Okay, I'll just talk until it cuts off, go ahead. Next.

C

Well, I I mean, maybe maybe people have comments. I don't know.

K

Yeah yeah go ahead. Actually, why don't we? Why don't we just do some q, a I guess right now that would be fine, since we don't have much time left I'll. Just talk through this last slide. Actually, if you don't mind and then.

C

See which one you're a few seconds behind when I switch them.

K

Okay, sorry go to the next one at the last slide.

K

Okay, so this so with this uh prefix unreachable advertisement, there is a feature called uh maximum advertisement which uh in a case where you have um prefixes- and this is something that you know- could possibly happen where you're the number of reachable prefixes on unreachable prefixes, there are more unreachable component prefixes than reachable, so in that case it makes the pre. The summary advertisement work even more conditional that, typically, if you have a single component route, the pre, the summary is always advertised.

K

So in this case it would, there would be there would be a another uh factor or another variable that allows you to con. You know would be able to configure, so you don't always advertise and you could switch to only advertising longer matches. So it's just another layer of um condition. Conditionality, I guess with the um with the summary route, um so that's pretty much it with for the slide deck. um If anyone has any questions, um we can go ahead and go to questions.

C

Well, something occurred to me, as is being working. Remember when I was uh thinking about this. A lot of people seem to have complaints about the mechanism for drawing the unreachable and using timers and whatnot, and how it was you know, rift it was compared to rift and how rift had a more deterministic way to deal with it.

C

It made me think what you know if there was a way to attach the unreachable to the summary route, so that then you would just re-advertise the summary route with with or without the unreachable, the holes, basically right, and that way you know, if you don't have that problem timing out. That was just an idea.

C

I don't know how a bit I don't know if it's a you're able to do that, like in lsdf and stuff.

K

Right so with this, let's say when they route the so this these the uh prefix unreachable advertisement. They would only be present when a component is down. So when that component comes up the unreachable, like you know, it stops immediately. So it's it wouldn't stay, but it would help it would help for you know propagation, but when that when the summary is advertised, it would be the summary plus this this component, so it would be attached to the summary route.

K

So, when the the um the receivers- I guess on the other side, when they let's say on the left side, let's say when they receive the um the summary. The summary they'll see the routes, the components that are down and it will automatically program it in, but let's say program into the fib to stop. You know to drop traffic and not send any traffic to that. To that summary route right.

C

Now, if you have it, if you have it as a sub tlv, then you can withdraw by just changing this summary again right. I think we're going to get cut off in 10 seconds.

C

Do you want any last words.

K

um That's it, I mean, I think uh we could we just pick it up on on ml on the mailing list, um yeah.

B

Yeah, I was just I wasn't going to speaking as working. Remember I was gonna say, there's a lot of complexity here for the different use cases and it looks like you even added some additional use.

B

Cases in your slides and the interaction with with the rib is going to be quite complic, complicated that if you should describe what you'd expect to be installed in these cases uh and how it's going to work, because I I look at it and I said: oh, I yeah you know I can kind of wave my hands and say how it works. I think that needs to be specified.

K

Yeah, I mean, I think I think, that piece of it with the convergence- and let's say I- you know if you have a false, positive, false negative, I think with timers, because you're impacting the data plane it's supposed to make the convergence better not worse. So we want to make sure that whatever timers that we make sure that the um that, when services come back that- and it would be a flood that it would be part of the summary so when, when the um when the service comes back up, it's immediately flooded and removed.

K

So you you converge immediately as soon as and it would be part of the same summary advertisement same sub tlv. So when when when, when the service is back, it comes back when it goes down. Data plane converges immediately on that component. That goes down so just and it's for a link or a node failure, but really improving the um data plane convergence.

K

um I I think the big one that I I think you know overall, like you know, on on the mailing list, I think that came up with with the bgp which could be like in this drawing.

K

We actually have multiple areas, but if you had a single area and that issue with the next top self on your tie to let's say you know other you know customer yes's, where you know because you're doing that next top rewrite your your um your your bgp, like prefix, independent convergence, your your your core pick core, because that that hierarchical fib that now it's dependent on the loopback doesn't go down. So that kind of impact and that's something- that's always existed for a long time.

K

So this this thing would make the um that next hop reachability that the next hop. You know where that when that that pec links goes down now, you're converged immediately, and I think that would be like a huge gain and it would be really for any service provider operator um that that you have um where you have that tie. But now now you actually converge that data plane quickly. When that, when that next top goes down, so I mean I would say overall, that's probably the biggest one I mean.

K

I think that the main the um the timers and I guess really converging the data plan and making sure that that when, when services come up, we just have to make sure that the uh that that entry- that's tied to the prefix, the component prefix, that it's actually it's gone and it would be a flood so so that igp would flood that lsa out at you know, and with with the uh with this new tlv, but it would age it out quickly like immediately.

K

It would be immediately flooded as soon as the service comes up boom, that black hole route is gone, the unreachable's gone as soon as the component. You know as soon as the component is down, you know as soon as it's down like the next stop goes away, then immediately the data plane converges as soon as that. Next out comes up, then immediately the um it's withdrawn.

K

Basically, the poa has to be withdrawn, so it would really have to be immediate, you know, and it it would you it can't be that that it's lingering and or any case of a false, positive or false negative happening. I mean that's really the critical one, because we don't want to make things worse. We want to make it better and improve conversions.

C

Okay, somehow we got more grace period than I thought.

K

Hey, are you still there? I don't know if you want to comment or anything on on the draft. I guess any any other comments. Did you make yeah and then we went over to we're at 202 a little bit ago.

C

K

C

I I think I think this this probably needs a lot more discussion on the list that there's you're sort of mid discussion on it. It feels like.

B

I'm interested.

C

I didn't do and.

B

And the different use cases have uh have different. This is ac again speaking of working. Remember uh they have different uh different behaviors.

N

B

And, and so mixing them mixing them is confusing as well and saying you just can do them all.

K

Right, no, it is, I mean, I think, there's some stuff. I think we have to really you know, clarify and just kind of you know clean up some of the verbiage in the draft, but I agree the mix there are. There is a mix of use cases with the areas at you know, convergence and all, but I think some of that will we have to work on um cleaning that up. You know in the.

C

Tony did you have something to say while we're still able to talk.

A

Yeah, I have a concern about scalability. um It seems to me like, if you had a significant failure, you could use this to inject a whole lot of stuff into your igp relatively suddenly.

A

That seems like an unintentional stress test.

K

Yes, so so tony, that's that's a good point, but I think that so that is something that we would control with a there there's a timer that we would have, and it's a variable that's really based on it, I think, would be it would be.

K

A user configurable like based on the number of um the number of component prefixes that are down versus the number that are up or what you know, how many negative components you have and how many, how many services are up and it would be it would be something configurable based on the prefix length that you, you know, use a configurable so depending on, and it would be really like.

K

Let's say if you have, I think like by default as long as you have one match and there's one component: that's up the summary always gets advertised, so you could keep it the same or you could change it and that's a variable that you could change depending on, depending on the use case that if you don't want it to change- and you want to like always advertise it summary, no matter what.

K

Even though you're just let's say you have a thousand component prefixes, but as long as one component is up, you always advertise it um and that's something that you could change. You could say well make it like 50. If you have 50 of your, your components are down. Really, you know you shouldn't be sending out the you know summary. Maybe at that point you know, send out your components because they're there there's a lot of downstream failures, but it would be something that would be user configurable.

K

Hope that answers the question.

K

Tony anyone have any other any other questions or comments, and uh we can pick it up. I guess on the mailing list.

C

There's been there's been comments before too about um we let it run over, but we shouldn't let it run over too far, because people may have other things scheduled.

C

So I think we should probably we should probably wrap up.

B

Yeah we're supposed to leave uh grace period between the next meeting, starting at uh at 2 30 eastern standard time.

K

Yeah, okay, sound! I guess now like I I'm just going directly to the pc, but I'm like talking like really close to the mic. Does it sound any better or is it still still low.

C

Yeah you sound fine um ac. I I think we should wrap up yeah. I think so too.

B

So we'll continue.

C

The discussion.

B

On the list, sorry to uh barack and uh cair.

C

But all right! Well, thanks! Everyone thanks.

O

C

Seems to go pretty well yeah.

B

Thank you yeah. This was. This was better than the last uh online meeting yeah. I agree. Yeah all right.

B