Internet Engineering Task Force 97, 13 Nov 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF97-OPSAREAINTRODUCTION-20161113-1345

Description

OPSAREAINTRODUCTION meeting session at IETF97
2016/11/13 1345

A

Alright good afternoon, so during the next hour we're going to present on the app's area, I'm burn wat Claire's, and this is my friend qu le a Glee will do the best to and return you so he's asked question. Try to make it interactive.

A

I thought would be better if we present from here, we can have a look at the pc slightly to read the slides instead of reading the screen. So the thing with ops is that it's divided into two logical parts. On one side we have like how do we operate networks right with a best practice was network local deployment guidelines. So this is what your paraders are involved. This is Joelle spot.

A

My part and I will be starting with the first half an hour is on magic networks, typically protocols and data model. So you know we've been doing MIPS MIT modules SNMP for some time. We still do a couple of write about a serene on writable, read-only, MIT modules. Today, just a few years.

A

So today we we focus on on the yang modules or young models for configuration. Was that compadres come we've been doing strictly like flows, flow management with IP fix a working group which is closed now we're doing triple-a as well. Radius and diameter Triple S stands for identification, authorization and accounting, so we're doing fault from Earth gaps, fault configuration, accounting performance, even if I ppm is a transport working group and also security from the operational point of view.

A

So we heard that from the community that we are friendlier than we look so and we're quite.

B

Good idea, which.

A

Is good here so typically, if you approach us we're kind of friendly so done, is it a quiz questions.

A

Now so I mentioned apps, the apps area is operations and management. So typically, what we have in the ITF is that you've got people defining specifications for technologies. Those people are not the one running networks, so it's important to get the operator feedback to say well. This is the way that we should deploy ipv6 or bgp. So in this case, for example, at the bottom, there is a nice there was a nice drawing its kind of word.

A

Now so don't forget it forget about the drawing, but basically, we've got working group, which is a working group called IDR for bgp protocol specification. We've got another one which is called secure. Id are then, whenever we take this into account and take the operator feedback coming from the NOC network operator groups, then it feeds into typically an apps working group grow, which is about routing global routing table, and then this is where would you find the best run practice and the guidelines?

A

And then we go back into the working group if we need to define something else right. This is the feedback loop yep now we'll be spending, maybe 1 slide per working group describing what we do in there. What the hot topics are in one hour, it's not like a tutorial on ok, what is an MP? What is not come for this restaurant etc, but we were trying to give you pointers on what to pay attention to in working groups specifically if you want to participate.

A

So these are the working groups for from joelle, so typically is implicated: benchmarking, DNS operations by routing operations, multicast operational security we mentioned like cider operation for for pgp operation and ipv6 v6 ops, as we call it is quite an important working group here. It has been for years. It will be four years. I guess now, on my side of the house on the protocols and data models, I got a couple of working groups and we're going to review them. There is netcom for that company turing net, not for netconf data model.

A

Language, add three sm. Just close. This is a service young model, I'm going to come back to that and we open an l2 sm4 l2vpn service model. I've got lime that deals with OEM management and supa to define policies. So I was quick, don't worry, I'll come back was one slide for a working group. What I want to show at the bottom here this? My key message is that we have four different working groups that are in the ops area. But if you look there they're not managed by any of us right.

A

Typically, they would be. We can move in. My part of the house endure the management, so we've got the triple-a ones with diameter and with radius, which is radius extension radix. We've got one on autonomic networking, anima and one on el map large-scale measurements of broadband performance. So why do we have ups working group not managed by the ops, a director? It's not because we're just lazy and we gave working group away. We are lazy, but that's a different story.

A

So here is what happened two years ago already, the iesg, the internet, internet Engineering, steering group realized that we would have a lot of young models in the ITF sao yang models. If you know about its end up in the past in the past had like mid modules with SNMP.

A

Now we have yang models with that count for us come for configuration now, since we realize we would be, we would see a tsunami of young models coming, and this confirmed by the way, then we ask for help and, as a consequence, I was asked to refocus my time in the iesg, mainly on young models, with more than 240 young models now across all working group in the ITF. That's a lot, so what I've been doing for the last two years is only focusing on on yang and related protocols.

A

You'll see the couple of working like I can take I take care of now. It means that I've been having a couple of working groups that we gave away to non operational area directors, so the one I mentioned Triple A, l map and edema, and what I want to mention. The bottom also is this edgy statement that we should stop doing writable mid modules at some point in time.

A

The past there was like thinking that every single working group should have a way to configure is technologies with mid modules in practice, writable MIT modules are not implemented. There are difficult to implement. It costs a lot and the new way to do that is with netcom for a scarf and yang.

A

Now, if you don't believe me yet that we've got many young modules in the ITF, this is like the dependency graph of all the yang models. It's the font is small on purpose, because it's not for you to read every single yang mother's. If you want I, would be happy that you do that.

C

A

C

Trying to attract me sources here so, okay, please do.

A

And now, if you not convinced yet that we've got many young models in the industry, this is the graph. The issue we have right now is that all these models, the Camaro same time, they should be working together and we should slice them as soon as possible. This is justification. Why 180s to focus on yang not only for ops but for all the working groups, and we see many of those young modules coming from a routing in the ITF, but also from broadband forum, and we have ice Italy, open, config, opendaylight, sis repo at City.

A

A

ah This one I believe I have to check I believe these are also the vendor specific one, but now that I'm thinking about I believe it's, it still looked nice if I put all the vendor specific, which are hundreds and hundreds. So let me double check, because if I put the vendor specific to be just a black search, yeah.

B

That would be the fully completed Death Star, as opposed to this one, which is partially completed.

A

Now the thing is the vendor specific one are somehow in a different bucket, because I don't expect them to work completely with the smart ones right either you go with Stan out ways to configure models or with native ones, as we call them from vendors and those are generated from internal databases or or CLI, etc.

A

Now, I'm not sure how many of you have been to many ITF meetings, but maybe it's good to take a minute or two to review how to look at working groups which documents are covering and what the the topics are. So the first thing is you take that tracker and in this example, we're going to take a net count working group and use it in the URL and you've got another one for tools.

A

So typically, you would have something like this. This is a charter. So let me just stand up.

A

Alright, so you see the Charter tab over there. This is what it gives you. So, if you want to get any information from the chairs, you've got the two email address from the chairs at this level. The era director. The first thing you want to do maybe is subscribe to the mailing list. Over there I, like the dependency there, that shows you are all the different documents are dependent on each other. So if you want to be involved, that's maybe one thing you want to do.

A

There is also, depending there, the wiki or the issue tracker, which might be different for documents now and maybe start with just looking at the Charter and at the bottom, the Charter, with milestones with what the documents are.

A

Yes and typically, you would see like, on the left hand, side documents, then the last time it was updated if a document exists, if it's a working document, if it's, what is the status, is a variation the ad and the document Shepherd, which is most the time with share looking at a document to make sure it's complete before sending that to the IDF rascal yep. It's about it.

B

A

Alright, so any questions so far, it's all clear and you're going to contribute to ups and start writing documents tonight this afternoon.

B

Reviewing them is even better. That's.

A

Right actually, now let me go one slide for working group. The first one is not calm. That stands for the question, for you European pay attention. Thank you network configuration. So this is where we provide the protocols to manage to configure devices with netconf and restaurants, and we just finished the net. Conf are the restaurant for FC, which is in the RFC Turk you just waiting to get an RFC ID this, where we do the encoding, JSON, Oh, HTML, HTML, with that com or JSON or HTML with restaurant.

A

Now, what are we working on? Well event, notifications, the way to push the data pops up like telemetry, sending the data all the time. We've got four drafts on that. So, since you won't be writing apps document, you might want to review those right and provide feedback.

A

We're working on young models for managing net convent restaurant was TLS, ssh, client server, key store and we've got a way to do a call home so I'm trying to give you both points on what we're working on to try to get your interest and quickly see the overview of different working groups.

A

Now, in the net mod one, that's a net count: data modeling language, we've been defining yang 10 as a language itself and yang won that one and we we have in there a couple of young models. So the rule is like this. If there is a specific working group, that's a defining specific technology. Ideally we want to have the yang models in that working group.

A

Now we've got a couple of common common yang models like access list or syslog, or actually the rotting one that long history has been published as RFC and since, at that time no work group of them ops wanted to do yang models. That's where we start with a rotting young model.

A

The hot topics we've got to and I hope to get a lot of progress this week. The first one is kima mount.

A

That's a mechanism, a mechanism to combine yang modules into schema defined in other young modules. Well, the ID is in devices. I might have a VRS right routing instance. It mean that I should define all my young models with a slash vieira for the top, maybe not because I've also have devices that don't have a vrf. The ID would be, can I just take one part, I gang module and just mount it into a different structure so going to allow flexibility of integrating schema in different yang modules.

A

Now and by the way, we've got money young models depending on this specific point, the other one, is a revised conceptual model for young little stores. The idea here is that we have moderators. You would like to manage their device differently by telling. Let me push a configuration. This is my intended status. Internet configuration and I want to listen and regular basis if it's applied, so intended were supply as opposed to not come, for example, which is I, mean to send the config and wait until it's applied now receive the okay.

A

To do that, the idea is to have two different views of the same data internet and apply that's what they're doing in that design team I'm hoping to get a lot of progress on this one.

A

The lime, lime working group layer, independent OEM management in the multi-layer environment. Okay, let me repeat that the here independent OEM management in the multi-layer environment there. What we're doing is that we realize that we have many different oam mechanisms right and the goal is to have young again young models to have a consistent configuration of the different OEM mechanism, a different sorry, a consistent reporting of the data and consistent representation of the data. If we would have that would be perfect, regardless of the OEM mechanism.

A

I, have this super set of young models that we just configure what's happening below the status getting there I I hope that we won't be meeting at the next ITF in Chicago, because the work will be done so again, that's a good place to provide feedback on on the document and thats a good reminder Greg. That should be done small message, so the the super working group.

A

Now you know in management what we always like. We want to monitor things, but in terms of configuration there is always like policies. If I see this traffic I need to block it. If I see this traffic, I'm going to read limited, if I see this specific security feature, if I see this entry, it exact routing, pass, etc.

A

Now the ID behind super, simplified use of policy abstraction is to define the policy construct. The if-then statement, because most of the yang modules will have those policies, POS access, lists, routing so services, you name it now in the Charter there is like the metric for success will be one ever. Those policy construct defining this working group in yang models will be reused by different people right. This is the metric versus the metric for success.

A

Now I mentioned no intent, which should be a cavity there. Knowing no intent means that in this working group, we're not going to say, I want my network to behave like this, and the network just behaves magically.

A

It's not part of this charter, even if there was some interest to do so, I would prefer to fix first, if them scenario and maybe later on see if in 10 could be so diced. I want to speak about a concluded working group and we closed it. Working group just a couple of days ago, so it's a service yang model. You know what the service young model is.

A

All right, what is this well.

B

So you have you have a particular facility that you've described with this, this model from provisioning through operation and so on, and so this particular one is for layer, three VPN, but you could imagine serve with yang models for a firewall function or for l2vpn or for a network, overlay or underlay, or some kind of policy.

A

Enforcement mechanism very good unser, thank you for indirection, so actually the way I describe this is on top of what George said is we have two types of service of young models to one on the network elements I want to configure interface, vrf and access lists, etc. On specific devices, the service, one typically will be in a controller on a castrator saying: I want to have a service on top of different devices.

A

In this case of a 3d, I'm going to configure the customer edge, router provider, age rather age and consumer age, and then this service will have a great apology and then, by mean, with the orchestrator and controller, that nosy topology will go in different individual devices right now, a capella. Another characteristic is that those service models are done by operators, because this is basically an operator asking the question to his customer: do you want to have ipv4 and ipv6?

A

What which routing do you want to have within your siggy and your PE with type of key OS? Now I mean by this? It's not like I'm going to have in this service model. All the configuration knobs that the specific device could do. No just a question asked by the operator to wis customer now, l to sm is basically an three sm which is closed for an l2vpn this time.

A

So same thing, questianus.

D

3 will gather to the sem our metric unit. Swarms of is it to have their service model amia.

A

D

So this model, or we care how that is so.

A

The question who repeat this with recording is what is interaction with em EF, which has got also some service models?

A

Yes, it was discussed the MAF once you have an architecture with different building blocks there for a service for customer database for billing for all this and we're going to work with em EF on this, so we've been reviewing what they're doing we're also reviewing I'm believing that in the world of service model, it will be somehow difficult, okay, nervous that we're not going to have that many service model solid eyes very couple of them: I start to see new service model all the times.

A

Now the approach is different between the ITF and em EF in the ITF. We want to have a self-contained model and the MAF. Once you have the floor architecture.

B

So L to sm is brand new. It now.

A

The first meeting, yes and I will be quick. Yes,.

B

So you have a situation where you may have a multi-vendor environment, but you're also stepping up from from say the point of bare metal interface configuration to the abstraction ie. What I'm provisioning is an l2 VPN service, and um so we described that to a control, work. Menu controller goes off with the device or interface models and actually takes that abstraction and has to implement that mechanically, which means producing configuration essentially for these devices that are involved.

B

So you want to step away from the vendor specific notion of of how this thing actually gets configured to sort of higher level abstraction that describes the features of it that are that are required for provisioning.

A

Typically, you would be asking something like okay I want. You have a GF service, gold and I'm going to define specifically oh I, want you to QQ death of X, nothing to discuss that with your customer on the line right, you're going to say which one do you want? That's what about abstraction that you're speaks about it.

A

No, it's not in a structure itself. It's.

B

Just like different.

A

Positioning on top of a controller orchestrator for multiple devices, yes,.

D

So how it applies to mention as a cadet or deserve mapping of the divots. That is this war in the Africa scope, because there's go on chief. So would that be didn't scope for to SF or scope ye rather I.

A

Don't think so, but I don't I I, don't think that the l2 sm will go into it and with some well not going to the SLA. Maybe you want to go to the mic. If it's a long long comment.

D

Yeah one of the points of the MAF is that they specify the service. They don't specify how its implemented, for example, for ITF. That will be whether it's a VPN or its V POS to the wires. That might be part of the model, but it would not be a definitely part of the MAF model because for them it's a line or EV PL or.

B

Iii, it's pretty important for these industries to be able to describe the product that they're delivering in a relatively coherent fashion, so that we all agree that we're using the same thing and I think that's um that's! Where sort of these higher level on constructs come from yeah.

D

But it didn't desire.

B

D

I, wonder, is that I would again? Would you expect that L to sm will have define the mechanism with implements there to service whether it will say? Okay, we do EVP n and here's. You can go into their EVP and data model and it will address your concern or will say we use vpls and then you go into the POS data model and it provides you how to build their to service. So.

A

In a charter we said to the wire.

D

A

Don't you could be not of those things? It's.

D

Not EVP and then I need.

A

Opinions in there as well yeah.

B

I mean it could be. A lot of those things like pseudowire covers a whole bunch of technologies, either in the ITF or elsewhere.

D

So, would then that these models of this specific technology to instantiate the layer to service be exposed in l2 sm.

A

So we sent a charter on Frankie access said that I can that it should be based on the pseudowire and an ED p.m. if I'm not mistaken, but it's not like a configuration of those those two it's based on. Let's review the Charter text: okay,.

A

And if you recall, I've got four: there are four different working groups that are not that are in ops, but not much by ops, so I'll be quick on those I want to mention the of the rectory. That's a group of expert in ops. We could help you've got an ops issue, but also what they're doing is that they're reviewing all the working documents at IDF last call. So this is the upstair Directorate.

A

You can also send them directly request if you've got any any questions and you've got like some more Directorate for young doctors with doctors. If you get like a yang module or mid module at IDF last hole, they need to review this. This document from a young point of view, from SMI point of view, which is the language, but not specifically, if you're, managing your technology right, because it's difficult to be an expert in management, but also on the technologies technology themselves. Right.

A

So let's pretend that you want to manage x.25 good example then, maybe which one he can't be. The expert in yangon lips at the same time makes 25 and we've got two more like the idea, triple-a doctors and the performance metric director rates. Now, if you want the last thing I want to say, is: we've got the apps open hours every single time at the ITF. We are available for any questions. You have specific new work or anything that relates to the apps area.

A

This is tomorrow at 350, so we just ask you to to book an advance for us, because you've got my money request now. This is the end of my part. Any questions for me I would have to leave enough on my next meeting. Even if at you I can answer any questions. Oh I.

B

Can make stuff up, certainly good at that all right I. Thank you good. So then, why I talked over the management side of things? I have the ops in operations and management, so um ITF areas are typically organized around particular lines of work, um so routing internet transport applications.

B

Real-Time applications was a separate area for a while, and it's been folded back into into the general application in real time area and even management protocols on operations, however, is kind of a meta area in the sense that it actually touches a whole bunch of the other areas um and the general rubric of that is network operators used to be a somewhat more on general purpose entity.

B

If you worked at compu server, AOL or an entity like that, you had a tendency to have operations in sort of all of the areas and, as networks have become more application, specific, whereas they've fallen out into transport and services and eyeball networks, and so on.

B

Operations has tended to get a little bit more diffuse and divided up into into more specific groups on the operations area, and the ITF still touches all of them.

B

However, um so largely we're concerned with the operation of IETF protocols, um there are, there is overlap with other organizations, so we occasionally have liaisons, for example, with I Triple, E or 3gpp related to particular lines of work in the ITF, and particularly in relation to the operation of, say, the ipv6 protocol or cap web extensions to I Triple E 802 dot11, our places where we are outwardly facing so the ITF didn't start with an operations area.

B

It actually sort of evolved out of a need to have a place to do work for working groups where the actual protocol development was actually completed or largely completed and in in a maintenance mode. I'm sharing in coordination with operators is a necessary part of protocol utilization, so just because the IDF thinks they're done with something doesn't mean that it is actually particularly easy to operate or that we don't benefit benefit from sharing the insights of operators back with the developers of these protocols. So operations tries to fill that hole.

B

The big places that we do, that the sort of top line on divisions among the working groups tend to be routing coordination, security, coordination measurement arm and so on, but we also catch a few other things.

B

Operations working groups typically do not do protocol development, so there are exceptions to that. But in general we do not do maintenance on existing protocols with exceptions. Four elements in the DNS that are largely operationally focused like new resource record types um coordination with protocols.

B

Developers is a lot simpler in areas where there are active working groups, doing work so inter domain routing, for example, has a as a in the in the routing area has an excellent dovetail with global routing operations. Working group.

B

Maintaining critical mass is a challenge for some operations area working groups, so some of these things span decades because we don't get to just declare victory and go home in some cases um and so part of what the responsibility of an area director and the working group chairs is to judge where there are critical levels of activity and or kill off areas where we're no longer doing a good job or where we lack critical, mass or interest for the ITF to still be engaged in those activities.

B

But some activity levels are cyclical, so protocols will go through periodic demand for a change or usable input and then the level activity will drop off again for a couple of years. So that means we have to not be afraid to charter new work just because it might not work out. Sometimes we have to make working groups dormant and then find new chairs. When the level activity works up.

B

There is a tendency among operators to think of protocol developers as some form of subhuman.

B

It's kind of important to not make the operator a developer relationship in an us-versus-them act, kind of stance and we try and maintain that in in the operations area. In many cases, the the participants in the working group and and the authors of documents come from both sides of the fence. So developers come here um because they need feedback and operators and consumers come here because they have problems and because they have ideas on how things can improve. So we try and do this together.

B

So on the ITF operations area, I think serves an important function, and this is one of the key focuses of the Operations Directorate in in performing review is to look at other ITF work with a with an eye towards its operation and management considerations. So this comes up in the charter of, for example, new working groups, so something that is very important right now in terms of IETF activities, was the chartering arm in the beginning of the effort on the quick protocol on now that http/2 is done.

B

There is a significant amount of interest and effort looking at the quick protocol and one of the things that we as operators are concerned about with the quick protocol, is a the potential for loss of visibility into things like flows um that are necessary for the operation of devices like firewalls, on for IP flow export to work properly and for us to have visibility into traffic on our networks.

B

So we review the quick charter um and we get some text added, which I think uh actually speaks to the manageability of the IP protocols in general and is maybe a feature of them, but was not actually a design consideration back in the early 80s. So there's this been a significant amount of work in the area of how do we provide guidelines on to protocol developers on what operational issues are and um how management should be done in the rest of the ITF?

B

So you can see in then was efforts around yang on that effort bearing fruit, because um operators do need tools in this space, so it was no longer sufficient in the IETF to just do protocols and not do management interfaces, for example, for them, um because the operator community has to knit all these pieces together um and that becomes harder over time.

B

Don't look at the current set of working groups that we have we're actually going to go through all these real quick, um so we can just go into that benchmark methodology. Working group I think this is the oldest working group that I have um currently it's been operational since 1989.

B

It was started by a guy named Scott Brandner, who many of you might be familiar with, but at Harvard he had a thing called the Brandner lab, which did ethernet switch benchmarking, and so uh he brought a great deal of levity and sanity to UM the measurement of forwarding performance in routers and switches and um yep.

D

Well, being in the window side and being involved in prepping, their box to the burner lab I have some interesting history. What lenders did to get the numbers? Oh, yes, absolutely! That's!.

B

D

Why, I wonder is just your opinion? ah How much value operators put in the benchmarking numbers so I think in.

B

This way- and this actually speaks to sort of the ITF as not being Internet Protocol police, I- think what benchmarking methodology gave us was common language to describe the properties of things. So I have a tendency to not have a tendency to not take seriously numbers that I see published in magazines, because the circumstances under which they are created obviously have a you know, can be viewed with some suspicion.

B

On the other hand, I can use the language that the ITF has given me and that the tools that benchmarking methodology gave me to compare the performance of devices and at least talk about when they deviate from my expectations, for example, what it was that actually happened. So you know obviously, as vendors and I have actually worked at a firewall vendor.

B

So I have some direct experience with, say: TCP, I mix, performance funding, I I think we could say of vendors that, like um and as consumers of this technology, that that actually did have real value, because if they were all making it up themselves, it would be even we'd be even worse off than we. Then we are now so um and I mean this gets.

B

This has continued to evolve.

B

There are all sorts of things that people care about performance aspects of not just forwarding performance, um so router convergence, for example, are things where it's helpful to be able to do to come to have a common language to describe them, and the RFC series, through BMW G in the last 30 years, has actually done a pretty I think decent job there, and it of course covers things other than routing and forwarding performance, so sip traffic management, neighbor discovery, virtual network functions are all things that have been done there um DNS up, um so we essentially have two working groups where lots of DNS work was done, dns xed, which was dns extensions, and that was in the internet area and dns op, which had a tendency to handle a behavioral changes that dns operators wanted.

B

um Now we just have one so we have dns op and so that actually simplifies things a little in other ways. It makes it more complex. This is another place where outward-looking arm outreach efforts are done.

B

So, for example, um the ITF has a responsibility for the technical operation of the root zone, not for the done for the contents of it or the management of how things get in or out, and so that that puts us in an interesting position with respect to managing darpa where the reverse zone is and the community around that is organized around DNS up.

B

So this provides an interface for other constituencies. They can come here arm and work with the ITF on the technical problems associated with this area.

B

Grow is global routing operations, um and so this essentially exists as a companion to IDR in the routing area and it documents, issues and operational practices with BGP routing table size, IGP interaction, security and VPNs, and it works on best practices for configuration and problem statements. So, for example, if you see something about route, flap dampening being considered harmful, it probably came through grow right route. Flap Ralph, lab dampening is, of course, not an ietf technology.

B

It was a vendor specific implementation which everyone slavishly copy copied from cisco, because it actually, you know, does essentially what it was intended to do, which was reduce cpu utilization.

B

On the other hand, it needs some bumpers to make it safe, and so that's a place where operators I'm provided feedback to implementers through the grow working group on that M Bundy, contrary to some people's expectations, a multicast routing actually still has a quite a viable life span, even if it's not even if it's not the interdomain promise of the early 90s for multicast routing, so that work is coordinated among operators on, and it also has a companion routing working group, which is the pim working group um operations in management area.

B

This is an important working group. It's our catch-all working group. So uh the ops, AWG and operations area of meetings are code joined on we have chairs. Here we have a sufficiently broad enough charter that we can.

B

Take on operations, work or almost anything in the operations space without having to charter a new working group. So it's nice to have a place to stuff things. That does mean that at any given time, it may be working on some unrelated technologies.

B

The other thing that we do there is a maintenance of legacy arm management components, so things like mibs that need to go away or get mark historical or deprecated and things that might potentially be dangerous, that we should that we should get rid of from the IETF protocol. Specifications occasionally come there um um and things like mibs that might be informational that don't justify spinning up a dedicated working group tend to get house there, so that meeting can actually be interesting is a smorgasbord, but it's also a place where you might potentially bring work.

B

If you don't have an idea where it actually should go, and that is actually good place, a good opportunity to talk to either the working group chairs or the area directors about whether um the operations in management area, a working group is a the right place to put work.

B

Opsec does essentially the same thing except for security, specific work um and it develops recommendations and best practices for the operation of things like control, plane, police ears or control, plane, ACLs or default fire postures. Things like that cider ops is actually newly charter. This is my first new working group in a year um and it essentially takes son arm the remaining work of the cider working group, as that is closing down because it has completed the core specification for cider.

B

um So inter-domain, routing again in the internet area, is sort of a companion to this in the sense that that's where bgp sec protocol work is going on right now, um but now that we have is have a cider specification arm. The operation of secure inter-domain routing and the rpki is going.

E

B

Be a thing that is quite involved as far as deployment goes, because it has a number of constituent parties and its operation has not yet matured significantly. So you know we needed a place where that stuff could cook, oh and so it starts within a whole, stable of documents in sort of intermediate stages related to the operation of various components of the rpki.

B

And finally, we have v6 ops, and this exists as a companion to the internet area group six-man, which does the protocol maintenance for the ipv6 protocol stack, and this does this concerns itself with the operations and deployment of ipv6 networks, and so that's what it's focused on. And finally, that means we've made it to the end here in good time. So there is a survey and I'll leave this slide up for a little bit if you want it, but it's also in the set of slides um and will be in the agenda.

B

So if you want to offer us feedback, that's usable d 8 for the education, the edu team. They can't get rid of me because I'm an area director, but it would be useful to them to know if this was useful for you, and if there are any questions you can either bring him to the mic or bring them to me directly once we close this down cool.

B

F

F

B

Yeah we can. We can do that. um This one is also this one.

E

B

Be online, if it's not already, click yeah I can try this entity.