Internet Engineering Task Force Interim Meetings, 7 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OPSAWG Virtual Interim Meeting, 2020-04-07

Description

OPSAWG Virtual Interim Meeting, 2020-04-07

A

All right welcome everyone to the virtual interim for ops AWG. This is in lieu of a.

A

We are on WebEx, and this is a recorded session.

B

A

Am now, hopefully, you can see it I.

C

Cannot and how about anyone.

A

Seen the slides yes.

D

A

The lag will catch up as I said, the virtual interim for ops AWG. This session is being recorded if you've had difficulty joining with your computer. Try the call an option make sure video is off, make sure you're muted, unless you are speaking just because there will be a lot of background noise, you have the ability to unmute yourself, but if there is background, noise will mute you to join the mic line.

A

Just do a plus Q of the loop X chat, make sure everyone is selected and if you want to step out of the mic line, just do a minus Q. The jabber room is there opps AWG at jabber at IETF, org I'm, currently, sharing I can't really monitor tendrán is is out there looking at the WebEx chat and the jabber, but if anyone says something substantive jabber just have them go over to the WebEx chat to join the mic line. There is a virtual blue sheet I'll get to that.

A

It's like there's a virtual blue sheet. I'll talk about that in a second, and we mentioned the jabber room. This isn't official idea.

A

So the note well does apply I'm sure many of you, if not all of you, have seen it, but it is up here be aware that anything, you say here anything that you type these things are being recorded and these things you've been Trat. So the note well applies there. Ten ran and I are your host. Today we did the note, well the blue sheet, the virtual blue sheet. If you go to that etherpad link there in the minutes section there you'll scroll all the way down to the bottom past.

A

The agenda you'll see a register, a blue sheet register, where you can add your name and affiliation. We're not really gonna have a jabber scribe. Like I said in meetings, these other virtual meetings, I've attended, it's mainly been used as a side channel. If anyone wants to record something just come yourself, if you can't, for whatever reason a tin rim will look or anyone there in the jabber room can act as a proxy or just let.

B

A

Know that there's something there and I can I'm I'm logged in as well I. Can this and go look at that? The slides are posted at that link there. We will be going through them here, obviously, and we're all on the WebEx channel or what X meeting, but you can see the link there as well in terms of the agenda. We have the current status of our documents and then we have, of course, a number of presentations.

A

Good news is tax. The the authors have closed all the discusses and the document is moving forward. A warrant pushed that through so I want to thank the working group. The author, so I, don't believe, are on today for all the work and getting that forward because of that, the the yang, tak X draft or tax yang module draft, we think, is fairly stable, will do a working group last call after this network network telemetry framework they've incorporated recent feedback from Adrian federal and they also think it's ready for a last call.

A

So we can push that out there. The SDI secure device onboarding work that Waring and Colin were working on Michael Richardson, that it did a Shepherd write-up of that and then now we're getting this additional feedback from Tom Michaels, also chiming in there. So there's been some revision to that and there likely be some more before it's finally submitted to the iesg for further work. We put out a sector request for review.

A

We didn't get one there, but regardless when it, if we don't get something on the security side, when it goes through, the the a DS and Warren has also reached out to an ad to to look it over. It will get eyes on the L 3 s, ml, 3, nm and the automation framework. Those are going to be presented today.

A

Anything else dad on this tender.

A

Oh great, so the other thing we've added is a op zwg github organization. We've got two documents being worked there, if just like any other github organization for a working group. If their desire to move a project there let 10-run- and I know we can add those members. This is, of course you don't have to be a member to contribute. You can go here now and and look at these projects if you want to use them for issue tracking or on this of the version control by all means.

A

We have that set up now and we have some boilerplate and kind of note well, markdown that you can use if you're interested in moving a project there in terms of the presentations we're going to be front loaded with some of the working group items, the things that have already been adopted, we saw the two of them will be presented today. So you see the network automation framework, then we kind of group things together where they fit. We've got some additional related to the l3 work.

A

There we've got the mud our right in the middle sampled traffic streaming. We heard from Andrew last time here again, then we have I fit. We have been well, unfortunately, he's under the weather I'm, with some notes from him. Will that and we'll finish out with something that was initially ad sponsored but requires a some more eyes on I? Think and that's that IP fix packet sampling protocol, both data export work.

A

There are some additional drafts. If we have time this is a packed agenda. If we have time there are two others, that's in the agenda on the etherpad we might get to it, but knowing history we probably won't I asked the authors, the presenters please be cognizant of your time slots and and do your best to fit in that and finally, we'll move over to ops area. There's some open mic time with that. Are there any questions on the.

A

Excellent I would also like to say that we have a new op stadion Rob Wilton he's joined us is on the call I'm welcome Rob. Thank you for stepping up to be the ops of management, I, believe, ad and I'm sure you will have a more formal introduction in the ops area section, but I'm I'm, very glad. You and Warren are both here joining us this morning evening or afternoon.

A

With that, let's get our first presenter queued up you're all still seeing this and I believe chin you are presenting I will do the needful with the next slide. So please unmute yourself, chin, woo and take it away.

A

A

A

I, don't see him, oh, there is chin. Are you there you you?

A

C

Hear me yep, let me see your problem. The list see.

E

A mark against his name, I did.

A

He's got his head from icon. There.

A

Well, he seems to be having audio issues. He muted and unmuted minute and I will ask if he can't get situated quickly. Oscar, would you be willing to go and we can just flip you yeah.

F

A

Two around.

F

Yes, we I kind of started in the next presentation why the while team solves his chin.

A

If you can hear us we're going to do that, we're going to let Oscar do is first back to you and then we'll flip back to Oscar, so slight agenda bash here, Oscar! Take it away! Okay,.

F

Thank you very much guys and let me know if there is any you can hear me properly. Yes,.

A

We can you sound great thanks: okay,.

F

Perfect so I'm gonna send you the today the updates of the layer, 3 VPN network young model just to just go to the to the next slide, please. So what I'm gonna tell you which had updates from the zero one version, which is the last one that was presented in the last IDF meeting? Now we are in the all three version we submitted one version last week just to there were some some issues to to close that we did not have time when submitting the O 2 version so I.

F

So there we have the oh three now so then, after this set of update, I'm gonna tell you some going to some specific sessions where we had a or some parts of the drop that we have a more advances: the the multicast, the assignment, which was one of the open issues in the the last one, and also highlight one of the collaborations that we had with Diaz for the water service, mappings and then continuity steps. So please go to the next slide so which are the changes.

F

So, first of all we have some new contributors, so we have Lucia Manolo nedeth, so this happened and great contribution. So especially the del 3, the multicast 3 VPN, was completed.

F

Also, we have many many new insights and refinements thanks to the contributions the document is quite is quite good, so we have the. As you mentioned earlier, we have the official l3m repository in the officer working group repository hub, a group. So here you can go there check all the all the issues, all the requests that people have been contributing, all the all the commits.

F

So here we have third tissues closed and the each of these issues have been discussed in the calls that we make regularly or either in the mails or sometimes there is a discussion. You can see it there. The discussion in the legit I encourage guys to always to try to live there. The the comments contributing and commenting in the deed hub is like contributing on the list. Ok, so it stays it stays there. So you see that there was a lot of activity it with 264 commits. So so it's been quite quite active this one.

F

So regarding the changes themselves, so, as I mentioned, the the multicast report was completely was revised and updated and we validated against the real use case. So it was the IPTV multicast floor of telefónica based on l3 VPN, so we tested that everything, at least against a real use case a say, was needed. Then there was some requests to support some more complex, important export profiles.

F

So we added the possibility to create an or operations between communities, so so, for example, two targets or two other targets in the in the examples analysis, what you want to add it in the two requests that the model also a an issue with the how to identify in the VPN that were accessed and just to remind you that the in the VPN network access is the point that enters the traffic into the into the VPN. So there we added the port ID to clearly identify which is the interface or shrub interface. In a topology.

F

Previously we had just a in the VPN network society with its just an ID, so anything is separating. The concept is much better. So also we checked a lot today that we had a lot of requests coming from the many operations requesting be able to spread through the model, a some PCP parameters, so yeah.

G

F

This is not a range model, so we wanted to be able to pass through the through the network model. Only those PDP parameters that are essential and they have they have real operational needs. Also, we added one additional CP routing protocol is, is because we denta fight one use case, but at request from an operation that required it. So next slide, please, before.

A

I, do that I put myself in the queue on your tracking issues and get up, and that's fine, but this is a working group document and I would ask that if there are any decisions, anything that you you need working group consensus buying on that the list is the canonical place to go so, please be sure you're taking those things to the list. The the github is in a reply for that it's great for working collaboratively, but some of those things do need to come back. So the working group has visibility into into that work.

A

That's happening. Ok,.

F

So then, let me do the following: after the after the meeting, let me try to get all the discussions main discussions there to the list, taking them from somebody of each of the discussions that happened in in the jeat and that drove to a decision.

F

Thanks, so then we had a solved the out assignment issue that we had in the last IDF this one. We solved it querying the through the mailing list. So here the unexplained later we made the RT assignment optional previously was mandatory. So that is no change and we added some a way to express some preferences on the underlay. So we can ensure the operator or the service orchestration layer can indicate his preferences.

F

So if you want a LDP, if you prefer as VPT tunnels, if you prefer salmon put in etc, but the service mapping itself, for example, it you need to map to two tunnels- is done in a document with it.

F

Yes, so also with- and we did some minor changes like in the VPN node only have the net willamette ID sake, so for each node in the network, you can have only one VPN node for that particular VPN, and we are clarified, as requested in the in the last IDF meeting, the relations with other Jiang modules, so especially with l3 SM, which are the relations. Even we added a pointer reference to Dell 3sm, so you can match so you can. If a Services has.

D

F

Because of handle three same request, they pointed to the three same IDs added, and also we added a list of potential service modules that can be used. Also, we clean the young module. Please go to the next slide.

F

We review the test and we are the some samples of the use of health freedom. We added some examples and also we added one more implementation by Jessie Telecom that contacted fast. So we know that there are more implementations around so just including them is a matter of the management approval.

F

So, in sake of time please and go to the next next slide. I'll try to be quick so in the BEP parameters that we added, so it goes to have with a beaut. These are the the ones that finally was chosen together to the model to the modules of the BGP description. So people wanted to suppress there, which is just the string that will go and pass down later so it is.

F

It facilitates the troubleshooting, the administrative and operational status so to check the health of the PD in session directly from the l3 named the local autonomous system. So you can overwrite the the autonomous system. We have seen those cases in reality, while the VPN has won a yes and what you show to the customer is another different idea. So yet you can overwrite it and in the security allow the encryption in the DD pcp session go to the next slide.

F

Also we, as mentioned with a lot of work, to support to finally support of multicast, so we updated the multicast container, which is mana stability and node level. Now we added an any cache container. We added a couple of lists: the local address, which identified the IP address of the local trend as well.

F

Also, we had a a set of RP addresses, so these are all the IP address from all the route that I said the same vendor was point. We modify the name to clarify the anything, because we have a parameter called the single address.

F

However, it was not quite full so now we change it to Group prefix, which is much the role of the parameter another the MSTP protocol container, so with with several leaf. So if it's enable or not the protocol, the peer, the local address so to configure the multi-source rediscovery protocol and we others and we removed the customary flavor con container and for each of the access we added the remote source. If so, we can go to the next slide.

F

We don't have much much time, so the sign meant we had three possible behaviors that then they need to control.

C

F

I think this this was discussed in the main list. We had required net mod for the for guidance. So, finally, we included a solution proposed on the on this feedback, so include explicitly in the description of the junk, the in the behavior that, if it's not no leaf is created, the entity must has out assign a value and that in the value itself include an empty type. That means that you don't want anybody to be assigned, so please go to the next next slide. This is a joint work.

F

We yes for the service mapping so is to be able to identify which have a set of LSPs orbital network or tunnels that are associated to a given service. So here you have the reference and I think s it will be presented on on. Ts is a collaboration with with es so go to the next slide and I finalize the presentation.

F

So we now, after all the the changes and discussions among all the all the offers, we think now that the the jam modules is stable, so we are now. We believe that we can go for the young doctor review within that there won't be any major changes now in the structure and so on. So just some tweaking in the text my we needed just to finalize they even at some point that might not be clear and so on.

F

We can work on that and we asked their working group to review this version of the of the document. So so we can go and have a finalized it in a couple of in a couple of months.

F

A

A

See anyone coming in the queue I noted your yang doctor review. We can. We can get that put in for you after this and talked about just those those decisions, those kind of what you need, the the working group to weigh in on, especially because they're asking for the review just summarize that from github, please, okay, so you're still on deck, but chin has told me he's bat chin. Can you hear me.

A

We can't hear you chin or you call an user five.

G

I call through the phone is.

A

That, like we, can hear you now, no okay, so I'm gonna put your prisoner.

G

Yeah start: okay, your.

A

Presentation back up here and hopefully you can see cuz, it's gonna be kind of hard to present. If you can't okay, take it away, then yes,.

G

Yes, I can yeah. Thank you. Thank you about that. Actually, travel to join yeah I can hear you.

E

G

Maybe okay, so this chapter talk about a young model, automation framework and I'm here to present this- and this actually is a Johnny Walker with the many operator, and the name we listed here are also this dropped. Next.

G

Next yeah for people who don't know what are these jobs talking about? Actually the attacking audience for this job. There is operator and young model developers and implementers and I think the big challenges faced by the operator when we deploy young to the model at a different layer is how how this motor put together to provide service delivery and to to to realize the service of fulfillment. So this chapter really provided guidance to show how this model model put together for service, fulfillment, service delivery and the architecture we propose.

G

In this chapter we identify the common functionality that can be used by multiple models. These can travel to peel the for a young business system, so also, we actually give a separate example to show how this common functionality can be used where they can be used. Next.

G

So what is the kernel standard is Java. This chanta has already at occupy the obvious averaging since last single meeting and better. This job has been around for a while and this outcome of the young sorry meeting in last year. Actually the changes were made since the last working. Actually, we try to address the comments erased, onion, not the thing about meeting one of comments from local from Morand.

G

Actually, he what he suggests actually is to move service, the commission from the net, whatever lever to the service level, which so we try to achieve this- also a kind of comments from diego actually to try to clarify the service verification. The position actually clarify the relationship between a service, verification and service creation and modification. In addition, actually we add a new figure trying to add a more details about service attribute and coming up with a reference, and we also add a new use cases for the 10ml, even base potential automation and so yeah.

G

Also, we try to complete the security section and make it more completed. Yeah next.

G

So model layer model, layering and representation compared with the previous version. Actually, we are the more details about service attribute that be defined in the service requirements. Actually, this service attribute can be classified as a separate category for number connectivity flow identification traffic, a service as raising routing and for forward in sexual and, for other part, actually the same as the previous weight with poster next.

G

This is aperture for the service and network. Imagine automation actually, but some comments from the Lauren. Actually, we actually moved the service decommissioning to the service layer innovating. Actually, we add one photo op or feedback from the network treat her to the service dog treat her. We can provide the service assurance notification and for as actually important part of like a multi-layer magical, main service mapping and administrative service, decomposed accommodation actually the same as a wave about the people and next.

G

So so the changing we made. Actually this it's a use case we proposed in this chapter. It talked about the third week in service delivery. We use every SML to pass the exam brought you here. Actually we just provide a top-down service delivery, but what is missing actually is when you get a service deployed by the operator, so operator also care about the weather. So it's a get.

G

It deployed successfully another cases so that when you get a service setup or get a network setup or you really need to care about, what is the network performance look like? Actually, so we lack the feedback are from lower layer to the a player. So we so in this routing we add the the feedback from oaktree confirm the controller to the operator. Also add the feedback from the operator to the to the customer. Next slide.

G

So this feedback- or we call the air Sri um notification or capability- oh you actually, and on top of dog sitter, we have also added a notification. All of these, the 3-pack or notification can be used for many peppers. The wine, our peppers, actually can be used for the peeling or accounting actually. So these also are very important to to provide the service assurance. It was a closed loop management.

G

G

So the to the Surrey use cases proposing this job that actually the photo to cases as a crime trial. We added a missing piece at a feedback in the sorts of cases about every region, service delivery. For the second case that we we don't make any change, but also it you know, can provide several assurance they're using the Holmes amendment at any mention model, and also we added the third cases. We can support event abate. Can dementia automation?

G

The idea is, you know you can dedicated men, will control logical to the device and populated policy from a controller to the device, so device can provide a device, several temper management and provide a quick response to to the events actually, and so this is a change we made. Actually this case actually also compute the closed loop management within the device. Next.

G

So we think this chapter reaches completion. Actually, what is the missing piece? It is about a service assurance. Actually, we already, you know, add as a notification ability, exposure from the lower layer to the upper layer and talking with our cows or and editor, and we think maybe we consider to add another example to show how these services that can can be performed. So we would like to hear more comments within this meeting and we hope we can request a working without car in June to get this worked on.

G

That's all Thank You comments, lana suggesting feedback.

C

General yeah, you mentioned that their service assurance and bhai meant I'm seen in the slice. Is there any connection to the work the benoit proposed that were present later.

G

Yeah there's some some connection. I think the service our service actors are proposed by umpires providing more you know, abstract air sure, the whatever he needed is you know you do the translation between the technology independent, the metric performed in Mexico to the technologists Pacifica performs in metroburg in our more you know, I proposed. Actually we you know we, we can leverage a young data model and also young Washington dimension mechanism to develop some laws on innovative performance and maim and the model to aggregated performance metric.

G

And this and more you know, you know, connect them metric or from the under nine networker. So what he proposed actually seems, you know he was overlay architecture. The Haredi may rely on the you know, metric challenging translation or metric engine to do the translation between you know the the the technology independent metric and technology stress of a metric that that's some something. Okay, you know relationship between to work.

C

Okay, is there any other comments, I.

A

Would say that on what you have appear chin about adding another example and common stories in the meeting if you've got specific questions of the working group example, you might want to add I would just bring that back to the list to get more people looking at it more input ahead of any last calls any additional expert reviews. You want at this point like an orderly review in this document.

G

You know I'm not sure we can replace the young doctor review, but this is a you know: chapter, maybe nothing John talking to about it and about the you know. For example, we I would talk aways. My cars are mad actually about this example and bring back to the list when we come when we, these kind of you down bro, yeah, sure.

A

Thank you, I would I put it in the chat, but I'm gonna say it again. If you haven't filled in your name in the virtual blue sheet etherpad, please do so. The link is a lot of places. It's also in WebEx chat window, Thank, You, chin.

F

This time it was five minutes right.

A

F

Thank you very much so now before we presented the layer 3 VPN network model, now we received similar requests to do the same work for layer 2. So this is precisely they doing that particular sheet for layer, 2, video, so code to next slide. Please what is the motivation, so we already have a l2 same model that captures the the VPN service from the client a point of view. So in order to deliver the service, we needed this modern Network centric view that takes or digs more into the network details.

F

So we have this new module. This l2 a name is a young module to manage this provisioning of the layer, 2 VPN service in the service provider network scope. So we can use it to to drive the configuration, the detailed configuration of the devices and underlying transport that you will need. Ok, so please go to the to the next slide.

F

So what is a? We try to maintain the same module structure as in the S&L 3 VPN. So in some cases you might not need the all the information so dependent, because these these model aims to cover all the different types of to GPS. Okay, so but the concept they say we have the everything it was around the VPNs VPN service, so the young module contains the list of ppm service in the service provider network managed by that controller.

F

That has a VPN nodes in all the points that you want to have connections to the to the VPN and you have VPN network access, that is, were the traffic a thumbs, so you, the relation, is 1 to n or 0 to n 0 to when okay. So please next slide, so we apply it inside the service provider network. So that is between these. So that is the the border of the of the VPN or the L to an M scope.

F

Here we need to support point to multi-point all to point a multi-point to multi-point services and also be able to select, which is the ender lion, a transport that you don't want, whether it is MP MPLS, whether it is VDP segment routing. We also want to express that a preference in the modem, so please next slide so.

F

Night, ok so, which are the the highlights of the of the of the module. So so we started from what was existing in 2sm and we added the pieces that were needed to feed the network view so, for example, support new service types, for example EPP n. Here the I think there is a lot of work now in base for doing the device device modules to support a VPN. So I think this is the is that fits in the middle supports all the legacy access technologies.

F

So we need to support Ethernet, good, illumination cetera, so we'll have many kind of accesses a before requesting the underlay transport protocol preference over. We want VDP with a 110, dp7 duty, etc a support redundancy. So we have and remote terminations support some parameters of sample their target role, distinguish here for the VP VP LS and support administrative and an operational status. So these are the the main editions of the model. So let her slide. Please.

F

If you want to contribute now, we have the in a private jet what we are using the same procedure, track issues and receive comments. Also, please use the least or so not to wear something like they compete they did and the under list.

F

There are some issues that have been discussed to improve the model, for example, this day the service mapping would have already done a collaboration with with TS also to include this to map in map in there, and also we have also some contribute some implementations on the weights of cotton. S is like this, and then we finalize so here we request the working group to review this document, see if it's useful, see any flaws.

F

Anything that you want to add so want to fix these issues and comments from the reviewers and if at some point and you think it's worth a NASA working group and not just an individual, it also would be great and.

H

F

This I finalize the thank you very much. We.

A

Have two two people in the queue version, mainly your first.

I

Ok also, can you hear me Oscar have the two questions? The first question I see that you have the open usual for the Lincoln supporter I'm, not assure you, the Abner sure if the EVP is not supported in this draft or just some creases of the EVP, you are not as important by this I.

F

Think we have started to add the David in the EBP n support. We we added it in the last version of the of the draft. So now now it is supported.

F

I think it was in held to a same where it was not not supported, and but maybe what what we need to check if, if all the parameters that are required for later trigger in the EBP n device models are available or not, so that that work of reviewing all the EVPs report is neither sort right now is just a type, so you can request an EVP n type. So there is work to do.

I

Is a the second of question? Is that I say that most of the are to live here? Features are supported, I want to know because they are to be being is a little complex, I want to know for the eight years a mr. here, a hierarchical are to live here, can be supported by this service model.

I

F

Would say GS but I, don't know whether I wanted to review whether everything needed is there or not. We will need to review it.

I

Okay, so how about the inter, yes scenario,.

I

F

Think I think yes, but maybe some of the first can also want to cover one to answer.

J

One of the use cases that we have been planning to support currently in them whether we support the selection of the transport protocol or they underlay transport protocol. So in theory, yes, option C was the target use case that we were expecting to solve. So in this case we can select BGP as the transport to call and we can configure or assign also remote address of the termination point of the VPLS. So in this case this deployment is supported where.

K

J

Are still enhancing the set of network parameters that we are required for, the Yaqui can be paralyzed, for example, and another use cases that we have in our network.

A

In the interest of time, I think this is a discussion for the list, especially since you're looking to get that feedback I like to go to the next person in the in the mic line to Italo busi.

A

So we can clear the self-timer section to the list. It's all Thank.

L

You Oscar. Another draft in a second working group which is addressing a similar problem, is mainly focusing on traffic engineering. So there may be missing pieces, but there is a lot of overlapping, apparently between this raft and the cecum working group draft. As you consider the debt and the relationship between these two documents, which.

F

Is the document that you are referring? Can you point the type.

L

Decisions they eat.

F

L

F

I think the client signal model was more aimed at the pure transport part right, not Ethernet. Vpns. We need to check out with. There are any.

L

Overlaps there are eating services that can be supported all over transport and also covered by the draft yeah. Okay, we can talk about that.

H

H

So my my question is more mental question here, so we've got two examples of network models here. I'd have lots of, has lots of device of all yeah models? I'm trying to understand is how much work is there in a general area of network quite yang models? Is it just going to be an L 3 and L 2 may be an l1 network model, or is there going to be extra models for covering there's features from network Y perspective?

H

So my question to the authors and maybe to the working group is how much work is there in this general area? Is this something that we should be focusing separate working group, perhaps on on this area or either having up so GG the correct place.

H

For tonight.

A

F

A or right now or the kind of services that we were started to to focus inward on these two because they were the ones that were more popular in our network, so they say from from Ned were operating operator perspective. Those are the ones today, so should new services appear, we would expand it, but for now, as I think as currently in in since presentation, there are regarding these two main services or network wide services that are presented today. There are gaps around.

L

F

So, with these two drugs focusing on some specific just a provision in par, so we think we need to solve a or to control in gaps around that more than right now, in our view, tool to add more services. So this is, there are more services that require by operators. Of course, there will be more more war, but for now service wide perspective, two are the ones that are in for us as operators, we see more.

H

A

Sounds like for now the scope is fairly limited or restricted least and fits where it is, but it sounds like if there are gonna be a proliferation of this. Maybe that question can be revisited. That's.

A

That clears the thank you very much Oscar.

A

Next up we have med okay, they're on the yang model for user and network interface, topologies.

A

Med, can you hear us.

M

Yes, so distant, this presentation will be about the and the user network interface, so this will be I would say, ID a natural continuation of the two models, as presented by this car, the one about the e 3 nm and the 2 nm, and actually we we decided to read this graph as a separate one, because it was a I would say it's not specific to a given service, but it can apply to to multiple services.

M

So if you can next slide, please- and so basically I would just describe be I- would say the the issue. Why we need this kind of models, then you were to present, you I, would say briefly the overall structure and then to discuss some next steps from the drive. So if you can move to the next slide, please, and so just I would say a simple view of the I would say of just a network in which we have multiple customers.

M

Each of these customers have their own sides, and this sides they are connected to two services, are delivered by a given provider.

M

So these customers has its own view of the service which is provided by my who said by the network, as can be shown in the next slide. For instance, if we focus on the I would say on the block customer, the block has done what it sees. It sees the next slide, please what it will see, it will see.

M

I'm I would say a topology in which he has it customer the each devices that are interconnected and has they have connectivity by some magic, which is provided by which a by the network provider and sometimes not by multiple providers and all what it sees as this topology and but now, if we go down to to to the provider, as we can see in the next slide, we will have I would say no it's.

M

We will see at the service layer, which is a really SM which provided that was an abstraction of the service which is provided to these customers in you to this, multiple I would say signs or what we see we see the I would say an interconnection of sides. We don't even have the devices and then we, when we translate the three SM service model into the l3 and network model, as can be shown in the next slide.

M

We will see right now that the service, so we have the same service, but we have multiple views and now what we have, we have only D I would say the interconnection between D and the the provider edge routers and there's this topology, which is all only shown and maintained by a network controller.

M

So there is something which is really missing here with if we want to have the gap between the service which has seen by the customer as the service as perceived and seen by the another provider, we have something which is really missing in the next slide. Please, which is where to deliver the service this can be answered by including by defining or by including a reference into the interfaces that will be shown.

M

The next slide that we call the user network interfaces, so this reference points are important to have the gap between I would say the over server, which we should be provided and delivered to a to a customer and the the current view. We have a D at the network level.

M

So if we enrich the information which is provided at the entry and then I would say a little with the various reference points that are pointing to the interfaces that are used to deliver the service, we will have something which is more rich so that in the next slide, for instance, we will see that the network controller now has I would say the holistic view on all the I would say the point in which he can he can deliver the service, so the network topology we have today India that are defined.

M

The various models in the ADF can be enriched with this information about the the user network interface, with focus on the USA on the provider side, we do not focus on the customer side because we already did the current topology models already provide this kind of obvious. So if you can move to the next slide, please, which is that this is the which it is simplified I, would say the modern of the user network interface.

M

So we we are adding this service attachment points with with identifiers and also with more information about the encapsulation tablets can be enabled on or parental phase. Next slide. Please.

M

So, for for this model, we we we could decide to to have this I would say this destructor included in the ill Traynham graph that we have already adopted in observe working group. But the point is that this kind of I would say: free formation is not specific to a given servers and it can be reused by other services or models, for instance the layer 2 and it work holders and so on. So it's it's not really specific to a service.

M

So what we know to what we would like to do here from the work group and.

D

M

A direction for this work with we maintain that a separate or we can just maintain it on the one of the current models and that are already presented by Oscar, for instance, the liar to nm or into the liar 3, and make presentation.

A

X-Men, it's all abou C is in line most yes,.

L

Thank you. A it's similar comment to the previous one. We have a similar draft o adopted this working group in C camper, because we have exactly the same problem when we set up a client service over transport network. It's that you need to know the Uni xur, which I agree is generic, but also you need to know the color I know. Some. Some boxes are, for example, in layer. 2 are able to do villain classification. Some are based on one.

L

Some ways onto some are not based are just doing it on a frame based mapping, so the Uni discovery is something generic, but the capability are specific and we have some work already in Sikkim. So I think we need to reconcile a little bit.

M

Please just sense it as I pondered through your document and let's work together on on pushing this forward. Yeah.

L

C

Yeah and I have I have a clarification question: what's the type of this kind of model I mean the service model or network model or device model.

M

C

M

It's a firm, it's a I would say a topology model which will augment in current I would say. Dd current network topology, which is already I, would say, specified in existing RFC yeah, who.

C

Will consume this model.

C

mmm Or else we SM all.

M

Of them can consume that model.

C

C

Because right now, right now there are several kinds of models: the service models.

E

C

And also the network model at l2, an M and the device model for devices, so it could be used for all of them.

F

This is car a if we go for the jin-woo's presentation at the at the beginning, with the with the network, control layer and the service orchestration layer. I think this. This topple. This is a topology view that can be exposed by the network controller to the service orchestration layer. Tell him from which points can service be instantiated. So then the service orchestration layer and use the LED l3 and a model to an M to request the desired services in the potential endpoints that were shown by the UNIA topology.

C

Okay I see this is a new kind of source abstraction and may be changing. That's a framework document could describe this kind of things.

N

C

Going to expand or ask questions.

A

Yeah sorry I have to unmute : user five. Here Jen go ahead.

A

Jen. Can you hear us.

A

Cannot hear you this.

F

Mutates I think my riddle appears. You know this is my scream kappa hello.

G

Can you hear me yes,.

C

G

Can you hear me sorry, I, muted, I, muted, similar answer to the tenth question? Actually you and I two velocity model is nano eleven model similar to the Nano topology model. That I saw to be published it actually as a met, my mother Clara, so yeah. We definitely we can show this. You want veloce usage in the young model, automation framework of chapter yeah.

C

Yes, next, the robot okay. Thank you.

H

I just understand how these fit together, you're saying it complements both UL 2, nm and L 3 and M models. I, don't know how they fit together is the expectation. Then this will augment both of those yang models or does they need to be an underlying.

H

Network model, both this augments so does that do not so I'm just questioning how all these different yeah models are meant to fit together the network. This.

M

Is actually shown in the previous slide, if you just move on, we describe what we call the a we said, Ye, the previous one. Please.

M

Thank you so here we see what you see. The L train M, which is I, would say covering the scope, which is only between every state, the provider edge routers themselves. This is this is what covers by the L train and and then, when we add this I would say the United to the pole, G. We include this I would say this missing piece, which is the demarcation point between the P and the C router. So that's why we don't purpose a that. We are complete.

M

The two models will complement each other to provide you overall to to deliver the overall service which can be and model another. So the complementary here is in matter it's a matter of scope of the network scope. Do you use a network interface? Is it really what what it said? It's really specific to the demarcation point between the Peterborough through and the still routers, and the existing I would say the trend or is to end and we'll just cover. I would say: the PM between the various devices themselves are including he and I would say.

M

The equipment provided by this buddy provide network provider. So it's a matter of scope: it means that we have multiple scopes. What one of them is really specific, I would say to to do specific legs in the overall.

H

My mind: don't have a clear I'll need to read the drawers on how these things fit together, so whether you're augmenting or you expecting yours to sit alongside, but the thought that needs to be some bindings between the l2 and M model and the l3. An immortal and your unimodal.

A

All right next up.

A

Are you can hear us? Yes,.

B

I can hear you, can you hear me.

B

Hello, everyone I am through I'll present updates to Marty Ellis profiles for IOT devices. Next slide. Please.

B

We will go over a quick recap and then the updates to the draft and equations and comments next slide. Please just a reminder of this graph. This draft was presented at ID of several times. This tariff proposes to extend mod to describe TLS interactions. It offers several benefits. Some of the ones are listed in slides. The first one is, is the ability to define TLS profiles for IOT devices that have a diverse communication.

B

It's useful for duty devices that learn new skills and frequently change their communication patterns. It's also helpful for identifying MIT mi tax, especially for I, would read devices which have one durable, necessary implementation, for instance identifying in it quinces in certificate validation next slide, please.

B

So what we have done to validate what we are proposing is we have profiled several I would really versus basically the home network IOT devices. What we observed was lad. The TLS profiles for IOT devices for benign flows was quite different from the TLS profiles for thousands of malware flows that we got from our research lab and the conclusion is malicious. Dtls use can be successfully identified and glock and one of the most interesting one was the TLS profiles for IOT devices, even based on type manufacturer and model, are quite different.

B

B

The updates we have done in the last couple of revisions is to highlight the growing trend of malware using TLS and to also discuss the implications of TLS 1.3, which encrypts most of the handshake, but still allows inspection of several parameters. For instance, cipher suits and extensions, supported versions named groups and signature algorithms. Even the selected cipher suit I in the server error message can be inspected by middle boxes like firewall or IPs. What we identified was several malware could be detected even for TLS 1.3, even without acting as a TLS proxy.

B

For instance, we were able to successfully identify malware, which was using cipher sutra randomization in client, hello messages.

B

We also updated the draft to discuss the scenario wire, firewall or IPS leads to hell act as a TLS proxy to do a full handshake inspection and the section this section has been updated to reflect that the middle box has to follow the behavior defined in TLS specification.

B

Tls proxy may not be viable option in several networks, but could be an viable option. Unita managed for IT manager, IOT devices.

B

The advantage of this proposed mechanism is, there is no need for the middle box to inspect the payload, and the middle box can be configured to skip connections destined to specific services due to privacy compliance requirements, as far as analysis goes what we identified that malware agents, it's quite impossible for manual agents to mimic the behavior of thousands of unique TLS profiles that we seen from IOT devices and it's gonna be nearly impossible for them to keep up with the updates to the tailless profiles.

B

B

To address the comments from working group, we updated the young model to define the three applied TLS profiles once and reuse it. For instance, the TLS profile can be defined for a specific destination. For example, I would really was reaching a forum where server, which is using a private CA. So that way, if the I would really was using here for specific destinations that can be defined in the client TLS profile.

B

We would like more feedback on this draft and we would like to collaborate on profiling, malware and benign flows from IOT devices and would request for working group. Adoption of the draft.

A

C

Right now, I want to know. What's the security considerations on the mod I mean the RFC 8 520? Is that enough and I think that, where you described the motivations on this.

B

Work, yes, we are referring mud as a base young model and extending on that mud definitely helps to identify and define the intended behavior for devices which are headless and have specific communication, but when it comes to devices which have brought communication, Matins mud is not that helpful. So this draft comes in clear and is useful for such kind of IOT devices.

C

It's not provide any security mechanisms itself.

B

The mud profile itself will be provided by the team. Rtls will be provided by the manufacturer itself, just like the motor. The specification that was previously defined.

A

Has been discussion on your draft on the list and and I know that Michael is going to present a few mud related works. It might be interesting to see how we want, as a working group want to progress all of the next level of mud work.

A

Maybe the ad overall will have some comments on. We want to do with mud in general, but III think you said you presented this a number of times. It would be good to see what the that the working group is if we want to start progressing. Some of this, in addition to the base mud, spec.

B

A

Worth I'll take it to do to bring it up on the list, what we want to do as a working group around some of this work. So thank you very much.

O

Just the clarifying question for dinner.

E

I'm not sure that.

O

I, quite la doesn't you yes, this is Elliot, sorry I'm, not sure I quite understood tamarins.

O

It was added in relation to this traffic and was it you want to know if the security considerations are C 8520 sufficient for this draft or the? Where that this draft out stretches those security considerations, do you want to comment more because I think you're we got missed? I just would like to understand. I.

C

Mean in March after I believe for you, you have already you there. Some pretty considerations in that's RFC right, so is that is it to provide the already security mechanism or it's just describe the the issues and describe the requirement and, and this drafted right now provides the actually the security madison. I.

O

I think in perhaps to you can correct me if I'm wrong, I think this draft relies on the mechanisms and security aspects of the underlying mud. Mechanisms which are you know, can be secure or or less secure, depending on how you derive the the URL, for instance, but I don't think this one introduces new security mechanisms to secure mud. That's the question you're asking right.

B

Yeah, the strap does not define any new mechanisms for discovering the URL.

A

A

Spring up Michael, can you hear us and thank.

D

A

P

A

Gonna, do it you take it away right, listen! So.

D

One of the issues going forward is how we get the security for the URLs. The devices provide next slide.

D

So one of the questions is: why do you need to update the mud URLs at all at any time and there's one one way to do it? Is you just update the mud file in place, and another way is that you prefer have the device, when it's updated in some way provide a new URL and there's some trade-offs when the document goes into a fair bit about the difference and one of the places where it turns out.

D

It's it's a better idea to replace the URL when you update the firmware is when you are using TLS profiles, it's my opinion and the reason is that if what you've done is you've, you've changed your TLS libraries, then the profile is likely to be a bit different, particularly if you fix some bugs, and so you would like to go forward with you the profile.

D

But if you change the profile you are going to in the file you're going to make possibly make all the existing devices that have not yet upgraded invalid, and this is a problem. So the question is: if I want to update the mud URLs, how do I do that next slide.

D

So normally the mud, URL next slide comes through DHCP, next slide or lldp, and it gets to the mud manager and the mud manager goes and retrieves. It there's a third very next slide, which is that it can come through an eye dev ID, for instance, through Bruce key or there's. Maybe some other ways that you can use an eye: dev ID to get a URL and that's considered to be no secure mechanism, because the manufacturers actually signed the eye. Dev ID.

D

You actually can trust that this device and the device has proved that it has the private key to the eye dev ID. So it actually has a very strong relay to the mud, URL and manufacturer next slide.

D

So, but a malicious device with malware could put a different URL in the mud or the lldp next slide, and so it could in fact say here's a malicious mud file that lets me attack, Facebook or its favorite target, and it could. It could basically make mud useless, and so that's the problem is how do I be sure that the mud URL that I've been given is in fact legitimate mud? Url next slide.

D

So the shape is the solution. Is that the first time you get the mud URL either by eye dev ID or you might do trust on first use for the DHCP lldp and you get it and next slide.

D

Yeah that way, you got it structurally. Yet next slide sorry next slide, and so then we get the mud URL, the second times through DHCP X. Fine next slide.

D

Next slide too many animations sorry, so then the restriction is that you can actually update the URL, but you'll notice. It has to come from the same location. Okay. So that means that at most you could have a manufacturer. Let's say: LG cuz refrigerators could pretend to be there. Toasters is that a huge issue may or may not be depending on exactly how you organize it next slide.

D

So people have asked well if the idea.

K

D

Large secure wanna just update that and and then you have no problem, and the answer is because you don't generally go through an onboarding process again after the device is onboarding. So you aren't going to use the idea of ID again and in many cases you can't update the IGF ID. It's it's in some kind of a TPM or other secure storage, and you really couldn't update it without in fact effectively doing a factory recall of a product.

D

And if you could update the idea of ID, then maybe the malware could update it. And that may be a concern as well. Next slide.

D

There's two ideas: one is that we update 8520 to essentially do a semantic change that says that the URL that you specified in it the base- that's inside the mud file in fact, tells you where updates have to come from, so that would be a semantic change to something that's already there. The second ad is that we add an extension to essentially provide a base, URL next slide, and so then that's the question. What to do next questions I could take them at the end, if you prefer Joe I.

A

Don't see anyone in the in the queue, so why don't we keep going if there are any I'll? Give you a second? If there are any questions.

C

Hello, you seem no cure.

A

Sorry Elliot is in the queue Elliot.

O

Yes, sir, thank you thanks Michael for this drought and I think it represents a good start. The key thing I I think we want to think about is how might we protect against various downgrade attacks?

O

So could we, for instance, have the original mud URL of a fallen pointer as to authorized, might URLs, and so or could the original mud file have a have a forward pointer to valid mud, URLs per particular device type based on and say, versioning information or somesuch yeah.

D

So so my proposal is the essentially, that is that that's option. Two is that you have a thing that says all future profiles must be prefixed by this URL, which lets you put a firmware version the end and, and that's really it.

I

D

Okay, so this next next running is peripherally about mud, but it's also about IOT and and the great DNS over HTTP and stuff next slide. Please.

D

So typical in a mud file is that you will provide an access control list that allows a particular device. I have used Elliott's classic photocopier printers that we are suspicious about to access some service on the cloud and, if you missed, my air quotes and the mud manager will typically look up that that service by name will get an IP address and install an access control list. Next slide.

D

So, okay, so get some more complicated. The service is now in an a content, distribution network and so you're going to do a mud manager going to resolve something in the content distribution network and if everything works well, you're going to have install an access control list to there so far, everything is it's. Fine doesn't look too much different next slide. Please.

D

So now the device manufacturers decide that they don't really trust the local DNS and they're going to use some cloud-based DNS, whether it's DNS over you know, quad a quad, X or DNS over TLS or DNS over HTTP. It doesn't really matter exactly what matters is that they're going to ask an external entity about this next slide? Please so.

D

Next slide, please double into animation, so it gets back an answer. You notice that says: zero. Two one, two three, four, you notice! That's not the same answer: the mud manager got which was Oh 178 a B next slide please.

D

So the connection that was authorized was to that near server, because the geographically closest device to the mud manager, but the connection that the device makes next slide. Please is some other place which the mud manager is like. I, don't know, I've never heard of this place and it probably gets denied. So that's the fundamental problem that we're trying to deal with is to make sure that this is not gonna be a problem in going forward next slide. Please.

D

So there's some other problems that are related to this. That show up. Okay, where essentially, the mud manager is unable to see what the traffic actually was and they're kind of related, and so I can clump them in the same place. One is if you have IP address literals and protocol. Okay, I go back to FTP right, but typically that's the same location. It's not unusual to have some kind of protocol where the device asks the cloud.

D

Am I running the right piece of software and if the cloud says no, then the cloud gives it a URL to go, get the right piece of software and, if that URL, that it gives it is not in the mud file, because that was the whole point of asking the cloud is. They could now position it wherever they wanted to use whatever cloud resources they needed to make the upgrade work and then pass out whatever URLs they wanted.

D

Well, that's not in the mud file and therefore that off that access is not going to be authorized and another example is they have done that, but now they've specified, for instance, they may have said well: Amazon s3 buckets temp, typically have all the same name, so you said I'm going to an Amazon s3 bucket. Well now you can go to any any s3 bucket at all next slide, please.

D

So this document is about advice. Essentially, don't do this all right! Here's a list of things you shouldn't do: okay, in particular, you should always these names within your own own scope, so that you always have control in them. You should always use DNS, that's provided by the local DNS server so that you get the same geographic view of the rest of the thing and if you are going to have some kind of content distribution network then make sure that it answers with a round robin DNS type of things.

D

I think that's on the next slide.

D

Always answer with all of the quad a and a records that you're going to use and there's like the old way of doing this is with round robin was that they would just always rotate it such that the first IP address. That is the one that want you to use.

D

They would actually give you all the client all the rest of the IP addresses so that it could use them afterwards if it wanted to I, actually looked at figure out whether there was some BCP or some other document explained how to do this and goes back and I didn't really found a lot of IETF advice, and maybe there's some advice elsewhere on how to do this.

D

But if you look up Google, for instance or Facebook, they don't give you all the IP addresses for those they give you a few and you're expected to use that one and if you happen to come across or have cached a different one off right. So that's a big deal, and this is some advice that I think that we need to give to manufacturers such that when they are setting up their devices to use mud. They pick the right thing next slide.

D

Please and that's it, and so it's a BCP, don't really have a lot of of protocol parts. It would be more examples would be good, apparently, a DNS people, don't like the term caught X and didn't standardize it. So they don't know what we're gonna call that questions Elliott.

O

Michael I think it's pretty important, and actually just by way of how important it is, there's work going on it, I can shock is actually tied into that by the way. Okay, that is looking at Dinah's for IOT. So a couple of points to me, the first of which is I, really believe that this is not fundamental to mud, but is fundamental to IOT, that is to say it's bigger than mine.

O

The problem that you're hitting on, because even if you manually try to configure access lists without any Lud involved at all, you can still run into this problem if you cannot specify the met, if you, if you have no way to learn the mapping the fundamental issue here, that the policy enforcement wait for whether to decide whether the past packet or not the turn not well bound to the same resolution mechanism.

O

Now going back to one of the points that you've made, which is use, the DHCP provided, DNS server, I, think that's good short term advice, I'm, not sure it's the right, long term approach, and so some of the other work that's going on in the IETF. That has interested me along these lines and should interest you even more that somebody has gone to the effort to parameterize in yang all the DHCP options so yeah.

O

Now. What can you do with that? One of the things you can do with that is you can provide those DHCP options over a secure transport when you're, enrolling or after you're, enrolling and I'll lead you to think about that for just a little bit, but so so I would say this is an interesting work. I think it should become a BCP at some point and it could even we can even adopt it now, but I think it needs a little bit of work in terms of the advice so.

D

Tiro and some other people have been basically trying to make sure that it's possible to do dns over TLS or DNS over HTTPS, with the dhcp server with the cert dns servers that dhcp told you about, and I think that that is very much needs to be what IOT devices do, whether that's appropriate for your tablet? I would may have a different completely different view of that. But that's that's.

D

My view is that that IOT devices having no user interface need to use the local DNS and because that's the only way that the local operator gets control over or can protect them if they really want to do dns, firewalls and and therefore it's inappropriate for the devices to talk to the to the cloud for their DNS ever and I. Think that would I think if the document said only that that may be very controversial, but at least you'd be able to ask vendors.

D

Are you complying to RFC blah blah blah and they would say yes or no? You know that up front. As for the comment about DHCP yang options, that's an interesting way to make DHCP more more secure and that's interesting.

O

Looking at that, too, so they're curious how to set up please zero.

B

Sorry I was on mute, hey, hey Micah, thanks for the draft and I agree with most of the proposals that you haven't draft. So what we have been doing is we are using domain names for doing image filtering for IOT devices for enforcing word, so that seemed like a like right technique, especially because of Sirians and geolocation and G approximate issues. You could get different. Ip addresses the other one is using IOT, do not just format but I.

B

Think I would read you versus need to move to using do T or T over H, not just for policy enforcement, but also for security and privacy reasons. You don't want people to see what DNS queries it is making, because we have seen many IOT devices making DNS queries and you can pretty much figure out what that is doing. So. Privacy is a very important aspect for IOT devices and you don't want somebody to know whether you're talking to your LX and giving it command so just looking at DNS traffic.

B

It's pretty easy to do pervasive monitoring, so I think the bigger question for IOT devices used to discover and use a network provided duarte T, which servers and home networks and I guess we should start migrating to that and that way they get both security and privacy.

A

Very completely so, as I said, I'll do a call-out to the working group around all the mud, work and Michael you one more and if you could expedite that would be fantastic I'll go as quickly as possible. How.

D

Fast, can you hit the down arrow fast.

A

D

So device goes into quarantine because it violates its mud, its mud process ex, like.

D

During that quarantine, it needs to access the its updates. Okay and the device can't up site update itself. It may have be connected to critical things, and so, while it's in quarantine, because it's been it's behaved poorly, we don't know exactly why. Yet it may still need some network access, in particular at the minimum. It may need AK network access to the update server in order to be able to get the update.

D

If it's some other critical device and we're thinking like you know, ventilators, then maybe it needs access to the status console to update the fact that it's still running it's still working, although maybe it's done something that was maybe a bit wrong.

D

In particular early on in the mud, lifetime or life cycle, vendors are going to get mud, they're gonna, get things wrong, they're not know exactly what they do and they're gonna trip over and be quarantined unintentionally, and so we need to be able to basically continue on in some reduced access profile, and this essentially says which this mark switch access, control lists, which ackles are we enabled during quarantine in which ones are not? That's it and next slide. There's an example. Next slide next slide.

A

I think that's it him.

D

A

Think, that's it! That's it.

D

Questions not a new document, it's been around for at least a year hasn't changed much, there's not a lot to say, I, don't think in it. Some extensions are very long. I.

B

Mean this seems yeah I mean this seems obvious, and the right thing to do. I was wondering I mean why not let the device do its Internet activity in addition to the phone we're a place because, for example, for a home use case right, you don't want the device to stop completely functioning till the form where it happens. I'm.

D

Not saying it's only for firmware upgrading I'm saying and can mark any Akal as being essentially critical, and so you know if the device needs to do is something specific. You can significantly reduce its functionality when it's when it's been tripped.

A

Thank you very much. Michael.

A

Q

Yes, I can. Can you hear me.

A

Coming through loud and clear, Andrew gray, all yours perfect.

Q

And I will expedite this as best I can. So this is sampled streaming. We presented this at the last nigh ATF next slide, please just as a quick refresher. The problem we're trying to solve is essentially we as a service provider, we're seeing all these platforms with insanely high throughput scumming down the line. We have a number of devices presently that do various traffic captures and what have you, however, various vendors? What have you are informing us?

Q

It's going to be a struggle to maintain sampling rates and what have you that are going to be acceptable for our general use case. So what this draft is trying to do is make it so we can actually just have the forwarding Asics on the boxes. Um's do the sampling and sending the packets off box in a format that is extremely convenient to get to those 1486, because I can throw a ton of x86 computer or whatever I want to do to this traffic flow once I get it out of the box.

Q

In addition, that forwarding ASIC certainly has additional information. You know exact times of when the packets came in, especially if we combine this with PT P, which is something works by Manning with you know, getting very precise data as to when the packets started coming in on a second window is starting to leave that sort of thing. Let's actually skip all the way down to changes from o2, which is slide 8 we'll skip the rest of those.

Q

There we go so after the presentation at Singapore. We did have another follow-up meeting, which was we got a lot of good input on that we have done a few updates. We are using the ops AWG, get lamb or github for this work, so you can fight it up on there. There were some questions about what interfaces are available or subject. Some people mentioned there's a pretty good use case for doing subscriber interfaces.

Q

After talking about this, it's listed in the draft as an explicit option, but unfortunately it must be a may, because again, every Hardware every platform is going to be operating differently.

Q

So we didn't want to require that in there, and that might be probably should be a should, but that's one of the things that we're pondering about there were so a lot of questions about how this is different than peace amp, or this focuses primarily on getting the Met the metadata extraction out there with a negotiated packet, header and packet format that comes off the 14 ASIC and its primary driving focus is to keep the control plane of any specific router completely out of the packet flow and make it so the ASIC, and do it just as quick and as simply as it possibly can.

Q

There was a request to clarify the order of sampling requests. Basically, how do they get actually installed in terms of do Ackles occur before or after this one? We ended up having to split a little bit, because there is an option in site sample streaming for please sample the packets that you would normally discard, which has a number of interesting use. Cases that have been talked about. Basically verifying things like Ackles are working or you know, QoS, filter or QoS rate sampling is working.

Q

That sort of thing, so the draft is clarified that if there is sampling requested of prop packets, it must occur before any other sampling, and if there is no such mashing, it has to occur after the sampling, which seems to be the best compromise, but more than willing to take any additional feedback on that. One next slide: please requests from the working group the O 3 draft did get posted. However, we really could use a help or a co-author or somebody to come in and help with some of the yang model work.

Q

We did have some feedback to bring in peace, amp and some of the other in work. That's already been done for models. There is a little bit of overlap. We made a crack at it. It's not great, as of oh three so fully intending in oh four, but certainly went mind having another or a few extra sets of eyes on specifically the yang model in particular, and if any other people want to have any other kind of feedback about the draft in its entirety, and that is actually it for me any questions we.

A

R

D

So this is sort of fortuitous in the sense that one of the piece of work- it's not on our agenda at this time- is to restart the pcap ng work, and so I just wanted to say that maybe there's some good synergies here between this document and pcap ng, there's a bunch of different ways that I can imagine it, some of which may be not necessarily changing your wire format either. Thanks.

Q

Yes, so this draft is actually one of the tricks to. It is a pretty tight-knit, it's a dynamic wire format because it allow it's done that way to allow the box. That is actually saying the traffic say: hey you know this. You know my forwarding ASIC or whatever has this little bit of metadata. You know these ten bits or twelve bits or four bytes or whatever it ends up being in the header. I can send that off to you.

Q

Here's the format, the encoding of that or the how that format is described, is actually flexible enough that you can actually I think I actually have it in there. It draft. As an example, I say: here's pcap, mgs4 or pcaps format. You know.

D

The other way, PK angie, could actually standardize all of the different captures from the different Asics that you may imagine as well. So you could write it to a file in that format and have it stamped as being that format. I then open it natively for coming from where it's coming from your chip.

Q

That's actually yeah, that's actually. Okay, yeah I'll have to take a look at it. We've been using a variety of little snow based tools to try and be code tinker with this here locally, but yeah that would be yeah. That's a good suggestion. Okay, I'll, take a look I.

C

Can have this similar question and suggestion as Michael and I think eventually you wanna export the raw packet with some metadata. So why not extend some existing protocols like IP fix a stuff exporting channel or I, see some existing spam protocols? Like yes, Barry.

Q

Yeah so again, the because the primary reason behind this is this is intended for a routing ASIC to do. We need to be able to allow it to be as simple or as relatively complex as those ASIS can handle. You know the newest Asics from Cisco, or whoever else can do some fairly complicated things. You know if we're talking lower in hardware, you know you may just get the raw packet and basically nothing else, no metadata at all. So having the flexibility to be able to carry that metadata and get it off the box.

Q

It is intended that this gets sent to a collector box that takes that metadata. Then hashes it or ant well, hashes, a bad word then reworks it into another format, then to be sent on or be a collector in and of itself. So this is just to get it off off the box as quick and easily as possible, without needing to involve the control plane without needing to involve any additional overhead on the Box I.

C

Did not really implement all this protocols, but it seems the IP fix could be implemented. Also in a Sequoia hardware and and I see, the spam protocol is to monitor to mirror the interface, so it should be very fast. I think.

Q

Yeah, so we we talk about this a little bit in the draft as to why it's not a great fit in terms of our span and your span. Those are also fixed protocol, so we may be able to get the data we want. We may not be able to get the data off and they have to involve a variety of packet, reordering and rewriting of headers and what-have-you, which is all of which we're trying to avoid.

Q

In that that's kind of the route of this I'll take another look at the are span yourse'f and stuff and see if there's a way to do it, but having the ability to specify the packet format off. The box is kind of the key bit to this.

Q

So anything that tries to put wrappers around that is going to be against what we're trying to do and potentially makes it so less capable Asics cannot do it and that's the other part of us is yes top tier Asics can do a lot of really amazing things with the packets going out of them, but we don't have those everywhere, at least in our network, and can't really afford that. So we need something that even the most basic case it could go. Hey you know, I I can only give you.

Q

You know eight bits to tell you what portney came in, but at least here's the packet and that's all I can do. Okay, that's the main concern with us. I.

A

Have a chair question, but I'll, let Frank jump jump ahead of me thanks.

E

Joe one quick one and I I think I asked that question similar format, analysis.

E

We heard so far and Ryan I think it would make sense to include an IP fix example. So you have suggested packet formats in Section. Four would be I, think useful for all the IP fix minded audience with similar example with logics defined fields and because the Delta between what you have in the example and what he could go and do with he.

N

E

Is relatively small and I think that's what so, what what general was was ending, add so I think that example would help everybody understand things much more than rather than raising the the obvious question over and over again, so in that little section would probably help readability and understanding.

E

Question all the time yeah.

Q

All right I'll make a note to put that in there and then the other part that came out that same conversation, I think you and I had at Singapore about pulling in some of the IP fix fields for doing the on the negotiation. To say: hey, you know: here's the different formats and whatever we did pull some of that into the yang models. That's also part of the other thing week. I need to go back through the yang models to clean that up a little bit for a no for draft.

A

Q

A

Real quick is your looked at the Deloitte latest model. Is it a place where you wouldn't mind any expert getting doctor review? Are you really just looking for a co-author to shore it up? First.

Q

I think actually were we're kind of in a coma. An Ohio State with a young doctor, I think I.

Q

Let me get a no for kicked out first before the yang doctor review, just because there are a few things in there that I do want to have enough time to go back through, but I think at that point. Yeah having a young doctor review would be very beneficial because a lot of this is wrapped up in the gang model, and most of it is in pretty good shape. There's just one or two rough point, so I will write that I know about that. I want to clean up before we do that.

A

Much thank you.

A

Can you hear us I can.

P

Hear you can hear me, we.

A

Can take it okay,.

P

Next slide, please.

P

This ITF 106 restarts adoption call for this draft and we received a lot of comments of suggestions and critics from numerous reviewers we'd like to give special thanks to Frank, Allen, Warren, Alex and Daniel.

P

Maybe we missed some names here um based on the air feedbacks. We have updates these drafts for multiple versions.

P

Now it's already 11 and in this revisions we made some significant, significant, modified patience on the content and first we clarify the scope and also the relationship of this document with some other documents, and also we just highlight high-level framework and remove man helps unnecessary terms to keep it at checked and also we modify the framework by removing the encapsulation and the tunneling module from them from the framework itself, because we think that's more on the interface and the standard side notes the.

P

Why integral part of the framework itself- and we also had a lot of block diagrams and detailed descriptions for each this team framework module and we enhanced the standard status and gap analysis. And finally, we also update the style of the writing to remove some of some marketing some terms. Next.

P

Next, ok, so, first of all we are considered. The focus of this framework is actually on a special type of date, printed energy technologies. We categorize that as a hybrid type of the data plane OAM and the folder, we can partition this retyped to two subtypes. One of them is named passport type. Another is a postcard type. We already seen a lot of examples: sample techniques in IDF for each of these subtypes, so next class.

P

Okay, so pizza how we will apply this type of techniques on the it networks, especially for the carrier and networks we come up. Is this abstract framework, and now it contains contains four key components covering the techniques, selection and flow package, selection and data selection, and how we will output support data and how we were generates the data so for each components we provide a detailed description and what what modules we can be used to contribute to that specific components.

P

P

So why do you have this document so because this is only document now we cover a new type of data, plane, telemetry techniques, from the high-level view.

P

We also put it in the perspective of the entire network slam tree framework, and in this document he summarized some deployment requirements and the challenges, especially in carrier networks and this high-level architecture. Our framework also aim to address some of the key challenges and it helped to identify gaps and give the directions for related standard development, but.

F

P

Talk mainly, we will not cover any standardization of underlying techniques and interfaces that will be covered by individual individual drafts. Next slice.

P

To summarize some a contribution of this draft Lisa V first summarize and clarify a new type of techniques and provide the challenges and requirements for deployment.

P

We gave a high-level framework and the application example and the finally we gave it a standard status and yep analysis, so we'd like to ask all our reviewers to give it another run of review of this document and the providers of feedback to see if your questions or has been answered or if you have any other concerns or suggestions to improve, improving this document and the based on the feedback we'd like to ask for the working group adoption for this. Thank you very much.

A

Frank ICU and NICU Frank partners.

E

Yeah, thanks for the update and I, appreciate the effort to actually reflect some of the comments we gave. You unfortunately, I think I have to say that not sure where the way moving forward or we were rather moving back. What's on the document, yes, I.

O

E

Of the issues that we identified or still there right, so you still have a lot of terms that you define and these terms are unclear of what to do with them. So I think you went from I fit.

D

Had notes to now at.

E

Notes, you went from I fit endnotes to endnotes, but those are still you had I fit notes. Now there are called capable notes, capable notice right and you still have Huawei marketing language in there like I fit. Even if that's the name and you have things like slow, smart flow, telemetry or smart data export even at that only I think it was slot. It's like three, so many of the comments that we gave or not even reflect it so far, so not sure whether we're actually making progress on the rock.

P

Yeah I would see some of the terms like the Hat node and end node as easily understand because I said just used. His wives was in the scope of this a faith-based and network, and so I I can't add some more descriptions on that. But I, don't think it'll make me more clearer because I think he said it's really easy to understand and for some other terms, I I can maybe yeah.

P

We can think so offer to modify the how we call that and we can use some more neutral terms, but yeah I think that that's that's doable.

A

I

Okay, I have question for the franca. Why do you think I feel I belong too far away from our point of view, because this is the new flow. This is the monetary I think we need a framework cleaner, but we at the beginning. We do not have this the appropriate to me so that we use the affinity, but when we does the probe holders, we reuse the name in the forest solution, but I don't think that I fit a. You know how I surprised with the name, because they see the technical terminology.

E

Call it something else right, give it a new name that results the the overall so either call it wildlife it and make it.

I

E

Think that that's that's the problem that you have throughout the document, your your solving to really find a load of technology that is already defined in other places and I.

D

Can give you more.

P

E

On that but I think let's take that off to the list. I think that's much easier.

P

Friend friend yeah I'd like to clarify this: no, we try to highlight a new type of techniques. That's neutral, no terms for this. That's why we come up with this term right, it's very clear to show in the first slice how we categorize this technique and give it a name, and if we have a new framework, you have to give it a name.

P

That's neutral! Well,.

E

I would disagree right if it supports two basic on top telemetry modes passport mode, which is direct reference to I am tracing and another mode that is called postcard mode, which is reference to a now deferred and no longer for evolve document in I ppm, which is the same functionality as IOM direct export. So I think. Why do we need to go and even redefine a new name for.

D

E

Have a name for that: it's an in situ, om, I! Think it's well established understanding why we need to find a raft of new technology.

D

Terminology that.

P

E

Everybody without adding any value so I.

P

Don't think there's a confusion if you look at slices yeah there's some I went techniques covered by this two type of subtypes, but there are also other type of techniques. It's all on the data plane of the telemetry and there's no name cover that and besides that's the imposter MK. The name of the technique itself, but I fit is a name of the framework differently.

P

A

Would agree this we're not going to solve this here and we do need to move on and I agree with taking this conversation to the list. It's probably the best thing, there's clearly some issues to sort out and all of this can write anything quickly.

A

Yes, no general.

C

um I think we need to foster a talk worried on the scope in the mailing list, and here I would like to add some clarification about this work. It seems it's not just a classification of the the data brand knowledge assay. It's a more about the high-level framework for how to ox trade different, a technologist.

A

Let's take the conversation there we're not going to solve this on points on this call and while I notice you're here, you asked me if I could present but you're here. Do you want to present this.

A

Ok, he's still on mute, so I'm gonna in the interest of time, benoit's asked me to present on his behalf. I hope you feel better soon Benoit. This was presented services Oh.

A

The service assurance for intent-based networking was presented at ITF 106. This is an update, just as a summary. The in the purpose of this work is to be able to say that, given a service, let's say a VPN service confirmed that ok, it may be configured, but is it operating correctly and when it's not operating correctly, can we identify where in the service hierarchy and the whole end-to-end service, that problem is happening? The idea here being, is, it says, closed loop, automation on the slide.

A

The point is it's a way of saying: if I'm going to be monitoring, something I need to make quick corrective changes to the network based on what I'm monitoring can I do that can I have enough atomic insight into what's happening with the service to be able to make those changes.

A

The goal of this work is to provide that to provide a way of decomposing the complex service into these smaller parts, so that we can measure their health- and we could say this part of the service and what we call sub service is working correctly or not, and then we can float that or surface that up, so that we're able to make decisions based on that look at the overall health of the thermos decide if it's degraded or not, and the drill in to figure out where, where the the root Clause might be.

A

Ultimately, this is complement to and in synthetic testing, unlike being able to do probes over top of a service to ensure that it is functioning correctly. This complements that to be able to again figure out where, in that service there might be a problem. So here's a graphical depiction of that you might have a tunnel. So the thing that you you sell the thing that you care about and that gets decomposed or there's instances of that.

A

So you might have n number of customers doing it with that generic quote-unquote tunnel service there's multiple instances and within each of those instances there are multiple sub services that independently need to be monitored and also need to. They have relations with themselves. So we need to understand how the sub services relate to each other, so that we can understand from a cascade standpoint where something is failing and what impact that could have to other parts of the of the services or other parts of the service instance or the service as a whole.

A

So we have from the bottom up. We have these impacting dependencies and we might also have informational dependencies with things that are related to the service, but not directly in the critical path like, for example, ecmp. We could lose a leg, for example, and still have the service operating correctly, but it still might be degraded because that service not as redundant or not as highly available as it could be.

A

So what we want to know when a service degrades? What is the root cause? What is that sub service? That is having the problem and what is it that one sub service could be shared across multiple instances? So what is the overall impact to the network or to the services that we're offering as a whole? The definition here- and this is Benoit- has running and working code working with some operators as well on this. The architecture defined is both flexible and limited in scope. So what this work?

A

Fines is interfaces between some of these components, how the internals of these components are architected. Those are implementation. Those are explicitly left out of scope, but the scope is: how do we convey the service kind of definition? How we break down the sub services back part is also extensible and then the kind of the information we're getting so you can see this is the architecture, there's questions that could be answered. Based on how one wants to implement this. Some of these things might be implemented on box.

A

Some of these things might be implemented, distributed lis distributed throughout the network. Some of these things could be implemented within the device within the control management plane of the device itself. The interfaces are being defined here. That's the the work that Benoit is put forth as yang models. However, like I mentioned, the internal architecture of the same work is for this assurance for intent, based networking that the name they've come up with. That is out of scope. That is not that is left to implementation decisions. So you could see some of the the tree.

A

That's defined, how they define a dependency relationship between a service and sub services that require it, and then you see how those things are scored in terms of a health score that you can say: okay, either this thing is fully dead. It is degraded, it is fully healthy.

A

So then, based on that and weighing that and measuring that across all the sub services, you can determine the focus what services are truly degraded, where you need to focus your root, cause analysis, work or that close loop, where, where your action in that close loop can can take effect in terms of changes between what was presented at 1:06, there was a notion that there needed to be the idea of reflecting and maintenance window, and so they added being a boolean to say whether or not a service, some services under maintenance and and who is the content maintenance work.

A

There's also, as I mentioned, the ability to extend the extend the model extend the architecture to allow for new sub service types, even vendor specific sub service types. That makes you additional parameters that need to be specified, so the the model and the the way it's defined allows for that extensibility, ultimately and again, I'm presenting by proxy Benoit wants to know. Is this and yes, this last time? Is this valid problem for the industry to solve and there was some feedback on list suggestions about direction as well as perhaps this is a valid problem?

A

Is it a valid problem to solve at the IETF and if so, are they going in the right direction and we can, as I mentioned three can't do hums or anything here we can. We can take this additional request up on the list, but I do see. There are some questions in queue and I think sue hares has the first one I'll do my best to answer by proxy.

A

K

A simple one listed eius eius as a tunnel protocol in your slide- and I don't know- is that something that's part of the definition or if it's part of the main focus there is still.

K

Bgp track tag tunnels is that something that's going to be part of this as well, so.

A

This is this is an example of a service, and, in this particular instance, they're. The routing protocol for examples is, is there the the underlaw routing protocol could be very different from this. As you decompose a service, you might find that it's PGP or OSPF. This was just an example to say in this particular case. This is a graphical depiction of how a service might be broken down to its underlying sub services.

K

So in this graphical example, you gave is is as an example, you could give. Bgp is an example. This is a part of the specification which is not part of the main, but part of things that could be defined. Did I understand what you just said. Correct.

A

Part of this, but it is not part of the specification it in and of itself. These are types of sub services that are fairly generic. As you can see, you could specify the type of sub service, but there's nothing eius, eius, specific or BGP specific in here. This is designed to be flexible in my understanding to accommodate whatever the routing protocol might be for a given overall service. Thank.

K

A

Warren we'll see you in the queue as well.

A

Okay, Warren, we can't hear you so bless you in as I move my mouse to end this presentation you come in. We will move on to our last presentation, which is Joey.

C

Okay, that's continue.

A

Q

C

Q

R

R

Okay, so this presentation is regarding some, you yang data models for IP, fix, piece, amp and bulk data export, as mentioned, this is started as an ad sponsored draft and we'll go through some of the summary of where, where we are in C, where we might want to go so next slide, please.

R

Little intro in the broadband access market we have requirements for using IP fix for transporting bulk data. Bulk data collection in this sense is an automated collection of data from a device it's packaged together and deliver to an IP fix collector. It goes beyond packet sampling, for example, it can cool, include statistics for interfaces, sub interfaces commonly performance monitoring. Things like that.

R

There's also requirements for using IP fix and broadband forum for transporting, for example, in TR 350 to inter channel transport protocol, uses IP fix to transport dynamic data, for example, lease information across participating in G pond two systems next slide. Please.

R

We analyzed the existing IP fix piece ant model that was defined in RFC 67 28. We noted that it's a single yang module that performs I he Sam operations, the collection process from piece amp and the IP fix exporting process are all combined in the same module.

R

It only supports a piece centimeter as some assumptions that the device supports SCTP and so using this model was going to be a little challenging for the other applications such as the TR 352 I CTP noted that RFC 51 53 requires support for SCS CTP 4-piece app, so the model was written so that there was no specific feature define for setp to make it explicitly optional for TR 352. It only support for TCP and TLS.

R

The 67 28 model requires piece amp meter to be configured even if the observation points already defined by other game models. There are also some other general challenges. The draft has a few more, he spelled out, but one of the first ones we noted was interface references or through AF bit. I have index rather than using ITF interface references the same on the hardware side using physical entity indexes instead of using Hardware component references. Of course those didn't exist when this draft was written, so that's understandable.

R

So our conclusion was trying to augment and in some cases, deviate the existing 67 28 model to support and not only BBF requirements, but general broadband access requirements was going to be challenging. So we decided to go down a path of a new yang model where functionality is separated into different modules, so the functions can be independently leveraged.

R

R

Our new model, you know we're hearing to the general principles defined in sixty seven, twenty eight, with some some exceptions. We went ahead and adopt to conform to the latest RFC 80, 407 yen guidelines, for example identifier naming conventions, and so that makes this not backward compatible with the previous. There. Other reasons we'll talk about. We added support for RFC 83, 40, 383, 48, 4 interface and hard we're references respectively.

R

We broke the model up into three modules: ietf IP fix defines the IP fix, collector and exporter functions. Itf peace app defines the p-set functions for configuring device to sample meter a subset of packets from the network in IETF bulk data export, which defines the bulk data IP, fixed templates and filtering functions to apply to bulk data. This is outside the the P set VP data nodes and remained explicitly optional with an sctp feature that way. Application is not required to support. Sctp can advertise as such.

R

Ip, fixed transport sessions allow the session information to be retrieved individually before it was just a keyless list when you have applications such as ng pond 2, which may have a large number of transport sessions being able to hold one individually. It is an advantage we done some refactoring and mate things like source and destination address type, so it made them choice statements so that we can have extensibility in the model as future applications come in.

R

The idea once you have this is that applications using this would be expected only to use an applicable yang model. So if you have a piece app application, you only need the IP fix and P SAP modules. If you have data you need IP fix and bulk data export for TR 352, ICT P. You only need the IETF IP fix module.

R

R

Question we're here asking is: should this move forward, we've gotten previously, we've gotten through the process, far enough, that we've had a yang doctor review with favorable feedback and we've addressed the issues identified. There are other review comments from other ABS and those on the last call review and we've addressed those except for, and the reason we're here today is the obsolete of RFC 67 28. Of course, we chose not to augment it to support these new requirements.

R

New models designed to be flexible, its adhering to the latest young recommendations, covers peace, existing peace, Sam use case, as well as new bulk data use cases, and so, for this reason we, the new model, was recommending obsolete an of 67 28, but there are other options that I'll talk about in a second, and so should the my document move forward in its present state. If the obsolete in path is acceptable, can we continue forward with it?

R

Otherwise another option would be to rewrite the draft to define the new models as described, and we would only did reference 67 28 were applicable, describe the new functionality and I believe when we were. We were going through this. We found a few places in 67 28, where some of the process descriptions missing some some information. So we could use this as an opportunity to fill in those gaps with.

L

R

Time, that's the end of my presentation.

A

So just putting it out the one of the reasons that we brought this here was. It was ad sponsored and we wanted more eyes because of the obsolete, obsolete path. We wanted more eyes on this I, don't know how many on this call that a chance to read it any warrants back in queue so Warren.

A

N

Can hear you now.

N

This wasn't good.

A

When he ad sponsored.

N

I took it over and I think it should either belong in the opposite of eg working group or possibly Rob and take it over, but I was mainly just holding it as an interim measure. The change is anything.

H

So my preference would be this stage of this to go through the ops, AWG working sufficient support.

H

D

Eisen is definitely.

H

Good thing to do I.

A

Agree I mean that were a warrant back to you.

A

Cannot hear you Warren what you did last time? Yes,.

N

Now, weird just saying that if it does go through opps AWG, possibly we can expedite it, um but you know obsoleting a document seems like it should be a working group action if possible. The document from my reading seems not crazy, and so, if it does go to offset a breach, it should be relatively quickly. I think, but that's just from an initial read: I.

A

Would agree, I think it should go through opps, aw and and well well, submit it out there to the working group to see if there is interest in adopting than moving this forward and like Joey presented, it's got a lot of reviews already. A lot of comments have been addressed and the authors feel that it's in good shape so we'll put that out there for working group.

A

Other comments.

C

Or questions on this.

A

C

Is this idea sponsored the document or it's going to be adopted by up cytology.

A

Currently, it's ad sponsored, it was ad sponsored by Ignace. It went through some Directorate reviews and there was a comment that it probably needs more eyes on from people who are from peace and former peace amp that that could give more of a technical once-over on this. And then there was the question of this obsolescence, which is worn pointed out, is probably something that shouldn't just be ad sponsored, but should go through some working group to telogen s--. So right now, it's it's with warrant I. Just.

C

Deal with a disposer so.

A

It's still with Warren right now, as what Warren said, but Rob is going to be the new person and we can put it up to see if the work group once it or if it's going to continue on the ad route. I think that's the that's happened here.

H

Yes, just echo what Jose said here, furtively that I think that if we can get to go through the working I think that's the best choice. I do think that this work is sensible and I. Don't sort of have any fundamental issue with obsoleting 67 28 I'm, not that familiar with it, but I do see that we want to get young models right and he's okay over time, if they're not being quite right, so the early ones to actually update them fix them. So I think that's all fine.

H

If we can get this through the work you'd get extra eyes on it. That would be great. If that's not an option all that some work, then we then I can tell you look at ad sponsoring it, but if we can get this through the working group, that's definitely my preferred choice and I. Don't see any reason why that has to necessarily be a long process. I think we could potentially move fairly quickly. So I'm not saying cease go back to scratch, but just that it through the working group.

A

Questions or comments.

A

All right she and Thomas I'm. Sorry: we've eaten well into the. We only got 10 minutes left for hops area so I hand it over to first I'll say that if op stereo wants to defer any time they can, but if not, she and Thomas. You have first dibs four slots in ITF 108 a for ops area working group and with that I will hand it over to you Robin Warren, for your remaining sort of eleven nine minutes. Okay,.

N

Listen, thank you. Hopefully, my audio is working so first off thanks everyone and welcome to the ops area, part of the joint op C WGN ops area, I'd like to first start off by thanking Ignace for his service and also say, I'm really excited to have Rob Wilton, serving as our new ops and management ad I'm sure everyone will make him feel, welcome and Rob for those who don't already know you I guess, could you take a minute or two and introduce yourself.

N

H

So for those that don't know me, I've been not been participating in ITF for that long, so it might be possible to some you, don't I'm spent over 20 years working for Cisco more easily directly in before indirectly as a software engineer in their service provider business unit. So my background he's on the service provider OS across multiple platforms and things predominately and my early years was on layer, 2 technologies, VLANs and Ethernet, but even the matter time been working for Cisco and service provider.

H

I have quite a wide background knowledge across service provider, OS software stack there have been focused on manageability issues and yang, particularly in ITF and general system issues as well in terms of the ITF stuff I've been country to you for about last five years or so focusing predominately on yang and their related protocols.

H

The nmda architecture was, one of the things was heavily of the more recently the young versioning work solve where I see is a management ad going in the stuff I see most interested in is I'd like to try and see ITIF finish device that will young old I think that would be good. I have particular interest in the sort of service and network young models and how those mapped down to the device of all the yang models.

H

I also have been interested in understanding what the relationship between say, the service level, yang modules or service level models being produced by like any F and how they map on to and device models and network y models. I also have an interest in the lifecycle, monitoring and automation again, so all the stuff to do with actually monitoring how these networks are running and be able to up to find issue to fix them again.

H

I have a keen interest in that area, so that sort of summarizes my background fairly simply and the stuff that I'm I have at the moment, particularly interesting. Next.

N

Well, thank you, so I think that this officially takes us into the ops area open mic time and if we don't have any, we might be able to get if the few minutes back to ops, AVG and Russia if they can fit another presentation and or not really in the last five minutes, anyone have open mic questions for us.

N

Look like it so, of course, people can always email off stash, 80s and IETF to dog. If you want to reach us and Joe I'm, not sure if you'd like to try and fit another presentation in the last six minutes or there isn't really time, we.

A

Slotted GL I'll leave it to you your first in the queue can you finish in five.

A

Ji-Yong, can you hear us, you didn't.

B

A

Maybe it's it's best. We we adjourn here and she you can be first, like I, said: you'll have first dibs that had a crack in 108, followed by Tom Graff, who also submitted after the line they've been cut so I think one. If you want to close us, okay, we can catch back up, hopefully in Madrid. Thank you very.

N

Much everyone thank you for showing up and I know the times were difficult for some sort of people. Thank you for staying up late or getting up early, and we will see you all at the next one of these. Thank you very much. Okay,.