Internet Engineering Task Force 105, 24 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-GROW-20190724-1550

Description

GROW meeting session at IETF105
2019/07/24 1550

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

A

A

Thank you very much, Jared okay. If you're standing in the back and you're not supposed to be in the Gro meeting, you could go outside and help us out if you're standing in the back and you're supposed to be in the Gro meeting, perhaps you could sit down hello you in the back. Thank you.

A

Good, bye, Alvaro.

A

All right as I was saying, this is the Gro meeting in ITF 105. If you're not supposed to be in here, you could stay, it might be fun or you could go to your meeting you're supposed to be at if you're presenting. You should definitely either stand at the mic and speak into it like this or hold the mic.

A

Okay, now those presenting have a little clicker. It has a forward and a reverse. It also has a pointy at the screen thing: okay, there's a thing in front of you, so you don't to turn this way and stare at the screen. All of that out of the way we have a note.

A

Well, I'll, wait, while you read it: okay, there's a bunch of resources online, the Jabir's thing all the meeting materials that are gonna be presented are already posted online, so you grab those and look at them at your own leisure there's, a jabber room where natalie is hopefully scribing for us, we'll need a note-taker, Warren Kumari.

A

Okay restrictions. Anybody else.

A

Jarrod's gonna do some notes for us good. Now we move on okay, you see you found your paring all right. There's blue sheets they're going around, please be sure to sign them, so we can get a room this size or larger. Next time we have a minute sticker, jabber scribe we're gonna. Do some agenda bashing really just gonna show you the agenda stuff about existing drafts. We have some things. This is I, think all up to date. Actually even we hope. Okay, a couple things in ini, ESG, reviewer, headed that direction.

A

There's a question about whether we should adopt something or not I think that might not actually have been sent out. Yet, if you have a draft and you're wondering gosh, is somebody gonna do something about this and my draft? It's so cool! You should let the chairs know or ask on list for what you think is the next step either, if it's not adopted, ask for it to be adopted. If it's currently got a bunch of comments and you've dealt with all those, you know you're ready to push it forward.

A

Please let us know to send it, for your last call, asking often is probably fine.

A

Job you wanna say something about the IDR recharter. Yes,.

B

Our brethren ATS, the IDR working group, are looking for inputs in context of a new charter, so if we as operational community, have feedback as to what about the bgp protocol should look like on the wire and in its behaviors, now it's a great time to review those email threats and provides your inputs to IDR. So please take that under advisement I, don't know when the chartering process will stop. But I expect that if you give feedback in the next one or two weeks, it can be taken into consideration.

C

Jon's, better idea or co-chair yes, thank you, and we will be talking about this in our Friday meeting, so welcome to show up that and putting your two cents yes in the next few weeks would be a really good time to provide input and, just to briefly reiterate what Alvaro said at our meeting that disk included, you know we're we're.

C

Our desire is to keep the sort of overall Charter statement relatively broad and to track nitty gritty details in the milestones, so we're very glad to take in nitty gritty details but they're likely to end up in the milestones portion and not in the Charter proper Thanks. Thank.

B

You John, then a small updates on then a question from the jabber chat room.

D

Yeah question from Illya to Bynum.

D

Where is the guidance on which idea related topics go where.

B

The idea of topics go to the IDR working group.

C

Jones cutter again, that is exactly what the IDR chairs were talking with. The ad is about this morning and I think it will be relevant to the IDR charter discussion. So yes, there. We hope to have more guidance of that nature. That appears in the IDR Charter and possibly in the charters of related working groups.

B

Thank you, a small update on evolving documents or living documents at the last ITF. We spoke briefly about the concept of a faster publication mechanism to bring operational guidance faster to the various stakeholders and users of the BGP protocol.

B

The isg currently is reviewing this concept and coming up with proposals to more tonight in the ITF plenary, there will be an update from Warren Kumari on this topic and tomorrow morning, at half past eight.

B

B

You showed me slides, I'll, step notes for tonight.

E

Morrow I'm, not opening that kind of wounds there.

C

E

There's not gonna be an update tonight or.

C

If there is it, the.

E

First I've heard about it. There.

B

Will not be an update tonight, but tomorrow morning, at half past eight in this very room do liffe. There is a gathering to discuss the concept of documents that are not RFC's and I. Think that would be interesting to the operational community to have such a tool. So, if you're agreeing with that, please come to the site meeting tomorrow morning and provide your feedback on these ideas.

B

No Mike, my apologies, so tomorrow morning, half past 8:00, this room will talk about living documents were evolving documents or whatever it's called tomorrow morning,.

B

All right, we can start with the presentations. I would like to invite Alex to talk about leak, detection and mitigation.

F

Hello, everyone, my name again, is Alexander azimuth, I work for Yandex and now without harsh I would like to discuss with you around leak mitigation solutions for those who was not at the idea. I will just recap for the most crucial points.

F

So previously we had two types of signals for roughly prevention and another signal for route leak. Detection. The first rule says: if route is received from provider, route server or peer, it must not be sent to another provider appearing. So the only direction that is applicable is customer, so you may send your prefixes only to customers, the second rule. If route is sent to customer peer or route server client, it also must follow all the down rule.

F

In other words again, it must this may be sent only to customers, so the rules are fully contact, become compatible varnas working on egress, the other one is working on egress. So.

F

Yeah I understand so yeah yeah. He is noise from outside. Yeah I want this good. Ok, ok, I'll! Try to do this way, so we decided to make it's a joint signal and modern. We will have two signals. There was a argument about which one which, which is one is better attribute or community attribute, has a lot of advantages. It's more reliable! It's memory efficient! It has a reserve to use, but the community can be deployed tomorrow or a day after tomorrow. So we will. We would like to have advantages of both approaches.

F

We will have community tomorrow and in the attribute the day after tomorrow. Maybe later so here is the specification for community. It's nearly models, OTC behavior, that I present it. If the idea on working group, so we suggest to reserve this class for well-known transit communities, so these communities should not be stripped on ingress, so the first one is just sub class for do community and the video is carrot. Is the autumn system number how this weather is set like in how to see on egress?

F

If you are sending it from provider peer or internet exchange or router? You are setting it with value of your other known system number on receiver. If you are, if you are customer or beer, you are also setting it with this number. So it's doesn't matter. If it's a set organ, egress or ingress, the Whaley will be just the same. It works nearly the same like OTC. So as we discussed for in this example, we have provided on left side is, is taking transit from its provider.

F

It's also has a pier on the right hand, side. The signal now in this particular example community is set, may be set on. Ingress may be set on egress it doesn't matter. The value will be the same. So when it goes through the network to prevent network from leaking, it does not need to match the class of the community. There only difference from yo TC having not either or ot, see happening on egress at the level of ice 3. Imagine that ice 2 is not filtering, and so it's a liquor.

F

Unfortunately, we are not able, with community image in a single community means image, create a rule that says image for class and doesn't match for video, so this rule must be transformed into 2. Majors first check that is, is not setting the community second check the class. So it is based on the assumption that if ice 2 is adding marking its also makes filtering it's very important and we'll get back to this few, so the most important question what we should do if we detect a root leak.

F

So there are three common options: we should drop it. We should set a local proof to zero or just let it go so drop. It is clear. I will not describe well describe it in detail. Let's move to the second option: a local prep, zero.

F

The previous versions of the draft suggest these kind of behavior, and the idea was that maybe there is a customer that has only single path from all originator to a t1 and if ralick happens in this part and immediate upper provider accepts it and then next level provider the texas and drop it. We may end up that roughtly results in connectivity loss for the victim and for this case with the thought that local preference zero can solve the problem for the in these unreliable topology. But it's his very important side effects.

F

So first go into side effects. Just see the number of.

F

Actions this must happen at the same time to make network unreachable. So it's not very likely situation. So, let's go to the side effects. First, one happens because of when root Lee is propagating through the upstream providers. They are still able to detect it, but when such prefix goes down, the network lose lose this opportunity to say if it was erratic or not so it may become more preferable. We are getting in situation with priority loops, BGP wages and in some specific to a topologist, even stable, BP oscillations with Buju pillows. So it's not tasting.

F

This situation can be fixed with additional signal, but even with additional signal that says, for example, we detected a root leak. We cannot guarantee for these customer with unreliable topology. That prefix will become reachable because it will depend on the on the policy of other parties. You are saying there I'm propagating a root leak. Many providers will just drop it. Ok, but it's not the full problem. The biggest problem is prefixes that has a specified policy that restricts its propagation. It might be done in different ways.

F

It may be because I'm using some control community to limit the ways prefixes is propagated by my upstream problem by mega upstream provider. Thank you. Then it may be most specific prefix that is sent only through internet exchange point. So there are many kinds of such policy when prefix becomes partially visible and from receiver side.

F

We are not capable to just in to say if the leaked prefix that is received from your customer is poo proper cause a poo in direct customer with unreliable topology of if it's a CDN that had such such policy, its advertising more specific and you are going to ruin its connectivity plus ruin your own connectivity to the CDN. So this is just a highlight. I made this calculation yesterday and it shows the number of prefixes and its visibility. It's based on right, breeze data source, all small producers. This has length more than 24 I ignored.

F

So you see, the number of effective prefixes is really high.

F

The only safe way to mitigate root leaks is to drop them all other ways like local preference, zero or anything else will result that you will create a hole in a security solution and one day we will shoot your own leg with it.

F

The only exception may happen when, at the time of early adoption, one may want to see the signal before making a decision that we are ready to implement, implement drop policy. It can be done, but with caution as we discussed previously, we, if we see marking from a neighbor, I oughta, know sister number. We have an assumption that it's have drop policy. Otherwise we are losing the signal. So, if you are going to to do only marking, you should go a full of these limitations.

F

They will be described described in the next version of the drop. So here is the result. The only opportunity to mitigate root leaks is to drop them. You must you should follow this rule. There are. The only option is just to pass it by, but you're accepting root leaks. You may say into your egress traffic to a black hole.

F

What are the next steps? We really need your feedback. We find the good consensus among the authors in the version that is in mailing list with the miners. Changes will be uploaded into the tracker. I hope that I will be able to do it, and during this week we also will require ion allocations for class.

F

This will say that we have well known trans communities, plus a sub class for leak, detection prevention and so on, and we really need to go forward to have a fast working group last call, because if we will eat for years there will be no reason for this solution, because I will have a more reliable OTC or a spay in place. So thank you for listening.

B

Speaking as I don't know what's, but I would obsess.

G

B

To not refer to values that have not been assigned but put in TBD to be determined: okay, okay,.

F

But if I'm thinking but I just like this number, a.

B

Lot of people like that number, that's yeah.

F

Yeah yeah yeah, yeah I, understand.

H

It was made. One of my two points. Second point is that large communities were for various reasons designed to not have resort values. So one of the things you need to be aware of is that, regardless of what working group, this happens and you're about to make a operational change and having I Anna carve out a piece and know sort of like the well-known stuff, for you know: 1997 ones you what thunders eventually have magic behaviors for those think about this stuff.

H

Why a little bit more widely and coordinating with IDR about what happens with large communities where they would actually carve out a range of values similar what's the 9090, so it.

F

Okay and Jeff, thanks for your comment.

F

Before asking, you ask you the next question, just so from the point of process, so where should we differ? Request the class to be resolved from the Ayana in these draft, or it should be another work, because we need a subclass. Of course,.

B

In a different draft, which, coincidentally, is on the to-do list of the chairs of this working group, we can instantiate a registry and that draft will allow us to discuss the concept of a registry and see if IDR and andro agree that there should be a registry and once that registry exists, then your draft can just request a value from that registry. So.

F

May ask the chairs of the working group to move forward with this work. Come.

B

On Chris, yes, good, thank you for your feedback.

I

Can you back up me I? Think it's one slide back I think what we agreed was that the wording is that the default mitigation policy should be must reject and that you should follow the default. Otherwise, I don't know what it means to say. The only acceptable policy is you.

F

See it's very important voting the only acceptable mitigation policy, the only acceptable mitigation policy- it's not it's not.

I

F

Yes, yes, oh you, when you're doing only marking, we are not doing mitigation.

I

Its word brain surgery or something okay. We.

F

Can, let's try to be a little.

I

Bit more clear about it: okay,.

F

J

Then medicine work online, yeah I found that confusing, but I was just about able to pass it. My understanding reading. That is, that the only thing that is mitigation is rejecting and you may or may not choose to mitigate. Yes, that's correct I prefer that construction to having a recommended default I, don't think anything other than dropping leaks is mitigation and dressing. Something else up, because mitigation is counterproductive and I think we saw that in origin validation for years.

F

Okay, then, thank you for the comment, because I fully in line with you.

F

Any anak patience Commons seems to prove that we are happy good.

E

Thank you for your time.

B

B

Think you're next.

J

K

Nope, that's the next one.

G

K

That's not mine. This is doing yes all right. There's no box here.

K

Fantastic, so I am Paulo and finally, I have only one slide for two drafts, so I hope we are on the right path. So I would like, first of all, to present around la crib and utter about more MORE, yes, perfect and so.

K

So this is the only slide that I have on these two drafts right we presented in 2017. There is a lot of backup slides in this presentation on the motivation why we are doing this and things like that that key takeaways, that we are adding important advantage points over the existing RFC of BMP. So in the existing RFC we have a tree being pre and post policies. We are adding block creep and other about pre and post policies.

K

We, since the last IDF only minor changes right are about is seeing IE, SG review and feedback was processed and things like that I think things are going well and the forelock crib, which is the one that is a slightly more active. We did process the feedback of Jeff has thanks for very much for the feedback here, the plenty of feedback. Now, if you grab through the document, there is no feeb wording anymore. That is maybe one of the most important thing, plus many other things, and while I was processing, his feedback I captured.

K

Something else that we have TLV about vrf and table name and table name is, for example, if you have a slice, a partition, specific view that you are passing of the lock rib and vrf, it's vrf right, and so it's possible that you want to have this TLV repeated multiple times I catched it while I was processing his feedback, so some tax was added to it, and that is pretty much it right now. If you remember last time at ITF 104, there was quite some queue of people.

K

You know asking question around, you know what goes in block rape, active routes, all routes installed routes, and things like that right and it is true, this draft is maybe a little bit under it under determines a little bit. What goes in lockrey, but any question that you would still have around that I ask you if you can hold your tongue for the next next presentation, where there will be Camilo here, because it may be the most proper.

K

You know presentation to document where to ask this about BMP path marking, so any questions and anything can I go to the next presentation. You.

B

May sure can.

K

I get the next presentation. Let's.

B

Hope we can find it.

F

No! No! No! Yes,.

K

So the second presentation I wanted to the second sorry draft I wanted to speak. What is a draft about a tlvs, the original title and it's something that I am doing myself with young young and Hank and his remote a Hank? We love you so much.

K

So the original title of the presentation was the title of the draft, but the other day I was given a lesson about how in the intent-based tinks era, we should the focus also yeah IETF documents on interns, so the real title is future proofing BMP. Thank you Jeff again for the suggestion.

K

So a little bit of background or history behind this draft is that, if you remember like one year ago Hank he presented you, he wrote a document about how to make BMP more extensible. I myself was a supporter of that draft and also we met in person with Hank, and this is Interop meeting between me and Hank in which he was exporting from a Nokia device. You know, BMP content with the following.

K

The draft and I was collecting it with pms ECT and we were super duper happy because everything worked, but then what we did is a little bit of an exercise about you know about. You know rereading the draft and things like that, because it was quite extensive draft right, and so we could do this exercise and dissect it in three main areas that the draft was touching upon, and so one was very easy.

K

It was getting into use cases and we should you know it's not the greatest idea to compound use cases with other stuff, and so it was good to leave the use cases alone. And then it was touching a on to other areas, very important one, the tlvs introducing tlvs in BMP, not introducing but making sure that all the messages have tlvs and review message types right, and so we are here right so in the tlvs.

K

So this draft essentially wants to but be a little bit a child of that draft that only addresses the tlvs and why we wanted to split alt elvis from the method from a review of the message types. So, where you see, we have an idea to have draft in future about that.

K

It's because you know it's two different beasts right, so the till these are, if you pass me the term more important for a business perspective right so to make more critical mass around the protocol BMP, because with that you can pass more information more metadata, as in vendor specific data, and things like that, so in a enables enables further applications around the BMP and on one hand you can also say so, it's very important and in a way I tell these are very it's a very simple concept right.

K

So having till this appended to BMP messages, we will see that there are some parallels also there, but we can say it's easy. The reviewing the message types is more beautiful engineering effort, which is a slightly more account.

K

You know complex because we can have all different ideas on how we want to beautify the protocol and things like that, but we can kind of say that it's a you know an engineering effort more than something with the business critical sense right, and so that's why I think they really belong to two different drafts, and so we want to you know separate in the two things that said: what is the problem statement? The problem statement is simply: it's like. We have a table with four legs, but not the all.

K

The four legs are the same right and then so not all BMP messages do support tlvs right. So, very importantly, the route monitoring messages may be the most critical one doesn't support the till this and also peer. You know the peer down message doesn't support the TLP.

K

So what is the ideas in the draft is to add TLV, not odd. Allow simply allow for trailing TLV data in the BMP messages and in order to do that and I leave it as at the last point here, like a bump, the version of BMP to for essentially I want to leave it as last, because you know I want really to stress that that is not really the key part right. So we are not in a critical point.

K

You know we are not twins, inventing a whole new protocol or or anything like that, it's really just backward for backward compatibility. So that said, I have. There is one open question in the first release of the draft, it was on purpose left under specified how to handle the p.r down right. So it's just written that also the pillar. The period down should I have TLV data, but the truth is that you have three code points that allow for trailing data, and this data is not necessarily in a TLV format.

K

There are other code points that you know it's not specified. You know that they can add a trailing data and things like that. So again, even there you have not an even surface and you know solutions for that could be anything right. So from the most extreme, like we have a new message type to we duplicate the code points to we say we have in bmp4, and so now the in data should be in TLB format to anything right. So there are multiple solution to this problem.

K

I would maybe prefer something that is a low-impact from you know, implementation perspective, but feedback is appreciated, so anybody has ideas or preferences or whatever. Please let me or a small working group adoption. Is there any interest? Yes, oh thank you.

G

Please send message to list asking for adoption, sure I would and I.

K

Hope we have an exit zero. That's it.

B

Thank you for your time. Yeah.

K

Questions no question, no comments.

B

We shall move it to the mailing list. Fantastic I want that way. Back.

L

Hey, so hello, so I'm Camilla from entity, so I would like to present this draft on BMP pod pod marking.

L

So the goal of this wrap is basically to to mark the paths in B and P with our state on the on the local rip. mmm We will have this information. Maybe we can allow some different applications. You know. So that means basically that if you can get the pad mark as if it's installing the rip, if it's a backup path, if it's hopefully unresolved, maybe and stuff like that, we are open for suggestions on what else to mark either the TLB mechanism that Paulo Lucinda just presented. So there's some faith share in there.

L

This is actually a rehash of a very old draft, so like around 8 years ago or 7 whatever or six. We had idea of of using that path and communities to actually mark. So you see that path to get all the path from from a router and then using communities to mark what type of path they were if they were passed for base external or stuff like that.

L

However, even though technically there was not much of an issue like the philosophically is not such a good idea at least and the mind of many to monitor, bgp with bgp but used BMP, which back then was not very much sure now it seems to be so. Why not to put it there, so it still be basically right now we have so. This is the basic idea. The rest is our I mean we have the first iteration over these. Maybe we can.

L

We will probably improve it in the future if it's interesting or not, for the group. So right now we have the pad type and a recent string, because why not so the type is actually a bit field, so you can have more than one type for a specific path. I mean here are some initial ideas of this, so you can, you can mark like the path. Is the path is best path or primary, which basically means that if you have multi path, then you can have multiple paths.

L

On the on the on the install for forwarding. We took that terminology from the peak draft.

L

You can mark whether a pack a path is a backup, so, for instance, if you don't want to run very complex, BGP simulator- and you have this information, then you can use you can use that for for that application, then you can also have, for instance, unreachable next hop. So you can say there are path, is invalid last week, actually I'll prove retinas and on the ITR that we really were not sure what unreachable next segment, but whatever so there's a syllabus external path there, which, after six years, is a still a draft.

L

Even though people use it I, don't really have an application for that, at least for optimization. But maybe, if you have this information, you can you can verify your network or I mean the more information, the better I think at some point, there's also a recent string, because why not so the idea here is that if you can, if the platform actually allows you to tell why a path is in a particular state, for instance, why wasn't the best or wise not install, or why is unreachable? Maybe the next hope is a multipath.

L

Is a multicast address, or maybe you had a cap in the number of backup pad, so maybe you can and write that in the original string this tends to be controversial. I think this type of reasoning, strings but parameterize indeed, but I'm addressing this information might be very complicated and it could be useful for debugging for the government blogging purposes. So again, this is the structure we have now we're open for suggestions or, and that's it for that side.

L

So I do have an open question, which is what paolo mentioned before, which is what relationship does we'll discuss, for instance with with the local rip and the other rip drop, so I believe this is this basically come from the local rip, but to actually have a rich received, rich information, then we also need the UM invalid pads and I don't know if they actually, the low-calorie trap allows for that or not. You know if it's explicit or implicit.

L

So that's my open question and that's it for me. So we can go to Gareth.

M

Shared much Akamai, can you go back a couple slides, slides to the reason. Codes are back another one I think that yeah this this one so I'm just curious where this registry would live because it. This seems like it's more of like a protocol level message here and I'm wondering if that, if, if this would live in grow or an idea or somewhere else,.

B

Registries live with IANA.

H

Jared's point is that it's a protocol, generic-type behavior, you know you're. These things can be covered by multiple things elsewhere in BGP, so rather than to find them, you know once for this application should they be used for other things? Probably not, but no question I. Think.

B

You for the clarification, jeff.

H

Has so camilo night that this conversation of this part conversation already before, so this is partially for the room. I like the idea in general. This is overlapping. You know some other questions. You know we, the person that was just stuff of the mike head about, do we have sway, it may be tracing. Did this grout actually made it through the install process? No intelligible for out selection? That sort of thing rudiger has had similar comments before as well.

H

The the problem with a lot of the things in this set of states is many BGP pipelines and implementations are not fully synchronous. You know, use I can get her out and it may go through several stages before you actually get some of these things potentially set like reach. Ability of next hop may come very late and we get around install process. Whether things eligible for multipath is another example. So, and whether or not something's elected from best path, so people have drown.

H

Selection happened very far down their pipeline and the problem with this is the original BMP rip in at least it's a very dumb feature. You can just stream this stuff out almost immediately, if you want to, if your implementation once allow it or come very late, trying to actually tie these things in is try and actually lock the implementation down to don't send anything out that tells this stuff is determined and I think you might find that actually has bad impacts and some of the use cases ribbons used for today. So.

L

I'm, graduation, deaf and the local rip for is an implementation is not, if not also affected by that.

H

Actually far worse,.

H

If you want to pick like ribbon cases that are good, so best path, you're, not going to know that by that point, knowing that it's you know, installable a lot of people's policy Ange will get to that very quickly. That's something! That's easy to pass back of the DMV message.

H

Reach ability may vary, and some of these things like these so flags if you're, actually getting these as part of your local rib feed, look rib is only giving you the active road because giving all the state as it changes through the set of routes they're getting altered as part of route selection changes resolution state policy, whatever your than, if it's just nothing, but there's endless churn of these bits. If you actually exposed them that way, so I guess my two pieces of advice are: some of these.

H

Things may have negative impact on the implementation if you really care about them, and the second thing is in a low crib context, you'll end up with a agency. If churn that really doesn't give you potentially allow useful information, but if you dance back to the string slide. The second piece of feedback here is that this stuff is interesting.

H

It overlaps the work that you nuns doing for 10 cents and I think there's some value out of having that conversation continue in relation to that, but the related piece of feedback that sort of goes into should be put the state into EMP. We talked about this night. A photo for BMP is a difficult place to put this stuff in because it can be you're sort of jamming up the pipeline with more and more information, EMPs already pushing the fire hose of information down and drinking straw.

H

So the problem we have here is that strings are useful. They don't compress terribly nicely the protocol and this sort of just fattens up the p views with information. If you send this with every single thing might be interesting, but you probably want as a telemetry feed for interesting things rather than as a contiguous tree.

J

And Renison will come on again. I suspect, Jeff is gonna, have an opinion on this as well.

J

So at least one implementation of AD pass that we run. Has this concept of marking prefect marking routes as members of a set of of eligible prefixes that can be advertised to an ad pause capable peer, and those are.

J

This fits in quite well with your your kind of your your your your set semantics for the for the types, because those are you know those can be entirely disjoint or they can be entirely overlapping and I can see a use case for us where, in order to evaluate whether or not we want to be sending some larger or smaller, set of prefixes to a given neighbor, we want to be able to get an indication of what the additional memory consumption is, and this potentially gives us that very easily.

J

If we're able to stick those set memberships in those in that in that code set, but as I first effect, Jeff is not going to love that.

F

F

Him a few minutes so I can say that I was following all the draft. So it's my fault, but thank you equation. So we have a growing number of security solutions. We have router region validation, we may have ASPA and other stuff. This affect BGP decision thrones'.

F

Am I right that, with these recent stream, I will be able to say that the prefix was not accepted because of applicability or because of route leak was detected? I.

L

Don't see why not I mean that's, why we left there open, as but as long as information Jeff was saying it might be complicated, but that was one of the.

L

That is all parts and ribbon information of the log grip. So after the decision process is made if that decision was made after the decision process, I don't see why not, obviously, on my paper me doing the paper. I don't do the code, so I obviously think that is hard for two, but I don't see why not, for instance, we get something that's very important. We can also add a type for it, but obviously, with this is travel of implementation versus what we need.

L

So what we, as customers of devices of road monitoring, need versus how hard it is just a.

G

Quick point: there's 12 minutes left and two presentations from Iran still to go so quick, quick, quick! Thank you, quick, okay,.

A

You can always talk about this unless, of course,.

L

Thank you very much.

A

Which one do you want to do? First, this one.

G

N

Thanks for saving me several minutes, and uh can you hear me clearly? Yes, okay, so um I'll do a very quick update on this draft, and so this one was previously presented once on ITF 103, that we use PMP to carry the ruling detection information and where well, nothing. Much has changed in sense since then, but I would like to bring up a major information here.

N

Is that I want to clarify the position of this draft because there have been several works, that alex has been working on to do a blue lake, either prevention, detection or mitigation. So our drafts, our draft- stands here for for relief, detection and well.

N

The difference between my draft and other works is that the detection of root Lake happens a actually at the local airs. As far as I understand and after I have also discussed with Alex. There has no no message that can be used to detect the existence of rulings that is happening at the local s. Okay, so are typically a Lakes can be detected in the upstream or downstream areas, but not in the local s. Okay, so that's where this draft stand.

N

Okay and a very simple example: sorry very simple idea for this dropped that we want to use a IOT t RV to carry the business relationship to to state. What's the current relations and then and then at the EMP server side, it can combine the our DT of ease from the ingress and egress notes and then compiling to analyze these two relationships to detect if any rolek has actually happened within the ass. So very simple idea: any questions on this draft.

N

Now, let's move forward to the next row.

N

N

Instruct in this draft we use PMP to record and trace the BGP route policy processing and thanks for the working groups, comments and inputs since the site EF, and we have actually made a lot of changes to the previous version and but today will I will first show you the current position of this draft and, more importantly, I, would like to get more input from the working group.

N

How this draft should go because after I have been talking to some of some of you like Jeff and I'm booty girl, there still exists some gaps where, with whispers back to certain perspectives, so yeah I would like to see how how help the working group suggests the draft to go and a quick recap of the idea. So this drafts this draft. This draft wait does. Is that a it recalls, the processing of a group policy? And this is an example that shows you what is exactly recorded using this proposal?

N

So here we have the prefix.

N

10.1.1.1 24, it is received from a BGP peer.

N

192.168.1.1 and then it goes through the inbound group policy, which is called Rapala CCAP and with the node ID or item ID 100 at time, t1 and an action was applied which is adding a community to the prefix. Ok. So what can we do with such data?

N

Here? We list several use cases. First, it can be used to do route policy validation, for example, you configured a new policy to do maybe maybe rule ich prevention, so you add new filtering conditions and then you can use this function to record if the prefixes that you care about are actually correct or correctly a future or not. Ok, and also it can be used to do root, cause analysis. So the root cause analysis is not used right after the policies policy is configured.

N

It is actually used after a certain period of time when the policy was configured because some of the issues are only triggered when certain environment conditions change so that you don't know when the what what policy is actually responsible for the current issue. So you need to have such record within the device and then to locate the actual real cost. Okay and third example is the route propagation trace, and there is one example in the draft that tells you how you can do that with the data recorded okay.

N

So here I listed the three major changes from the first version. The first one is that we designed a new message structure, which consists of two parts which first one is, is the basic information part which is fixed lens, and it tells you the the basic background information about the event and then the second part is flexible. It can be customized according to user requirements, either its bandwidth consideration or your visualization requirements.

N

Okay, and the second change we made is that we designed a new structure to represent the route policy, basically to allow the policy, training and policy recursion, and the surfacing is that we add a optional TLV to to allow users to freely express whatever I think, whatever they want. Okay, so here's the message that the message body looks like I consists of the prefix information and then the event information.

N

So one thing I would like to mention specifically here is that how we define and event because previously there have been discussions on how how we can use this functionality? Some people has mentioned that it can be used to do programming, execution, tracing or say debugging, but I thought about it and and and and I would say, this draft is not positioned should not be positioned in that place. I would say this draft. Does the tracing at the policy group policy level?

N

Okay, so that's two things from the actual programming execution, so here the event will be defined as one group policy execution, whether it's mapped or a matched or or not matched okay. So whenever a policy is executed, there's one event generated, and this is what each single event looks like a consists of major a four parts. The first part is environment. It tells you the time stamp in event index and other basic informations, and then we have the second part, which is the event results.

N

It tells you the of the BGP attributes right before and after the policy execution. So this party is optional. You can have both preamp and post policy attributes uploaded or you can have just one of them or you can have none of them. Okay and then the third part is the event course, which is a policy part, a policy part which tells you what is responsible for the results. Okay and according to Rudy Gers suggestion and now.

N

I also believe that we should exchange the course and the results the order of these two parts and I'll do it in the next and the last part is the event notes. This is the optional TOB I mentioned just now, and I'll show you in the later slides how we can use that okay. So these three, the the the the event results course and those parts are or optional so the attribute she always looked like that.

N

So if you have both pre and post policy attributes carried in one message and then you can have a direct one by one attribute comparison for before and after policy. The reason that I add the true policy attribute here is that, because sometimes we miss the recording of certain events, so there are not necessarily direct relationship between the two events that are reported. So with the pre policy attributes, you can have a a very direct and straightforward with a visualization of the results before and after the palace execution.

N

Okay, so- and this is a new policy- a struct structure that we have defined previously- we only allow one policy expressed, but now we add the recursion and chaining consideration here. So basically, what we do is that we use a C bit and Arbit to indicate the relation. The relations of the next policy to the previous one, so you can stack like I would say unlimited, but it it doesn't necessarily have to be like that.

N

You can stack our policies one after another, with relationship indicated with the C and our bit, and there's also one a policy match flag, which is called the M bit to tell you, if part, if a policy is actually matched or okay. And finally, we have the policy optional TLV here, I'm thinking is that it can be a string type trv that can be used to freely express whatever the user wants.

N

For example, the user may dumped him. They don't want the attribute TLV or don't want the policy ID TLV that we defined. He only wants, maybe a conclusion from the device. Of course this is. This conclusion is also generated properly from the execution results, but he only wants such conclusion, so he can use the optional govt to use to express that so yeah, that's one possible usage of the option. Hiv and well.

N

That's that, and so I would like to have some feedbacks and comments from the working group, because previously we mainly have gaps regarding how what what protocol should be used to carry such information and and also some other suggestions. So if.

B

Thank you very much in the interest of time, I would suggest that feedback is provided through the mailing list, because we've reached the end of our session, we're actually over running by two minutes, we're missing cookies. Thank you very much for your two presentations. I will see you all in Singapore at ITF. 106 see you next time. Thank you.