Internet Engineering Task Force 103, 5 Nov 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF103-RTGWG-20181105-1610

Description

RTGWG meeting session at IETF103
2018/11/05 1610

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

A

Guys, please be seated, we are about to start, you can stand up.

A

Good afternoon, everybody welcome to first meeting prowl a working group in Bangkok we're going to start with status updates.

A

You should have read not well and know. What's inside and what's she doing, you know our our disclosure will ask IPR when we adopt document to the last IPR when we lost all document. If not, everybody has responded to a PR document. It's not progress until they receive all the responses. Please remember engine. Thank you for taking notes. We are looking for somewhere in jabber.

A

Thank you drew appreciated, please sign the blue sheets and let's review the agenda busy day today, not going to read it a lot of stuff.

A

Law, could you please close the door.

A

Thank you so no documents published for this ATF I'm, looking at our ad.

A

Significant number of documents had been submitted to is G. The yonk models are still awaiting normative. Reference. I was told it's finally progressing. So by next idea we should see an IME model adopted.

A

So we are potentially looking for a new Shepard first document, because the previous one promised to do this for the last for eight years. If you are interested, please let us know would be really great.

A

We've got for existing working group documents that are that were adopted before last idea: policy model, ERP, BFD, the snare start, routing and time and parameter singing.

A

We have adopted three new draft since last ATF our tank model, Etienne BGP and drop it here, seven routing PLA. You really appreciate. If outer finally publish the ITF dropped, it still shows up as personal draft and I think we are ready.

A

B

Hello: everyone, my name, is engine I'm here to do two updates on data models, so the first one is Rypien data model. We actually started working on this model three years ago, so I thought ham. This was a this was an augmentation of the routing config model. So some of the attributes that was originally defined in this model was mood to or mood to, the routing config model, for example like the ecmp staff, the multi half support.

B

So then that jogging config model it was published as RFC 1822 and then with an MVA. We updated that one to 83 49 so with all Austin I think now it's time to give some priority to this model and then progress this one cuz they, the rig stuff, is still important for routing. So let's look at some detail stuff in the define in this model. The riptides preference repair path.

B

So this one shows how the next hop is: augmented, with preference, the routing preference, how you later decide which path to choose and then tag an application tag. We think lows are critical stuff and those are not defined in the base class.

B

In critique model, so um so this one has to be so this one has the ipv4 dots, that's the single pass and they all have a CMP multi-hop and that's the least active a 6-part. They are pretty much the same thing so on this one has repair path and then some other rape statistics local on how many like for protocol wise, which protocol country muted with dots.

B

So that's the detail, stuff, you can take a look and if you please provide us any comments you have and one thing I want to mention. Is we got good comments from compacts I, not sure whether pronounce his last name correct so, but he provides a lot of good feedback and, for example, we change our prefix name from rape in into a rape extension. So we think that's more appropriate, because this one is really an extension to the base model.

B

This one is a very simple, straightforward one so but we'd like to progress it, and we want to collect more comments and then request working group adoption, because we think we now have time to really working on ID move. It forward.

A

How many people have read the trust yours out would be great if more people read it and provide some comments. Yeah.

B

So um please read it.

B

Okay, so this one is the routing policy model. This one is the one we really want to progress it fast this, because the policy serves as the centerpiece of all routing protocols and so since last ITF, what we have done, nothing major. We made a lot of editorial changes based on our experience, working on data models. What we have collected from the feedback from other models, lalala site Oreo changes, including the right references.

B

We made all those changes, and so the real changes only this, so we maybe I suggested by Jeff house last time, so we change the type to bigger size, those other real changes, pretty much. That's it and please, please, read this document because we want to Lascaux it pretty soon. That's it any questions regarding this one. If you care about routing policy all because this one is, we really need it in order to make the whole ITF routing young models, weak work.

C

A selenium, Cisco, Systems I got a comment offline from care. He wants us to encapsulate the list in container, see you can get them with a single get for all the you know like, for instance, for a prefix list yeah, so that you, you wouldn't have to iterate to get it every entry in the prefix list. Okay,.

B

That I think we can do right after they say ETF. That's a simple I think we did that for OSPF. Also right, yeah now cuz this one walk. The orange we took over from open config a lot of stuff was not really IBF status stale. So we tried our best to make them more consistent with other models.

B

A

There's question.

D

Channeling sue, Harris and suddenly my this thing is opening okay.

E

D

Right, please ask why they plan to when they plan, when they plan to working with blast, call also. She gives +1 to the last point to Carol's point. So she wants to know when, when is the working group last call going to be done?.

F

C

Thank you. A selenium, Cisco, Systems and I would say that it will be done well before the BGP model, of which she's a she's. The editor.

A

Juxta site I mean if anyone plans to do any idea, routing data models. We need policies. So please read it. Please look it up. We try to keep it as close as we could to initial up and configure on but adapt to ITF. It's been significant amount of work and it's important.

G

Next up is why mo Chen.

G

Slight technical difficulty with the Chromebook here.

D

D

While the chairs are sorting that out, AC I'm holding the BGP model based on this draft, so I'm responding to a see you guys now, Tom directly, keep me out.

H

Yeah yeah, that's one.

H

H

Hello: everyone today I'm going to talk about architecture for a use of PGP as a central controller.

H

H

Yet our go-to back go back. This is the second second place. I'll get it okay,.

H

Yeah we just go this way, so in fact, PGP as a call for light, walk, has lots of functions as a lot of capabilities, so, for example, PGP distributed link states so also TPP can distribute the second second segment ID information.

H

So these both in so because of this one PGP, will maintain a traffic engineer database and also it'll retain a database for second ID and labels. So PGE can control the redirection or for traffic flows. So this is a defined by from spec, so PGP can contribute and MPLS labels and also PGP, has a lot of flack reflected function, function, energies with this kind of function, at least, and then wrote a reflector. We can have a connection from raw deflector to every node in the metal which rank pgps.

H

So is this kind of functions and capabilities, so it's a very simple to extend PGP as a central controller, and also it later to extend PGP as a senior controller and also is the very beneficial to intended intended PGP as a sender controllers. So if we use just F have a some kind of symbol extension to make a big P as a sender controller, this well simplify the network of operations and also we have very efficient way. We can use that one which was very freaky occasionally next, one.

H

So this night we just talked about a beauty, blog basic building block for a central controller. So we should have a traffic engineer database, so this database, where stores and maintains trafficking information. So we should have a database which maintains the signal ID information for each node, each interface and maybe some kind of prefix. We should also have a database which maintains the information about mikanos.

H

So these are information for tunnel will include the parts for the panel and then the parameters configured by the users for the panel and also if we- because what are nowhere, we need to compute the optimal paths which satisfies constraints for panel. So those are paths will compute it of our tunnel will be stored in the tunnel and a passive database, and also after we convert a pass. We either reserved the resource for the tunnel, for example, or for ambulance tunnel.

H

We need a reserved bandwidth and we need maybe reserved the labels for segment tunnel for segment all internal. We need a locate segment IDs for that tunnels, so those three kind of a database we needed half for the segment for the central controller.

H

Here this will death, so we may have a CSP to come with compare paths for the tunnel and then we may have another, a beautiful lock, which is a tunnel management, so terminal module will receive the request from operator or applications for the surface, and then we were created of the initial resource and then we are about reserve the resource, and then we will set up the tunnels management. So next slide: okay, good!

H

Yes, yes, yes, so which those building blocks and then we can have us some kind of basic reference, architectures water controllers. So firstly, we just talk about a basic one controller, it's a new controller and then we come up with a controller cluster and then hierarchical controllers.

H

So for one controller we we can have a just to have. Someone can relatively simple extensions to pgps, for example. Here so for PGP. We already have our rotary reflector, so railroad reflector allow us to connect ronald replicas to every node in the network, which means bgp.

H

In addition to that so use these kind of connections. We can get the initial information traffic engineer, information about the network using existing communication channels through the database also for the second row. Second ID information, because right now we already have it also a kind of a drop or is a tokamak, so use it, those icky tensions. We can also get a second ID information to the segment I, a second ID database, so these are mojo, is the internal in a controller.

H

So with those kind of models we will talk about it, such as a tournament agreement and the sales clear and those modules we'll talk about, and then we can come up with a basic one, PD controller. So with this controller and then for example, customer we can receive a request, user and applications and as soon as we get those requests and then request the for Cano and then using that Career Service. So with those requests, and then we can ask a state's p.m.

H

to computer orbit impasse which satisfy some constraint and then since we're well well access the traffic and you database to get that pass. And then, after that, the pass after we have in that pass. And then we can reserve the resource for that eternal. And then we can gather if we use a second segment internal and then we can allocate that those are segment IDs for that panel. And then we can store those information in the plan on the path database.

H

For that eternal such as pass and then the resource will be reserved and after we store those information and then we can use a user communication channel to set up the panel users. The segment route in Hana was mmm MPLS nanos. So that's the basic basic PGP controller. So, as we know, the whole battle is controlled by this controller and then their reliability is that, if very critical to customers. So in this case we may have, we should have carnival redundancies controllers. So.

H

So that, while solution for that redundancy, you all reliability is that we can have control controller clusters. So the simple cluster is that we have two two controllers: why is the active one more primary one? The second one is a standby one, so those two controllers work together, so from user from view that just one controller from inside the form you the true over together the synchronize, the space and synchronize, those are control, States and then, as soon as the one is done without primaries. Is that and then the standby one will take over?

H

So in this way we can achieve a higher reliability.

H

So in generally, we in general case we can have a control cluster which contains a lambo for controllers like a primary controller secondary third and then the ends of controllers. These else controllers work together and then from all sides, purview, that's just as a laden controllers and the rest as evil. One type was n minus one died, and then we still have one knife and then we still can manage it to control the level work.

H

So the server architecture is, we can have a hierarchical controllers. So, in this a hierarchical architecture, we have a power in controller or called a super controller. So under gives us a super controller. We have a map of a child controller. For example. In this case we have a child controllers. These are a parent controller, were controlled, these n child controllers and then some of a child controllers may still as a parody controller, for example, this one child concern it so, additionally, the child controller.

H

It's also a parent controller, which controls this number of child controllers. We can have a hierarchy of controllers, so a user controller may contain they control one of the domains. So in this architecture, and then the super control of a parent controller will exact where we accept or receive the requests from customers or applications, and then this powerful controller we all split at the work and then, for example, if we would like to have a end to end the panel, these kind of work carried a surface for some customers.

H

The super controller will manage it to control the pass control pass. Ask her some of it's a child controllers and then, after super controller get it ended to end the past, and then you can manage it to some of his child controllers to set up the pass and then, in the end we have to pass and then use this and in the past you can carry customer service. So this is the rocky Cole controller architecture.

H

Yeah, that's a roughly about the PGP as a sanyo come as a new controller, so we would like to comments from people here.

G

So this is uh Chris Bowers here I have a question about when I first looked at this I thought based on the title that it would be.

G

You know, BGP srte to as the mechanism for controlling for instantiating paths, but it doesn't seem to be the case. Sigma.

H

T Sigma, or to the sub case here well I'm here with because here with this is the general architecture and we, this general architecture, can have the function for set for a thermoset, hopper ii and the routing panels right here. We, for example, here in this.

H

So in this building block we have a segment ID and a label database and then with visual information. So we can create a segment route. The signal routing Tejanos, for example. We can have a request with we can from source to pagination. We would like to have traffic alert stagnant route in tunnel so because PGP, you already have for traffic linear information. In addition to that, we also have a signal routed, a segment ID information.

H

So first we can compute a tunnel satisfies constraints such as T constraints and then after we have that pass, and then we can allocate that, though, the still Merle segment that IDs, for example, if we use digest e signal to those IDs right, so we can, along those pass each each link each each interface. We can allocate as adjacencies s ID and then with those IDs, and then we can send those information acts. Age is an ID.

H

Id is neji's an ID along the pass, and then we can get all these information similar to the immigration node. So English node can use those as second ah adjacency SIDS is ID. We can have a ragam wrote in panels right right.

G

So I'm curious there there are like methods that are being standardized to do that to pass the information from a BGP controller down to an ingress. Node is, is that is this talking about using those methods or another method? There's nothing wrong with that. I'm just be good in the document to sort of clarify what method you're talking about, because I think in the document it says: BGP + and our plus decisions.

H

For BG architecture, so you for we already have those are engines. I mean I, have a big view: evil TV, then a crappy video that we could use that one right, Yamaha already have that attention. You.

A

Are not referencing them? Okay,.

H

Okay, yeah I'll.

A

H

A

You could go a bit more in details and explain what is it exactly? You are trying to do because it completely.

I

Gregg Gregg Nebraska City, so you suggesting that you use BGP controller to calculate traffic engineering. So are you suggesting that BGP implements constraint based SPF.

H

Why not because, uh because baby, you know again.

I

And that's I wanted you to say that thank you. I.

H

Think because uh Pete EPE already gives Jupiter Venus that the information- those are big, that information, including shocking information right so easy.

H

We can have a CH care and then we can compute the traffic in your pass and then use those other paths we can set up either segment, routing, Kitano or MPLS. Three panels.

J

Hi Tony Lee Arista networks. So everybody knows yes, you can just shove anything into BGP. I believe our catchphrase is BGP is not a dump truck.

J

There is that aspect: I don't want to go into that. Let me ask you a different question, which is: what's the difference between this and PCP yeah.

H

That's a good question so.

H

So using piece PCE a week in the lab, okay, we need a deploy, Kizzy, another component, another protocol in the medical right, so that way, I'll increase the maintenance or whatever cost so with PG PE, because P P is already component of network. So if we have PGP as a center controller, we can just reduce the number of protocols. For example, we can reduce the PTFE protocols right.

H

That's asking a the one on purpose of segment, routing right segment, audience that reduces the RSVP, and then we reduce the number of protocol in medic and and customer is happy right. Well,.

J

Customer may not be happy if you reduce all the protocols by folding them all into one you've taken all of your complexity and shoved it into one big monster: okay,.

A

K

More gigatons airdrop.

H

A

Can talk to any upside.

E

A

And he's going to be polite, he promise, based on the amount of content in rubs our student, nothing to discuss. It would be really good if you put more details describe at least higher level and provides right right reference, BG pls, to get the link state I, don't know so spec to configure something just put something.

G

So next up is Jacob Heights.

F

Hello Jakub Heights from Cisco I'm, going to discuss automatic disk, discovering configuration of massive scaling with a massive scale, DC fabric.

F

I've had a look around to see what sizes that master scale data centers are, and some are several hundred thousand servers, so I've gone with. Let's go for a million servers that should be way enough for a long time and just depending on how the how much redundancy you put in and the other subscription you can have up to eight million links in such a datacenter, maybe from 1.5 million to 8 million, depending how many now we want to do you configure the switches in the fabric, we want no location dependent configuration.

F

That means no IP addresses no tear no southbound with northbound configs. Anything like that. We can have configs that a not location dependent such as a random number for a unique device, ID or unique interface like these for scalability no device must need complete topology information. That means we cannot do think states from every device to every other device.

F

Otherwise you got too many and no separate cabling for a management network. Some people like that some people- don't this- needs to detect all cabling errors, not just, for example, superspy into leaf connections or across pod connections, but also things like unbalanced, spines, fully meshed sleeper spies, that sort of thing or anything else that you not have been the requirement so detect every cabling error now, because a network will be automatically discovered and configured if multiple such networks are connected together, the auto configuration and auto discovery.

F

You should not bleed from one network into the other. Thankfully, if the controller is disconnected oh I forgot to say, I'm gonna put a controller in this right. If the controller is disconnected, the network should still function now, I call it a controller, but I've had some comments offline that this is not really a controller. It doesn't do a lot. It does the initial configuration of the fabric only talking about scale, the number of links in a clause, phobic scales, the same order.

F

It's a number of connected servers, the SPF computation time scales higher than the order of number of Link's, so SPF doesn't scale.

F

Okay, this I went through in a previous and that one as well now in the IDR meeting I gave the presentation or the.

F

Only way there I know any way to scale a fabric is to use I used to aggregate the routes. Every switch in a network takes all of its inputs and puts out one route. One route is the aggregation of all of its inputs. That doing that requires a few other things to happen.

F

You need to allocate the addresses to these switches in such a way that you can aggregate them, and that can be a little bit of a hassle, sometimes.

F

And aggregation to aggregate the addresses and only sane aggregates is difficult to do, because if you get a link failure, you get black holes. So in that other presentation I put in well, you need negative routes to say well, I can't get to the failed link, but that also has issues, because negative routes is not a new thing, but the solving of the issues is and that's why I need this? One order configuration auto-discovery and order configuration to make that happen for the aggregation right best way to do order.

F

Config is with a controller because the controller can see everything trying to do it. Distributed is very hard and error-prone, because any any node in a distributed network cannot see the whole thing and makes appropriate decisions is when the network or the connections do not comply with the requirements.

F

Okay, the solution.

F

There's a bunch of stuff on this page, but basically the solution is ztp. A number of ztp zero touch, provisioning protocols or radiators, but the device to be provision must have connectivity to the device. That's doing the provisioning.

F

So here when we have a total network, that's being provisioned, a lot of devices do not have connectivity to the provisioning device. So what I've done here is I can build the connectivity between the device to be provisioned and the device is doing the provisioning and in order to do that, I've taken several other existing technologies and glued them together to make that happen. So the first thing is I've used dhcpv6 to discover the links in a sign of my IP addresses, there's other ways DHCP before could possibly do that.

F

I just found it easier with dhcpv6, because we got railroad retirement in that now, I'm sure it can be done with other ways. But so that's one thing that only he comments on what is there reasons why other things should be chosen.

F

The ztp I've chosen here is: there's a draft in the net conf working good to use no confit, n4 z, TP soft Rosa net, but again could be you know it could be a different one right now.

F

What happens here is the controller I've called it a controller uses DHCP to configure the first device it's connected to then configures that one could be a DHCP relay, so I can configure the next device which you can just turn into a relay which can configure the next device and so forth right, I put BGP in there in order to maintain connectivity between all of the devices and the controller not device to device just device to controller and controller to device.

F

A single hop bgp sessions between the devices distribute the controller address, so device is going to get to control single heartbeat possession between devices. They learn the connected neighbors or more to the point.

F

If the connected neighbors fail, control has multi health bgp sessions, two devices so there's two types of bgp connections is point-to-point and there's a multi hop to the controller devices know how to reach the controller, but do not know how to reach distant devices so to reach distant devices we sr, v6 or actually any source routing protocol I chose is our v6 because it doesn't need to be implemented in the forwarding plane.

F

You only need to do it in the control plane, so it's easy to do it there, but you could use other source routing protocols and then, when it's all been discovered, the controller compares the learned topology with the required topology and then so that's the second stage. Once the connectivity is achieved.

F

It then goes ahead and configures. The final configuration to put the aggregate herbal addresses you, okay, so nearly everything they some kind of generic network to show this so the node. Okay, we have the d UT there. The DAT is some random device in the network, and you can see that the green nodes are the ones that did that this guy knows he doesn't know anything. Any further away right- this is for scalability only knows how to reach is directly connected peers.

F

Now the controller knows how to reach everyone, but everyone. Everyone knows how to reach your controller, but this one down there that's marked in the yellow right. This node does not know how to reach the Det, because it's not directly connected to it. So how does the controller get a packet to the D UT if that device does not know how to get there? The only way is with a source routing protocol, so he has to put a source route on to that packet to get it to the D.

F

U T, so I've chosen, SR v6, for that could be another one.

F

Right now, I've used DHCP in order to discover each of the links as the first discovery, but their CP wasn't built with that intention in mind.

F

So there's a couple of things in DHCP with DHCP, you can request an IP address or lots of interfaces in a single message, but then I wouldn't be able to discover the endpoints. So we need a small change here. um If you want to use DHCP to do this, you can request an IP address for only one interface in your request message, and that is the interface on which the message is being synced. So here we have the first step.

F

We have the controller and node a controller, wants to discover this link and assign an IP address to a so.

F

The device sins of solicit message, dhcpv6, solicit message: there are two other messages in between here, but they are not required with a point-to-point link, so we can put in the rapid commit option. So with this the solicit message, the controller can reply straight back with a reply, and the reply contains the IP address.

F

So there's another little piece in there like that. First message is a router advertisement with the M bit set to one.

F

So a DHCP device normally does not just keep on sending solicit messages out in the ether forever and ever eventually it stops. So one change of made here is that as a response to a router advertisement, if the device requires an IP address, it's a response to a railroad retirement it'll send a solicit.

F

That's it that's a change that is not in the in any RFC right, so once it gets the once it gets the reply now the controller has learnt that link and then the CTP will go ahead and find all the other links and assign them.

F

Ip addresses these IP addresses just random addresses. They have to be different. Every interface in the whole planet network has to be different, but that's all it doesn't have to be aggregator ball or whatever. This is the first step this the last step. It puts a go cannibal addresses in, but not yet I missed it, and that is because the controller- that's not yet know the topology. So it doesn't know what device is talking to me.

F

F

Now here's a next device device II.

G

Maybe just one question on the previous slide for a second just the network in point table is on the controller or on the device. Oh.

F

That's on the controller, that's the controller learns all of the links in the whole device in the whole fabric- and this is it's a link state table on me and.

G

The end controller, okay and it's gonna- use that to create of like the the SR v6. Yes, stack of interface addresses to get to yes, the next router yeah.

F

You know there's.

G

A router as a does the switch also have the similar. Is it able to talk SR v6 back to the controller or not? No,.

F

You know it rule route back to the controller, so each device will way here so so each device, the the red line there is the is the way back to the controller. Every device will know which interface to use to send a packet back to the controller. So the device has the controller address and all of its neighbors, but no further devices so device can get back to the controller. Is the controller getting to the device that needs the segment routing, because that yellow guy does not.

G

Okay and it's using like the equivalent of a stack of adjacency SIDS, which is in v6 the each interface address, yeah.

F

Yeah, so it's just got a list of addresses to go to it. To get to that.

F

Right, the second one right, the second one is a little trickier than the first link to find the second link e sends a DHCP solicit to a now a is a relay agent. So, in order to discover that link, we need to find both ends of the link right. We need. If so, we need to do UID device, unique identifiers, DHCP thing all right from E and the IA ID. That's the interface address association identifier, and that is a not only identifier that he's unique on the device. Only.

F

So we have, we have the interface identifier and the device identifier from e that is sent in this recent message now AZ is, is a link address field in the dhcp message that will identify the the a's end of the link and the source address of the relay for what message contains a's loopback address so now we know both ends of the link that information goes back to the controller, so that's browser back to the controller right, and so now the controller has that it knows that link now now it can assign an address to e.

F

Now the requirements of that address is that it B it has. The the same. Subnet number is the one on the a side so that right, so that the link has the same subnet on both ends of the linking, but the interface identifier, part that the low part of the edges can be anything so now we have an address for E and then the controller starts ztp to e and discovers the rest of the interfaces on it and configures the device again to be a DHCP.

F

Really, oh, okay, the last part there it puts the bgp sessions on now these bgp sessions. They are only for discovery. It's not the final bgp sessions in the final network.

F

Right um so what happens if e is configured through the bottom link in a is configured through the top link and the CTP configures, all of the other interfaces of a and all the other interfaces of e, but it doesn't know about a link between a and E, so it configures the wrong subnet for their interface on either side because it doesn't lightly connect right. So here's a next small change.

F

The router I'd advertisement from one side will disagree with the subnet address from the other side and say: aha I got I got the wrong suddeniy. You can find from the router advertisement that hey I got the wrong subnet. Now, if the N bit is one in because one means give me DHCP, then he says: aha I need a new address. Sorry sends a solicit message as before, and then of course, then, when that gets through with the relay forward message, the controller figures out that whoops gave it the wrong David.

F

The wrong subnet gives it the proper subnet and sends it back. So now we've fixed the subnet. So that's how we find the link stick. The links that did not have an initial DHCP request across them. We find those links out now and with this with this method, as this continues and it ripples through the whole of the network, the controller can find all of the links from the DHCP requests that are coming to it from all the network.

F

Okay, now I.

F

Think I went through the bgp connections right, so this is the last thing yeah.

F

There's the security threats they're applied to this is that any if someone can connect a malicious device to one of the switches, any of the switches in the network it can get in. It I think an access the underlay from outside through the network itself, but it has to be directly connected all right. So the best security is our guards which they do have, but failing that any device it's directly connected can disrupt any of the tunnels.

F

So the the tunnels that are running through the underlay may all use IPSec tunnels and learning that will fix that the drive ITF net called zero touch. That has a security built into that. So that can be used. The TCP I mean the BGP connections that are running on this to use TCP. You know, there's a way to connect on forever SSH and there it is now DHCP does have an authentication option in there, but the point-to-point called the later authentication has been deprecated. So that's no longer there.

F

However, it could be resurrected if needed, but here I found a that's the last point. They have found a document that describes a similar thing to delay authentication using.

F

Public private keys.

F

And the last slide, so really some of the choices that I've made here could be made differently. But basically what it is is to use ztp to connect ztp to configure all of the switches in the network and use DHCP and.

F

The the BGP to get connectivity between each device in the control question coming.

L

From Google I read through the draft multiple times just wondering what exactly are standardizing here.

F

What am I standardizing? I need a couple of different things to THC pay to make the DHCP priests work I. Don't.

L

See that anything in the document.

F

Okay, I'll put it in.

L

Quick question on so: let's take you add a device right in your assumption in the draft that the controller doesn't know that the device got added, what happens Oh each.

F

Each device as its configured becomes a DHCP relay agent. It also seems a rather router advertisements on all of its links. One of the changes of my it is if a device requires an address and sees a router advertisement with the M bit set it'll start at the HCP solicit and what.

L

Controller doesn't know that doesn't have any related to the device. Now.

F

What happens? The controller has reach ability through the DHCP relay agent, which is which is so.

L

What you're saying is something is that controller will always have the which ability of the device is that right.

F

The controller will have reach ability to the relay agent device to which the new device is being connected, and that's when it, since the N bit to one another piece in the draft that I didn't put here, was that if the device does not have fails to reach a controller, it will not sit it's in bit right and then and then what happens is that you can make a new device. It will not be. It will not be detected so yeah it.

F

The BGP ensures connectivity clearly controller as long as there are links if if a device becomes totally disconnected like partitioned away, then of course there's no there's. No connectivity, no.

D

J

Yeah Tony Tony Lee Arista networks I like this, but I can't help wondering if it wouldn't be simpler to enable routing incrementally, as you went.

F

They yell I, going right. The other guy doesn't know how to reach Det, because each device knows only its immediately connected, maybe and I've done that for scalability I mean you could run eyes. I saw something in the whole network, but that wouldn't scale well.

J

Hang on for a second isn't, the MS DC gonna eventually run some flavor of routing. Oh yes, that was.

F

The draft I presented to the idea into him using aggregated, using a using bgp aggregation so with our C seven. Nine three eight hope about the number right.

J

So why not deploy that incrementally? It seems like you would save yourself having a mess with us are.

F

So you saying to put the aggregator below addresses in in the beginning wireless, oh yeah, because the controller doesn't yet know before it's discovered only a few devices. It doesn't yet know what it's talking to you. It doesn't know, wait what the final addresses should be until it learns at least a very sizable part piece of the topology okay.

J

But wouldn't it be better if the ER, the the controller, had some idea of what it was doing before him.

F

That would be nice, but it doesn't have to so I mean yeah, where which device you're gonna connect the controller to several devices within the network, but it doesn't have to know which device is being connected to now. If you want to do that, if you want to put the previous information in that, you know that it knows what it's connecting to. First then fine. We can put the final addresses in in the first state.

F

Yeah we could, we could do that, but we don't have to.

F

M

You tell me what MSD see in the right mind doesn't have a topology defined ahead of trying to bring up a network right. Sorry, I I run in the MSD, see I run in network I have a controller that does something like this on the out-of-band network, because we're predefined the topology we're predefined, a topology because we're predefined a wiring plan we're pretty fine a wiring plan because we have to layout a fiber infrastructure throughout the entire data center. All this is predefined. We don't need any discovery like this.

M

We will program it out-of-band, because when hits the fan and holy will hit the fan, you need an outer band network to fix the in band network. Why do this?

M

You could introduce yourself I Igor, Yahoo, Oh Rison, whichever label you wanna sign, but yeah I. So we run data center topologies would over thousand physical servers right now in a Clow clothed in a multi-dimensional follicle network. We have controller that pre configures everything that deploys configs we've, given a talk at Nana, going exactly how we do this, both on the controller side and telemetry, etc. We don't let devices arbitrarily configure themselves again. We have a topology plan.

M

You have to have a topology, find an MSD, see I, don't understand why you need to do the stablished of discovery thing.

C

Systems up, can you go on? You said you have a topology plan. Do you use aggregate able addresses like we're trying to use now? Yes, oh you do. Okay, yeah.

F

Yeah I would like to talk you about.

M

Summarized aggregative all yes, yeah.

F

M

And we have a controller that will verify whether topology plan matches reality of wiring, because we find X percentage of stuff is miss wired by you know happens and we, the corrective action, isn't to hand out a different IP address. The corrective action is to make somebody wired according to the plan.

M

Again, you have a plan, you stick to it. Yeah.

F

Yeah sure umm so I do you connect the controller to the devices with the management port. I connect.

M

The controller to the devices on both in band and outer band, because any of redundancy for that, so initial configuration would come over the outer band. At that point, my agents get dropped onto wiring.

F

One, it's there's a separate wiring ever out of bay when you say out of band yeah.

M

F

Not in the same words and I.

M

Find it very so the controller is capable of talking both in band and out of band. It actually.

E

M

Over both because when ztp occurs, you grab the config, you grab the initial bootstrap and then you connect to the control over which ever channel you have. We prefer to happen over the outer band, because that means in band doesn't need to be up. But if you were to do it over in band only you would basically device one everything connected to device, one everything connected to the next ring and they would build out in rings out particular capable of doing that and then only it just. It doesn't need a whole protocol to do this.

M

M

Yeah who's, the customer that's asking for this is what I don't understand, because this seems like the wrong way to configure your network. Okay,.

F

I'd like to talk to you more, we have more time so. The the aim here is that you do not need to configure any position dependent information into any device before you put it in the network that you can take a device out of the network, fix it put it back in and it'll come up again, you can put it back. You can, if.

M

I'm wrong the way jiffy works, I'm, pretty sure I'm not wrong here- is that you will need to have a MAC address. That is somehow mapped to the system, identifier, because that's how you're going to handle a config, which means that you already have said this MAC address is in position X. That is effective.

M

That is what you do in any large MSD see what you actually have is you have a wiring plan, a topology, a model, and then you say nothing more than MAC address X, which happens to be this switch that I'm dropping in goes right in this slot, and then everything is configured around that and.

F

If you put a different switch in that slot,.

M

Then MAC address well, if I put a different switch in that slot, that's which will not come up because it doesn't match my model. My model says MAC address. X goes right here again in any large MSD see we, the architecture team will design how things are, and it better be that way, because any deviation in a large-scale network is unacceptable and simply gets D configured.

M

F

So what I'm doing here is as long as it's the same type of switch. It doesn't matter which one it you can put any of those switches into that hole and put the Y's in in to any Hall and the Y's and the control figure that out figure out where in it, where in the topology, it is find out. What is the proper configuration to put on there and we'll put that on me? I.

M

Again, operationally I'm wondering what MSD C would do that, because that seems unwise.

M

That's like saying you can put any server randomly into any position of the data center, which is just not how things are done, like your inventory management system, keep track of everything like in the data center. You to know like in a large data center where things are yeah. You need to know how they're wired up both power and network, because you're going to be doing power, management, you're, going to be doing cooling management, you're, doing, network topology and traffic management. You need to know where everything is randomness is just not how things are done.

F

Well, the controller will know where everything is once it finds it. The.

M

Controller isn't supposed to find it the controller supposed to tell a program where things are according to a plan, I think that's the disagreement and that's why I'm wondering do you have any large MSD sees that are saying I want you randomly spread all over their data center, because that's what the sounds like! No.

F

It's not we're not randomly spring all over the data center right. What I'm saying here is that you have two identical switches. You can put one switch in that Hall or the other switch in that hall, and it won't make any difference once this guy when the controller discovers it then you'll know where they all are now so having having to say. I got two identical switches here: I'm gonna have to put this in that Hall and I have to put these in that Hall and if I mix them up, it's not gonna work. What's.

M

Actually gonna happen is that you're gonna take two random switches: you're gonna put one of them into a cabinet you're gonna roll, the cabinet in you're, gonna, plug it in you're gonna, take a some form of a scanner and you're gonna go bbbbbb down the whole thing at this point. You know exactly this: is this switch? This MAC address all these servers for them into these exact positions, these exact ports, and at that point that goes to your operational database of some form and then you controller reads that and goes oh switch.

M

X Mac ad Y is sitting right here. This is how you program it.

C

This is left kind of great discussion to go forever, but a sealant of Cisco Systems I can see what you're saying, and it does make things a lot simpler to manage. If you do have this out of man management. If.

M

You're an MSD see you have to have it so if you're designing this for numbers, okay,.

C

With that, so we have the wrong requirement. That's what you're saying yeah okay to have something that does it does everything in band it does the zero touch I mean.

M

Whether it does it in bin or up and doesn't matter rain to know, it makes it.

C

It makes it simpler if you have the.

M

Only the difference is it's not random. It's not discover so spat. Okay,.

F

Here we go and I'm open to changes and to hear what you have to say and I'd love to do that, and actually anybody else in the group.

F

Okay, I'll see you after things.

A

Like and our IDs here so after 18 document definitely doesn't belong in idea, it tells us to do with BGP as such. If you continue working and I think this working group is better place, it's my personal opinion, obviously Marty. It would be up to you to.

F

Now the thing is: I've put several pieces in it's, not just BGP I, actually, I named it. Oh.

F

Sorry, it does not belong.

A

F

Belongs in idea no.

A

It doesn't I understand.

F

Yeah yeah yeah, um now actually I. You know, I named I'll put the IDR into the name of the document, which is a mr.. It.

A

Doesn't matter how he named, it survived their architectural document, it's not ideal where.

F

Do you think it belongs probably.

A

F

Okay, that's why I'm standing here.

G

So next up is Sanjay. Welcome.

G

So, do you want protocol.

N

N

L

Okay thanks, so we presented a framework, an architecture for cups, control, plane and use a plane, separation on B and G in the last ITF, so I think one of the actions, or at least the action that we thought the group presented was before we get into protocol selection. Let's put a set of comprehensive requirements for the protocol between the control plane in user plane.

L

So we did that it's a world jointly done between vendors and and some of the providers. I don't think I'll have time to go over every one of the requirements, but at least the key musts that we see will try to go over those so very quickly. If you look at a B ng, which is your broadband network gateway at edge of the network, I won't get into reasons. Why cops? We have done that as part of the framework.

L

But if you decompose it, then your control plane running as a virtual network function runs the subscriber management control plane only essentially DHCP PPP authentication. If you have l2tp accounting, credit control and things like that, all your routing MPLS BFD that stays local to your. U P or you use a plane and of course one model is where you have a lot of distributed: B and G s if remote locations, but you want to centralize the control plane running as a V and F.

L

So more often than not, you may have a layer, 3 network multi-hop between your, u piuser, plane devices and your control plane.

L

Let me skip a few slides ahead, so here at least our goal, as we stated last time as well, is to look at different deployment models for B and G, which are evolving and see that if we can do cups or this control and user plane separation in a uniform way, irrespective of how the bng is deployed, so one thing we observe is that bng is becoming more multi access where you could have, which is you know the common model. Today you have a fixed access network from the CPE.

L

You have your access nodes going to the B and G and more often than not, this is a dot1q or q and q. So it's a layer, 2 network. Of course, you can have different forms of layer to overlay or 3 tunneling layer 2 over GRE VX land MPLS pseudo wire, but essentially you have layer to being backhaul to your bng.

L

What we are now seeing also is that providers are looking at 5g, millimeter wave, for instance, as your last mile, so you want to basically do a fixed wireless type model where, instead of an axis node, now you have a ran that your axis is over and your bng is still terminating that fixed wireless access and doing the same type of subscriber management here. The functions that I just called out earlier.

L

But in that case your axis is not your VLAN tags or a layer to overlay at 3 tunnel, but it is a gtp you tunnel, for instance. So, ideally, when we look at cups, you want to solve that as well. And finally, of course, you can have hybrid axis, where here you want resiliency for wireless connection, to back your fixed connection or higher aggregate bandwidth, for instance, where you are not upgrading from copper to fiber.

L

So, in that case, you are terminating both accesses on the B and G and we want cops to work in that model as well. So then, very quickly, if you look at the three interfaces, we define last time as part of the architecture. You need a state control interface between the control, C P and you P. What this does is essentially, as the subscriber management control plane runs authenticates the subscriber assigns an address.

L

It would use this interface to program your hardware being, for instance, or your user plain on with its data plain state, so that is the state control interface in-band signaling for fixed, if you keep fixed wireless aside, is invariably always in band. So your signaling messages from your CPE show up to the U P. You want to tunnel them if this is, for instance, a layer, 3 network to your control plane and then the return messages need to be tunneled back through the U P to your CPE.

L

So, there's a need for an inbound control plane, working both with layer, 2 and layer 3 between the CP and the U P, and the last one is the management interface we're not focused at least yet on the graphic on this. But that is future. We will do that, but this is essentially a single point for management and control. So you need a management interface for both config and state between the CP n, w CP vnf and the U P.

L

So then quickly, looking at the requirements again, I'm zipping through because of time, but basically your baseline state control interface and then we broke it into extensibility, in-band control, channel scalability and performance transport protocol used for this cups protocol, resiliency and security.

L

So if we look at this state control interface again, it's a busy slide. So I'll, just you know, call out the key ones. So, of course, the basic function of this particular protocol here or the state control interface is to download the forwarding state state related to traffic management. Your ackles, your you know, SLA SLA management from the CP to the U P and again. Ideally, this protocol must work for fixed, fixed wireless and hybrid access.

L

Then, of course your subscribers can be your IP OE subscribers of pppoe subscribers, where pppoe could be terminated or tunneled to a retail gateway on the other side. But also one key thing is like I said before your transport could be diverse right, it could be Ethernet, it could be l2 or l3, with l2 over GRE VX LAN or an MPLS pseudo wire. So, given all this variants that you see, you want to make sure a control plane can work with a different vendors yupi implementation.

L

So it's not that from the control plane you take look-up tables and dump it onto AUP. So what you need is a flexible set of match, rules and actions where you can say match this subscriber of this slash, 32 and go program. Your forwarding state, you know encapsulate or D capsulate or do that or just route.

L

So essentially, what you want to do is not dump look-up tables directly based on a vendor implementation of AUP, but you need a definition or a language where you are specifying it in terms of forwarding rules or match rules plus actions, so that I think is a key for this. For this cups protocol.

L

Besides then, just the state, the forwarding state, we also need the routing state for the subscriber. So if you're aggregating a subscriber subnet and announcing it into routing upstream, you want to pass that aggregate route from CP to the U P.

L

If you're giving out the gateway IP in DNS, you want to pass that gateway IP address, so it's not just forwarding plus traffic management, but also related to subscriber routing an IP interface state and then, of course, your cross state, and we see at least in fixed networks, a hierarchy where you manage traffic to the CP or control the amount of traffic to the CPE, but also to the access node.

L

So there's a hierarchy, so you need the protocol to be able to indicate from CP to the U P what hierarchy this CP your subscriber belongs to right. For instance, this CP is behind this access node.

L

You definitely need some kind of lightness detection between CP and U P, based on periodic heartbeats one quickly, detective one Goes Down and then in terms of just messages and events. We need a synchronous session level event, notifications from U P to CP, for instance, reporting periodic usage which the CP may then you know various accounting at interim updates. So your periodic reporting of usage, your threshold based reporting of usage, inactivity time out if you have programs.

L

So these are you p2, CP level events also subscriber none, reachability detection, for instance, you may from CP, essentially issue a directive to see if this subscriber is reachable and once the UPP takes the subscribers is unreachable. You need a notification, so you need session level notification session being a subscriber session, but you also need node level asynchronous notifications, for instance, if one UPS, which is over to another you PR redundancy domain on AUP switch, is over because of a failure of a port or a group of ports.

L

Then you want to be able to notify that he went to the CP, so CP can download your subscriber state to your other. You P already done this suggests in terms of extensibility. This is really key here for the cups protocol. You want to define the information elements that you encode in the protocol as tlvs, so this should not be just you know, fixed format, messages.

L

You should always be able to define additional information elements and existing messages, but also should be able to define new information in existing TLV. So this is all under the umbrella of you know. How do you define PL V's for extensibility, and you definitely here need vendor-specific tlvs as well, where you can partition your type space and leave a certain space, for you know vendor specific extensions and finally graceful handling of unknown tlvs.

L

If you have non-mandatory tlvs there, the CP sends to the U P, then you need to need a graceful way of handling those on the U P, where it can ignore the non-mandatory ones, for instance, coming quickly to the in-band signaling channel requirements.

L

So one key thing that you need here is that the cups that you're defining you should be able to set up the control channel between the U, P and CP to transport. The in-band signaling I mentioned before DHCP and PPP, for instance, because all your signaling is coming into yupi. So it has to use the in-band control channel to send it to the CP.

L

You need the U P when it receives a signaling message to essentially signal a layer to circuit ID which port with which VLAN tags or which tunnel or pseudo wire the control message came in on. It needs to signal that to the CP, so in CP sends the response back. It can build a message and address it to that right, l2 circuit or l2 access, ID.

L

One key thing here is: you need to be able to pass the whole Ethernet frame that you received with the signaling message, but also in the fixed wireless scenario, where you have a GD P, you tunnel, your DHCP, v4 and v6 messages themselves come over a gtp, you tunnel, and you give me u it's an IP payload, so your inbound control channel must be able to pass both IP and layer, two PDUs up to the CP and vice versa.

L

Another key aspect is that this control channel must give you the capability for CP to specify which control packets at once also priorities for control packets, for instance, prioritizing renews over discovers or prioritizing keeper lives that go back and forth. So just the notion of CP telling the UPI need these messages. With these priorities and in case of overload, you want to be able, the CP should be able to control, tell the U P the rate or vice versa, so overload management as well.

L

So the short here or the net is that your control channel must be dynamic. It's not like a static, you know, let's say a VX land tunnel, but something that the CP sets with the U P indicating which protocols it wants at what rate and what priority. So that becomes important.

O

L

Then, looking at scalability and performance I think this one is obvious that you want to minimize the latency to bring up subscribers. Your CP may be centralized dealing with you know hundreds of these small B and G modes, which are fairly distributed so across this whole cup system. You can have a lot of subscribers, so especially when you have there are events which triggered a lot of subscriber bring up or tear down within a short period of time.

L

You want to reduce the latency for the subscriber to log in one key thing, is we want to limit the chattiness here to bring up a subscriber I think that is a here where, ideally, when you're bringing up a subscriber, you have the VLAN information you have, you know, let's say encapsulation with PPP, you have that you have ipv4 or ipv6. You have your course information.

L

If you want to collect all that on the CP and send a single request response message as opposed to these individual messages or multiple round trips, because that latency can kill you here. So definitely minimize the chattiness here and you know whatever protocol we choose should allow allow that overload I already mentioned then. The other thing is your ups to the cup system and can increase as your number of subscribers increase or number of ports on RUP increase.

L

Now your load on the control plane will increase, so you want to make sure your control plane, vnf can scale out, and your protocol that you choose should allow that load, balancing of the control, plane, load and scale out. For instance, it may be an initial message in the protocol going to a load balancing entity which tells you a way to reach the right. You know CP resource and, as you scale out, so that again becomes key here and then we are very possible. We want to optimize the amount of information passed in the messages.

L

For instance, if your forwarding state or your cross state is same across a group of sessions, then you want to pass these things by reference once you have created these based on an initial message just in terms of transport protocol.

L

So one key thing we are looking at here is that the cups protocol must not suffer from any head-of-line blocking. Ideally, it should preserve message boundary with Datagram semantics, so this looks more like a UDP option here. It should be, of course, easily implementable on a stack on. You know, simple forwarding devices but of course, the protocol itself. If it's using UDP needs to transport, it must support reliability of message, exchange, wire request, response and retransmissions.

L

So, ideally, no head-of-line blocking you know datagrams semantics and then build reliability at the protocol level rather than the transport level quickly. Looking at resiliency, you won't, of course one is to one and ideally, n is 2 mu, P level redundancy. You want your CP to be redundant as well, and when there's a lot of bunch of detail in the drafts I'm not going over here but the net is, you need redundancy for both entities.

L

Security will spend more time on this, but right now is just saying: this must be compatible with the proven mechanisms, such as you know, TLS or D, TLS or IPSec. But again the notion of you know security domains. We're within the same domain, you may not do anything but across security domains you want maybe SEC or TLS or DD LS, and then last one here. Protocol selection input. So if you look at 3gpp today for packet gateways, they've defined a protocol in 29 to 44, which is called packet, forwarding control protocol.

L

It's proven in the field, but more importantly, it has been extended over time to different type of forwarding, constructs and devices. So it works for a s gateway where your forwarding is Eid to T Eid. It works for a packet gateway where it is T Eid to an IP address or a TDF, where it's an IP to an IP. So that's proven in the field to be very extensible. It's a pretty extensive protocol machinery, but the way it is built it is fairly extensible, so it has tlvs for messages and such so.

L

Our recommendation here is that we can look at extending this for B and G cups as well. One difference, of course, is that with B and G your access is layer 2, whereas for mobile it is of course layer 3 with GDP and also signaling in bng. We need the in-band signaling, whereas mobile it's out-of-band. Today right, your GEB tunnel gets set up before anything else happens.

L

So, but those extensions, if you look at it, it's fairly reasonable, but you give this whole protocol machinery, that's well defined and proven, and it does define tlvs where the number space is partitioned between vendor-specific and standard 3gpp, so the vendor-specific once we can extend for bng and the benefit. Of course, is you don't reinvent the wheel? You extend what's there, which is already proven and it'll work for the bng, both all for all the different topologies, whether it's fixed, fixed, wireless or hybrid, so I mean I.

L

Think next steps that we would at least want to do is add more details on requirement for the men and management interface that I didn't talk about and then, lastly, define protocol extensions, ie extension UI ease to realize PNG cups with PFC P. So that's pretty much.

G

So I did want to clarify one thing: he made made a comment a number of times like protocol selection or protocol choice, and it's not clear to me that the routing area working group has been tasked with selecting a protocol here. You know we were asked by the broadband forum to focus on these specific drafts and their first liaison.

L

Is on from the you know, convergence workgroup in broadband forum, which is essentially saying that look. We are trying to integrate fixed broadband with 5g, for instance, and there is work happening between 3gpp and broadband forum. They study document going back and forth, and the expectation is that we'll have some bng related changes to couples. That's already defined and based on that, you know, we could see how much of that in other.

G

Their subsequent liaison yeah, it's pretty clear that you know they have yet to perform a feasibility study yeah and until so until we're told otherwise I think they're not asking us to choose a protocol so.

L

That's why we're calling it a candidate you're, not saying that this is.

G

L

Making our case here we are saying this makes sense and here's. Why so I agree with you BBF can you know weigh in.

P

A

P

I okay. That means on call. We are just a quick question for clarification because you mentioned that actually the protocol, it's called PF CP, right and Greece owned by 3gpp. Okay. So now you asked for ITF to do the extension of 3gpp protocol here or what? What? What kind of work all step back to write a 3 GPP to get some get more approval. So.

L

There are cases here right like there's: a fixed wireless switch squarely belongs to 3gpp and BBF is working with 3gpp on that now there is also a pure, fixed bng, where what we are saying is you have this protocol defined?

L

Is there a way to reuse it and the protocol it's written in a way where it allows you to extend the information elements, and it has a number space that is partitioned for vendor-specific, so ITF or BBF could be a vendor once that study is complete and folks agree that this is the way to go, I mean our goal is to not reinvent, you know what has been done and proven, and ideally we want the bng to be able to be multi. Access should be able to handle fixed, fixed wireless and hybrid.

P

Just want to clarify I'm, not understanding your quad law, I! Think that what what you want ITF to do at discuss the protocol tension Oh correct, because 3gpp.

L

Will not look at the fixed bng right, their purview is fixed wireless, but we want to use a single protocol because your bng is a multi access device, and so those extensions assuming BBF and 3gpp agree that this is the way to go. Then those extensions, those bits and bytes information elements. We can do it here. Okay,.

P

So you want to do some suji P protocol to see okay well can be applied here in ITF or.

A

Really price: we take it's the leaf, yeah, okay,.

L

By the way, 3gpp, this is president there as well. Mobile IP is defined here used by 3gpp diameter. Credit control is defined here, used to an OCS in 3gpp, already, cooperation between IETF.

Q

And 3gpp yeah, okay, because I also heard you say, take it to the list: okay,.

M

Q

Jason, a crow barracks and I'm speaking with the broadband forum liaison manager hat on so pretty much. What Sanjay was saying is the case. There's work on fixed only architecture where the be in Jeju segregation is detailed. That's a TR, 384 I think it is, but and that was liaised to the IETF back in March and I. Think that's the first liaison. What didn't what's been subsequently liaised is the work from the wireless wireline convergence group. That's now dealing with 3gpp.

Q

The BBF has not consolidated this work yet.

M

Q

I think if what we're trying to do here is come out with a unified set, a protocol that can deal with the whole shooting match the requirements for that need to be sorted out. Bbf first, so Indian.

L

Liaison in conjunction.

Q

I'm sorry and then liaised here, you know once that work is done. Then you time frame well, I mean optimistically. They have their next meeting is the beginning at December, but there's no. It was.

M

Embracing on my colleagues.

Q

Face over here as to whether that'll happen. Alright, the laughing is indicative of no but soon after that, I would think. Thank.

A

R

Joe's car journeys some are closely involved in in BBF activities and also discussed the second light zone. Actually that has been sent from BBF to ITF, where.

L

Are you from I got your name, but not your hallway.

R

So the the main se goal of the last owners to emphasize that we'll be in a stadium of starting requirements for feasibility analysis to identify whether requirements could be say derived for having an interface for a common for a control, plane, user, plain separation for both type of scenarios.

R

That is not clear whether you know this requirements could be useful to be for both type of scenarios. So that is not clear. Yet.

R

What is clear anyway, is that if we would like to to focus on a fixed mobile convergence scenario, then the solutions that you are proposing, it would be ready, I think in at least 17, meaning that companies that would like to have a solution as soon as possible for the fixed neck fixed network access will have to wait until 2021 2022. So it's just.

L

A quick response to that 3 DPP is not going to look at a fixed bng. It's for BBF to see what is being done there for cups for say. Fixed wireless, for instance, can be used here and, if I'm not mistaken, fixed wireless as part of 3 DPP release 16 or its supposed. Yes,.

R

But not, but not the control plane uses plane. Separation coming from the fixed mobile convergence will not come in little e 16, that's for sure, okay, so then it will come early 17 and then we'll have to wait until 2020. You want to have a solution. Sorry.

L

The well fixed.

R

Net or fix Network say carriers want to have the solution, but.

L

Again, I don't quite see that we fixed wireless cups as part of three DPP released 16. That's my understanding. Andrew.

O

Doggin or not yes, since I almost got hit I think I deserve a little bit of the Mike I think we have to fundamentally answer this. We have a router setting in a network. We're gonna have a mobile car setting the data path for it as part of its separation. We're gonna fixed core of some sort, setting that we will not have a converge that three of those will happen. There will be deployments that they will mix it. There will be diplomacy with their fixed or mobile I.

O

Think from our perspective, I, don't think we want to have three protocols, three things and managing that router and other one. It will be just now you're talking to anyone that will be like 2030 before we get this working and I. Think the value here is that it's simplistically to say that.

G

Excuse me excuse me I'm, cutting off the discussion here because we're cutting into Dawn's time sure. So, let's, let's move on to the next presentation here and give down the floor.

N

S

So I'm, Donna least lake with Huawei, so I have a much simpler presentation. A lot of technical details for these drafts that I'm going to talk about I, think we're presented at the last IETF and you're welcome to go. Look at them all. There I think. Similarly, general details were presented on the water drafts at the last IETF, so here's this set of of graphs that are they'll have the string, cos P DT in them, and here's sort of an amalgamated list of authors.

S

So these drafts are effectively the result of a sort of an informal design team consisting of Huawei, China, Mobile, ZTE and, to some extent participation by others, and this is what the drafts what they've come up with. So these straps are all to support the broadband forum tr3 84, which is a final document issued by the prevent forum and has to do with supporting fixed network access and on this slide, there's a URL. So everybody's welcome to go.

S

Look at these look at this TR and this TR provides for control, user playing separation and I think it should be. No. This is a something from the BBF which says architectures and things like this, but the BBF does not do protocols. So the extent of this architecture requires some protocol that isn't specifically defined for that that somebody has to specify that protocol, so I'm just going to go a little bit of the architecture.

S

This shows a network like a cloud broadband network gateway, the control plane and some multiple user planes, some of the functions that the control plane gets access to the triple a radius, diameter servers and DHCP and so forth, and one of the goals of this there's virtualizes things to improve scalability economy.

S

You can pull out services faster by having things be virtualized rather than physical and so on and so forth, and you noticed there's this sort of uh for the three this you know. Diagram shows three user planes as triple lines going down. There's three of these of these lines and this one kind of shows what each of those three lines is from the control plane to the user plane. These corresponds to the TR, 384 architecture, the service interface, a control interface and a management interface, and just won't go into any unnecessary detail.

S

I, don't think the the control interface assumes a customer user separation protocol which doesn't know there's currently not a I, know standard for that as such.

S

So this is also a more disaggregated diagram of the network gateway, showing more detail, some of the sub components and so forth, which can be virtualized in various ways. So there are these liaisons, which were mentioned in the previous talk and I want to be careful. What I say about the URLs, the liaisons here.

S

So people were also welcome to go and read the liaisons and see what they say, and this initial liaison was sent a little bit after the issuance of TR 384, which basically said that the things in quotes here are cut and pasted from the liaison. Currently, the ITF standard to work on the interfaces of this aggregated bng has started, gives actually, for example, and lists, actually that's two drafts and the original liaison.

S

If you go back and said that they look forward to continued IETF progress on drafts for the interfaces of this disaggregated vnj- and this is the second liaison- you also go look in that reader. If you want- which basically says that there is this other work going on fixed the mobile convergence- and you know you can read this stuff- basically as there's work going, which will at some point presumably produce an architectural requirements so on and so forth.

S

But that- and this could possibly result in some changes- went you know almost every protocol evolves and changes, but that they haven't. You know actually decided on the feasibility of doing these things, including the getting something which will satisfy both to fix the noble. So this is basically just a thing, a sort of a notification there is future work going on and as yet there isn't. You know an approved BBF broadband forum way of doing this sort of stuff and that this sort of fixed mobile convergence, stuff typically happens in 3gpp.

S

So these are the the drafts again and these drafts are are being worked on and they do provide in the protocol draft here, one sort of in the middle, a solution that supports this fixed network case and a couple. These graphs have been gone through extensive editorial revision. Recently they say, there's continuing work. All the drafts probably could use further polishing in various ways: it certainly editorially and these this protocol- this that's specified in this.

S

The protocol draft was successfully used after hackathon at the IETF one or two, and he actively had to have the protocol draft in conjunction with the information model draft as a they refer to each other and so forth, and there are in fact, trial deployments of this protocol and so there's some customer usage and so forth. So the question is what should be done with this?

S

This is work that I'm sure would be improved by going through the IETF process, but not in the sense of getting polish drafts getting better by ITF directorates and so forth would result in in some improvement in various ways, and you know, security, etc.

S

This is stuff which is I, think in use and I believe that there are people who want to work on this this polishing, instead of getting the stuff up to the level that would be necessary for an RFC they're people who want to use this protocol, and so how should we proceed on this so weeding these liaisons that you liaisons refer to here these some people looking at those believe, there's some. You know it's not not necessarily crystal clear, especially try to look at both liaisons exactly what the the message is in aggregate.

S

So question is: how should we move forward on this, so I believe, and we can determine to some extent from the people in the room or on the mailing list, that there are people in ITF who want to work on this FCS PDT, see you separation, PNG protocol and related the related drafts to support TR 384 I believe that if we worked on that their work will be completed ref quickly, I mean this. Protocol is already in trial, deployment and so forth.

S

There's there are drafts, it's not like something has to be written from scratch or gone through some big cycle or whatever I believe there are carriers who want to use that protocol for fixed network I mean this is a fixed network protocol so and that, if this is true and there's a feeling that we need a clearer liaison from the broadband forum, then what we should do is send liaison to be via eff, saying that from the IETF well from this working group or whatever.

S

However, it's the right source of the IETF saying that there are people who want to work on it, they're people who want to use it, and we want to know whether there's objections from the other end. So my feeling is that if there are people want to work on it, it's already in a fairly complete state and they're people who want to use it and there's no objection from the broadband forum. Then we should do it. You know if those Commission's don't hold, then obviously it's a different matter.

S

So that's my presentation.

A

Q

Thank you again, speaking from the point of view of the PPF liaison manager, I think sending that liaison would be a good idea. I mean if nothing else, it'll get some clarity back from vbf.

T

Transiently from 10 mobile some comments and the information from 10 mobile at this time, what we need, a it control/play and European Stability HP India for the fixed network, access as presented by Mike or occurs in the previous meetings. We already have the reference implementations, including.

T

Kanchana from 10 mobile and those those reference implementations are from multiple vendors, including variety accuracy, and we have already done some test posting our lab, and you know, v network. The test results shows as those reference implementations work well and they can satisfy our requirements, both the performance and functionality.

T

So so at present, I think the ATF should focus on on the v network for the control, brake and user based approach, ing for the effort and see I think it's a totally different story as far as I know, as the architecture is being down at vbf, so I think I'm happy to to work together with Nokia sppf to develop the picture for the FMC and then discussed the the protocols for for the FMC scenario where to to defend the suitable protocol protocols for interfaces.

T

U

Women Rick's, Nokia I think it's a good idea to centrally, as you want to to BBF, because I think that's needs to happen. But I also believe and I repeated myself from the last ITF. Is that I think we have all I? If we rush too fast into the fixed, we have a lost opportunity to solve the FMC use case and I.

U

Think if we can work together in BBF to speed up the requirements for FMC use cases be together with with a fixed side, we could actually serve a good cause for for the industry in ninety. So I write, I recommend that we probably speed up the work together requirement for MMC clarified in BBF as soon as possible, such that in the next ITF.

U

We can actually work and get those requirements in and then see whether which protocol is the best way forward to solve this problem space because MMC or fixed at the end of the day, which we should not come up with two different protocols, or I similar use case I. Guess.

S

I, disagree that the completion of these documents, which were already in this advanced age, which are already they document, something which is already news, would have any significant effect on the timing of subsequent efforts and.

U

It's up to the BBF to to see whether we can accommodate that well,.

S

I was just commenting on the time and saying I. Don't I, don't think that, due to doing what I was suggesting will actually significantly affect the timing of subsequent efforts and.

O

Organa Nokia and first of all, I was second with the website, which would send this liaison. We should specify things I, don't think we want to mix again, FM see from only broadband only figs, because I think we want solution that fixes both and one I, also don't like pseudo rash here, because for those who don't read this just go please and read this version versus previous version versus previous version. I've done 15 years of coding protocols.

O

The amount of changes between the drafts will tell to those who write software in wrote software in their life. How stable the solution is. The amount of changes is insane which is good because it's moving, but trying to suggest that this is done or even close to them is, is probably a little premature.

O

You know without detail. Reading. There is fundamental issues in the in the draft from protocol level that needs to be solved so I think we need solution. We have to take time to actually design it well and have a protocol that actually works, not a demo but works well.

S

I certainly have not claimed that these drafts are in final form or whatever that there is work that needs to be done on these drafts in terms of editorial and completeness, and things like that, it's not editorial.

O

S

O

Flow to new protocol, then I can show you how this protocol is even worse than what open flow was so and.

S

I was also going to say that well.

R

There are three implementation.

S

R

Related to the discussion that we have from the point of view of where they are actually carriers that want to have a solution. Now, okay, on the fixed network, the requirements coming, we looked into that requirements from for fixed network for Kanto Plain explained separation are much different than the requirements coming from a fixed mobile convergence network. So to be very different and I can tell you now. The the conclusion of the of the study will be that not be possible to have the same solution: okay, but okay.

R

This is something that is not yet say, worked out. What I want to say here is the timeline suppose that we like to to have a common solution, because that will be. Maybe you know something that even in that, for the fix never will have to use a very complex, complex protocol, suppose that that will be the case when the solution will be ready, I mean according to 3gpp, say timeline.

R

It will be after release, 17 or after least 17 will be after those 21 carriers that want to have a solution now, I mean now or next year. It will not be possible to use that solution anymore, so they have to wait a very long time until the GP comes up with the solution. That will be say a common solution for everything. So.

L

My comment is, we: are you know, putting this whole umbrella, calling it fixed mobile convergence? What we presented here is a multi access bng, you remove fixed mobile convergence as just a terminology, and you have different interpretations of that today. We see customers deploying bng with fixed access or fixed wireless access. When you look at convergence as a whole, that is also integrating broadband with a 5g core, which is slightly different. So I would say that what is presented here it only works for Ethernet access on a B and G.

L

It is not addressing the multi access part of a bhg, leaving even convergence aside, because convergence can mean different things to.

G

Different people so I'm cutting off the line here, so the three people can can still talk. Okay, so so yeah keep keep your comments. You know under a minute. Okay,.

P

Okay, yeah ninja, Holly, again I think Donna came back to your slides of the liaison to faciliate. First, a liaison, yeah I do believe this liaison is still valid because if we go to the secondary, so it's not a replacement of this Rosalie, though I think the first is encourage ITF to do the work, and the second is more information about. Okay, we are doing the FMC stuff. I, think that country I see that this clear requirement and also operator and the winter showed the increase and have also the implementation on the market.

P

So people needed that. Okay, this one perspective, we're not you know if we send a laser, I'm, okay, but not send liaison to say. Okay, we are trying to you, know, have some unified the protocol and give us that we can send liaison back to I PPF to clarify okay, this one first, why is still valid? So people can do that. Work and I think that we are not against a scenario of FMC it's a kind of new work. We can do that.

P

You know collaborate with everyone, I think here we are, but for we need to clarify with what is the short term target laser.

G

Work where, at the end of the session, so yeah I should align.

P

Off so it's my go ahead.

S

G

Good point: thanks: hi.

S

Dave Allen Erickson, also the wireless wireline director of broadband forum, a bit of context as to the complication that we're discussing was that one of the requirements for FM C that was brought forward by the the ten or so carriers that requested it was they wanted support for existing our G's, which meant that what we were going to end up with was a platform that integrated into the five key core, but also would terminate the existing suite of access protocols such as IP, OE and pppoe.

S

Hence the concern that I raised in Montreal, which is we really have an opportunity to jerk the industry around here by having many protocols that essentially support the same user facing functionality, and this was part of the motivation for the second liaison that came out was we have this issue and we really want to get our heads around making sure we're actually asking the right things of the industry.

S

You know we are and I just don't know of any other way to phrase that, in terms of trying to you know at least provide some clarity as to why there is this. How this situation has emerged, so that's what I wanted to say: welcome.

K

Victor to Tilikum I just wanted to second, the notion that fixed mobile convergence is not as straightforward as many people like to believe, because there's a whole class of products that simply aren't there in the mobile world like business access.

G

Okay thanks so we're closing out the session here and we'd we'd cut off the mics, so no session is over sorry, but we'll see you on Thursday. If you haven't signed the blue sheets, please sign them.

A

So so far, no no! So the conclusion is both group as much as you would like to see convergence. There is no conversion yet BBF if you have to come an advisory, so we see space for both groups to continue with work. Meanwhile, absolutely and we are going to open the agent, our video, so hopefully there's more clarity by next eight year and by the way they call us slow and.