Internet Engineering Task Force 99, 18 Jul 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF99-PCE-20170718-1550

Description

PCE meeting session at IETF99
2017/07/18 1550

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

A

I, don't see you, you know, we should I think it's the brakes.

B

We are giving couple minutes to Deborah, but we're going to start.

A

B

Hello, everyone: this is the past competition, a man working group meeting.

B

So you should be familiar with the note world. This is an updated version, so it's new for this week. Please be aware that there is this new mercy 81-79, which mentioned some new rules and policy, so make sure you're aware of the new content on that. You abide by the rules.

B

You may also be familiar with the usual command session, with the mpls on SECAM session about young, on which happening on Thursday. This time also tears are forged mentioned teas teas is in charge of the slot, but this is a common start to discuss crosswalking group about young models that could benefit from a coordination there.

B

So from the ministry perspective, you are also aware of the usual blue sheets. Please make sure you send them down. We need to identify how many people are in the room to be allocated the right size for the rooms over the ITF meetings.

B

Sometimes you don't have the same level of room size in ITF, I'll tell so make sure your seat will be available next time. Four people will come at the mic. If you are going to present, please make sure you are in to inside the pink square on the floor.

B

Well also, broadcast is also on the audio. So, even if you aren't presenting, if you want to make a command rise, a crave question or anything related to the presentation, progress, please make sure you correctly use the mics in the room.

B

Don't forget to state your name, people who are attending remote at this stage. Many more later, we will appreciate that you state your name before you start your comment.

C

So I just wanted to check. We have some volunteers to help with the minutes. Dhruv is helping remotely but locally. Damn you volunteered, so we're going to be taking the minutes in the ephah part. If you want to stay involved in the working group, please head on over to the ephah paris we're presenting you can write down what's happening in the working group and help us all keep them innocent today. Thank you.

B

Still about diamond roof, so you may be aware that then has stepped down as a secretary, but you means involve, as you see is doing minutes today too. So thank you for your secretary well done and thank you for all the upcoming work.

B

It has been, and you will still prefer to repay you so drove who most of you should know has agreed to the new Paz competition element working group secretary. So unfortunately it can't be there at this time, but, as you see, is connected you'll be try to be trying to present remotely later. So. Thank you all for agreeing to be the new secretary, and we appreciate your effort for the PC working group now on in the future.

B

If you reminder about the mailing list, we still feel that the mailing list is fully used to address, commands, resolve issues raised.

B

Pin points or anything so please be aware that the list is necessary to track the working progress to church the consensus on some item to be aware of the support hot topics. So, even if you consider that your work is progressing remind your culture, that many things should be sure on the list to make the working group aware of your working progress on make sure that everyone is aware of what's happening. On draft on everything related to the work in progress we may.

B

Depending on the agenda, we have used that quick area also to allocate slots so make sure that you don't fall into the wrong category.

B

We have this slightly lighter agenda because we're allocated more time than we were we had requested. So we hope that we won't.

B

Consume the fool to horse trot, but in case we have some spare time. So don't think we need to bash anything unless someone want to so can move on about our internet rafts. So we don't have any new FC since Chicago meeting, but in the background it's been progressing a lot. We have not less than four draft in years, detours queue with combined dependencies to each other. So we have to resolve that package pretty soon.

B

We also have three ID ideas with the iesg, so they've all told us that one of them is scheduled in the IE t th at on august 3, which happened to be my son's birthday, and we also have some other drafts who are ready to move forward soon.

B

Also with the working group, we have a draft which is waiting for an update after the latest review. I sing dance was da dieter, so for a matter of the process, we need to have an up-to-date draft to move forward. I.

D

Daniel King, yes, so kind of feel a sense of deja vu here, because I I think I was planning to submit a new version after the last ITF, but things just got a little bit busy. So for me a Copa sorry, we have a new version. I need to review it with one of the implementers that person happens to be Dhruv. Who is not here this week we have already spoken and we are planning to catch up next week after the ITF. So we review that and then submit target end of next week. Okay,.

B

Great thank you for the feedback, who have some other draft which are ready for shiver'd review. One of them is waiting for the others, so I hope that summer time will be the right time to share the reviews or some of them. One of them has been identified with an action item doing walking rascal. So it means that the recipe said attack needs an update before moving to the Shefford review, but tomorrow of process time mainly I think the author's came into an agreement on that. You want to come on. Come on that yet.

C

To comment on LSP setup type is a co offer and the remaining issue came down to wanting to be explicit about whether a PCC support set up by RSVP or not, where I'm considering either making a number quiz compatible change to the draft or doing something else which is kind of sub optical, optimal protocol wise. So really we need to check with the implementers about deployments and whether we can make my change and that's that's what's weird alight, but after we sold up and it's good to go we're hoping to get that sold very soon.

B

Okay, so we can expect to maybe an email with the to the dollar list soon to judge.

C

Next step is an email to the list, I think just just a close down issue which there's nothing blocking that up and my foreground tone.

B

Okay, all those who have a cue for working with last call one of the I do is spending the the previous one which just mentioned on the other. One is pending refresh because it's expired so before starting work in Glasgow, we need a version which is still valid.

B

We also have a bunch of drafts which hunt on the agenda for today, two of them are related to a CT and work which is in progress. Also in T's for balls. There has been some text change so moving forward with some walking progress there. We also have a piece: a young model module which has been a baby to be compliant to an mga, has many of the routing area young modules these days. So what is a piece of young modules is catching up with the new requirements and on that TLS has been considered.

B

The Associated RFC for PCBs in the digital, Qi, guess or not with Deborah, so make it's becoming consistent with what we have in the p-side toolset.

B

There is an open issue that maybe growth want to come out about, but the notification there. Maybe that could be a global question. That's on beyond piece F itself, so I don't know if you've come at something better I.

E

A su ID mailed, a question to the yang doctors as well asking what is the guideline with respect to? Should the models have notifications or rely only on the yang push mechanism? I have not yet get a feedback. I will try to ask one of my co-authors to catch the yang doctors this week and try to get this result.

C

So other things not on the agenda for today V the stateful PC, auto bandwidth, has recently been updated. Addressing some outstanding review comments, a few editorial changes in adding default values for parameters, and the authors are at this time, I believe requesting the working group last call so I think this mistrust seems to have been stable for quite a while and if, if it remains so, then will will happily us issue by last call. But please, if you haven't reviewed this yet then do so and send your comments and suggestions to the list.

C

Staple PCE with points and multi points has been updated recently to align with the RC 6000, a six biz draft and the changes to staple piece, evil worm a prior to its sort of preparation for the RSC editor and again, unless there are significant comments on the list and will be moving about to working group last call reasonably soon.

C

So overdrafts, the experimental code points draft there have been minor updates that the authors haven't received much feedback and they think, but it's going to be ready for working group last call, and so this this one I think this is a high priority for us. We've had issues with code points in the recent past and nothing. This draft will help going forward the process for sorting those out. So we are going to push that forward as hard and as soon as we can.

C

So. If anyone had thinks they're going to have anything else to say about it, then please do so in the short term. Before we move it on and request publication, the Association diversity draft has been presented. The last IGF. Not this time, no change seems stable again. A Association policy was recently updated. No requests to present this time same for staple PC, gmpls and we've recently adopted the LSP scheduling draft following the architecture working tees. There's a new working group doc.

C

Barris documents are expired, some of them I think just need to keep alive like the Donna's already addressed, the inter area is applicability. The GMP last piece of extensions I think is probably waiting for the Shepherd before the the next version is submitted.

C

God, the w.zahn RWA I think is in the same position needs to be issued with a key for life, but it's waiting for the GMP last piece of extensions to get shepherded and hierarchy. Extensions. We're ready to do, but working group last call on that. It just needs the the update to be done.

C

Dan says end of a week, I'm happy. Thank you. Dan.

C

A couple of documents we think are orphaned now, so the Pte remote initiated gmpls LSP, has expired a long time now and we haven't heard from any of the author's in a long time. So is there still an editor in charge of this? If so, please let me know now or let us know offline. If not, then this may have no future and the the other one is very PC enhanced errors which died and then was reborn a few IITs ago with a new editor gem, but gem has moved on again.

C

So once again, this document is treading water. If anyone was to pick this up, then please let us know otherwise again, this one won't have a future.

C

So that's a working group status, any comments or questions.

E

C

C

Okay, so we'll move to the first presentation.

C

Okay, truth: I guess you have to shout at me to move the slides on is that right, yeah.

E

Allu yeah, okay, so this is the Association drop and the base Association drop has been a working of document for a while. It's just that I have joined as an editor recently, based on the various comments that bunch of us who had other Association types documents wanted the base draft to, and also after discussing with the existing authors, we have made this update next slide, please so a quick introduction.

E

This is basically a generic mechanism to group set of LSPs in the context of pacer and of what we do is you can group set of LSPs as well as of attributes or policies? So that's why we have the policy Association draft and diversity, brach, etc. What this job does is it creates a generic Association object and that object can be carried in various P sub messages.

E

Like update report initiate M request, it is the job of other documents to actually go ahead and create new Association types, and we have two working group documents, diversity and policy and bunch of individual documents like protection by direction and BB, and something which is on agenda today for multi-layer as well next slide.

E

So what we did in this document, the major update, was that we kind of described dynamic associations and operator configured Association explicitly in the base draft. This is something that was happening. Why? Because policy? Let's take policy as an example, in which case the policies was pre-configured, so that was an operator configured Association, and then there are some Association like protection where you just enable protection for a particular tunnel, and then you have bunch of LS B's, which are dynamically belonging to an association type protection.

E

So these two different associations were already existing within pizza, but we did not talk about it in the base association draft. So what we did this time is explicitly say that there are two types of Association, some associations which are dynamically created by P sub peers and some switch some which will be configured by the operator and clearly set it out that what is the mechanism to do both? What will be the differences in each of them? So just to compare the two in case of dynamic Association. Basically, the association's are created dynamically.

E

We use P sub protocol mechanism to notify the peer. That is this. This is an association, and these are the bunch of LSPs that belong to a particular Association and the Association identifies those are picked dynamically by the P sub speaker and the association is associated with the LSP State, so till the LSP exists.

E

Association information also exists in case of operator configured association. What happens is that the association information needs to be manually configured by the operator. He should configure the association ID the type, the source, all this information, and then we can use precept as a mechanism to notify which LS piece needs to join, which Association, which are pre-configured on the P set appear, and these associations need to be manually removed since operator is the one which has configured it, but dynamically LSPs can join, or this join this existing operator configured Association next slide.

E

So this leads to an problem with.

F

E

Four Association types which may have both operator configured as well as dynamic. We need to worry about the Association I did a range of Association ID so that there is no clash between a dynamic Association that is picked by a peer dynamically and then some associations which are on figured by the operator.

E

So to solve this, we propose to have have a operator configured association range for each Association type and then communicate this to the peer so that when a dynamic, Association ID is pegged, there is no conflict, and this is basically carried in an open message and you can see the TLV format on the right hand, side. This needs to be done only for Association types that will have both dynamic and operator configured associations, for example. If you are protection, then you don't need to worry about it.

E

All your associations are always dynamic, so the full range of Association ID can be used by dynamic itself. This needs to be done only for the Association types that could be brought, and this is being clarified in the document next slide.

E

One uh one thing also, we did was we kind of added new error codes in the base Association drugs. We were seeing that the some new Association types were adding error codes, which are quite generous and are applicable for any Association time, so we kind of moved them to the base draft. So these are some of the generate errors. Errors like Association type, is not supported, or there are too many LSPs which have joined an association group, making it unmanageable to avoid any issues.

E

Sometimes the number of Association groups itself is too many in case Association should be configured before or known before. The Association itself is unknown. There is a mismatch of information between what is locally configured and what the peer reporting. You may remember that this was something that was written in the diversity draft, so we considered that this needs to be in the base draft itself, so we have moved these error codes here and then also a sensational information mismatch between the past information and our latest information next time.

E

We also clarified some of the processing rules, especially with respect to what should happen when the session goes down. What is the time that the Association information should be cleared since the associations are a properties of an LSP? We linked it to the LSP state itself so similar to the handling of LSP State, which is based on the state timeout interval value. The same procedure is used for Association information as well and some associations, and if the state timeout interval is infinity, that means when the LSP state is kept forever.

E

In that case, associations will also be kept forever. We also clarify what should happen for at the time of the delegation. So if you have read elevated LSP to a new PC, the old Association is still valid until the new pcs explicitly removes that Association. So we kind of cleared all those behaviors and updated the processing rules for a source base. Association next.

E

Just assembly, what are the updates? The updates have dynamic and operator configured Association explicitly spelled out to handle the case of ID range conflict. We added operator configured association range handling. There were some restrictions in the base draft. Earlier, for example, the base chart said that it's only a PCE that can add associations with LSPs that are not from the same head node. We removed it because if you see the diversity use case, there is a use case for having an association there as well, which is explained in the diversity drop.

E

We also had some restriction on who could be the Association source. What should be the IP address that should be used in Association source, so we removed this restriction so that, in case of a multiple PCE or a multiple PC is acting as a backup to each other. A common virtual IP or a other IPS could be used as a cessation source, rather than a strict, PCE IP address, which could be useful. We added errors, which you have seen and also updated the manageability and security consideration section about these drafts next time.

E

So this is the node to other Association routes, authors this we have discussed with them offline as well. What needs to be done here is that each Association draft, which defines a new Association type, should explicitly state whether this particular type is dynamic operator, configured or both and in case of both clearly set out. What is the range they would like to keep a site for operator configured Association note that this is a configurable parameters, but we would like these are authors to stay.

E

What should be the default value if things are not set next thing, so the this has been already discussed with the Association draft authors, we also got comments from Stefan rakesh Mustafar. All of this has been incorporated now at this stage. We would like more eyes from the working group and see whether what we have done is okay and try to, since this implementation exists for Association also want to make sure that we get I in a earlier location and think about moving this to last call as multiple association documents depend on this. Thank you.

C

The tree this is John Hardwick and just a technical question on this draft. So the so, if you have a dynamic association group, is the Association group ID taken from the available space on the headend PCC? Yes,.

C

And what about the case where you have an association between to LSPs which do not have the same head? End PCC, so.

E

In usually, in those cases, the Association source is usually the PC ID or a generic ideas. Never the PC sees IP address.

E

So what happens is since associations are identity for identified by association, ID, Association type and the Association source, so together they act as a key, so in in those cases, usually in a multi head case, it's usually the stateful PC IP address is the one that we use as a source or a generate IP address like 0, 0 0, or so that that's the thing where we remove the restriction on having the PC IP address or the PCC IP address as the Association source. So why are this mechanism?

E

Things can be taken care.

C

So, in that case, this association group, ID, is not taken out of ahead and pcc's number space is taken out of the PCs number space, usually.

E

C

E

C

You just read the.

E

Meaning, okay, just let me clarify this a little bit, so the main in is if, if I'm a piece of implement implementation and I have to pick a dynamic association or operator, configured association might be set up at any time. So we wanna just make sure that the dynamic association and usually the person who picks the dynamic association, is usually the association source most of the time. So he is making sure that I am NOT.

E

Gonna pick an association ID that might be configured later or is being configured on another peer leading to clash and like no rollback and all those mechanisms. So the clear idea was let the dynamic associations we have a different range and the operator configured one have a different range, so there is no clash. I'm.

C

Curious why we didn't make those ranges explicit in the through I Ana, or something like that, rather than having to serve this sort of complicated, her association type / PCC configured range like it would seem simpler. Just to say you know the first half of his space is operated configured. The next half of his space is dynamic. Why do we need the extra complexity yeah.

E

This is exactly what my first, like the first draft that I prepared, I I tried to do, but I got feedback from various Association authors who, who was saying that oh, we only have most of our most of us are only using dynamic or only using operator configured. These are limited sets of associations where we have both. So if we have to sacrifice the association identify space, if we have a fixed value, that was something that was not acceptable to some of the authors.

E

So to allow that we said, let us have this range and let the default value be specified by each Association type. So only if the operator is manually changing the value, then you need to carry this TL these. Otherwise the default values- and this will suffice, but let it be per Association type rather than a generate value.

F

This is Rakesh Gandhi from Cisco, yes, so association ID range is, the context, is the Association source and Association type? So, irrespective of, if is the same head in or different hand ends that's the context, so you had to allocate association, ID or range.

F

You know, uniquely on two sides if you need to be or at the pc, but the context is as drew was saying that association, source type and ID are the keys, so it has to be unique, and the second comment is that for bi-directional LSPs we do have a two hand ends, so we can initiate the LSPs and we need to associate and that the bi-directional ESPYs we don't have dynamic association. Something is really the operator configured, so we didn't want to have this kind of restrictions where some ideas you cannot use it.

F

It's only for operator, sorry only for dynamic right, so we wanted to have the whole whole range. This is one reason why we have it the way it it is.

C

Okay, I get both of our Vice points. I guess it's, it just seems quite complex. Robot seems like a fairly simple problem: okay,.

F

B

So we need to move on. The next presenter is Daniel II. Thank you. God.

G

Hello, what I'm going to present you? It's it's a kind of experiment, but it's the wrong presentation.

B

That's the one this.

G

Is the one he realized it incredible.

G

G

Introduction the proposal here is to add to matrix to piece up. First, one is the RSI rate, bandwidth of a part of an entire path at a given priority. Basically, what it is, it's the minimum value of the Eraserhead bandwidth at a given priority among all the links of a given part, the other one is the path for a doodle bandit, it's exactly the same thing, but it's referring to the physical available bandwidth along that path. Why the proposal twatted is to new matrix.

G

There are three main reasons. The first one is that one matrix I return the result of the computation. They can be used to know how much traffic can still be routed over that part. There is an example coming on which which explains a use case in which this is extremely interesting. The second being optimizing, a path against a reserved word or residual bandwidth, allows a better usage of the network resources so basically pure optimization, the third one, putting constraints on the value of our survey. The residual bandwidth helps prevent it.

G

Bottlenecks obviously background, so there is something similar in RFC 5555 41. There is an objective function called the MVP maximum residual bandwidth, but this is something that allows you to compute path, maximizing the minimum value of the residual bandit, which is more or less what we are looking for it.

G

As a result, it turns up the largest but neck in the network, but what's the problem, the problem is that this one is not exactly what we need and it's a an objective function, not a metric. This. This means that this is a parameter that cannot be returned as a result of our competition, then only the physically available bandwidth is taken into account.

G

While we said that we would like to have not just a physical bandwidth, but also the reserve bandwidth at given priorities, and it is not possible to put constraints on the bottleneck of the path. What is the use case, hierarchical, Sdn or hierarchical path, computation?

G

Basically, the the use case that we started from when thinking of this extension is a hierarchical, a PC image in any city and scenario where.

H

G

Topology is used up ah I'm the hierarchical PC I needed to compute a path between one node in the first domain and another not in the in the last domain. I have to ask all the different pcs for a path computation in their domain.

G

Okay, I need to allocate other traffic with the other territory, with the same characteristics am I ever to interrater these this process again and again and again what if I can collect an amount of bandwidth that is still available in my first request, I can save a huge number of requests, so we said: okay, let's try to see if this makes sense, we built a simulator, it's it's a simulator that simulates a Manhattan like network domain, where all the domains are black, meaning that just the border nodes are presented to the hierarchical PC.

G

It allow Sephora setting up a teardown LSPs it simulates bloody removals and so on and so forth, and so we did some simulations, which are capped and okay, no worries. So these are the results of a simulation in which we have domain network domains. Ten by ten nodes up in a monitor like scenario- and we did the simulation with three by three Network domains and four by four 1000 parts. You can find all the details there what's what's interesting. We did this simulation with the three different scenarios, the first one. There is no caching.

G

Basically, we want. We are locate 10,000 parts at every time. We ask all the child a PC if it is possible to compute a part. Those are the results. So in the case of three by three natural domains, we have a thirteen thousand request. Meantime, three seconds and alpha and eight seconds as a maximal time.

G

4X4 you see the numbers over there with 35,000 and so on. Then we did a second simulation in which we we did the caching of the result of the previous path. Computation in this case, I'll try to explain again. What does it mean? It means that we ask you for a path between a and B, the part most likely will be I, don't know ten gigabit part or 100 gigabit path. We just need a few Mac's. The second requested needs a few Mac's between those dozen points and we go on the.

G

The second scenario is the caching without residual bandwidth. So we just keep the the computed path and we try to reuse it. We might succeed, we might fail in case with we do the path computation again.

G

The third one is even better because we keep track of the path that we asked for the first time and we keep track of the.

G

Bandwidth that is still available in that path. In that case, suppose we have a scenario like this one, where the bottleneck is at 20 Giga, and we make a one gigabit request for 20 times we we know for sure that we will succeed in the activation without the need for another path computation, and we already know that the twenty first requester will fail. So in that case, without waiting for the crank Beca, we will directly ask for the friend new path computation. So again, what are the changes to the protocol that we we are proposing?

G

First one battery unreservedly that the given priority K? Suppose you have this Lincoln? The value would be 20 gigabits, this path. Sorry, nothing then let the pot residual banded in this case would be thanking a bit over those two links which is associated that to the unturned path. The encoding is a super simple. It's it's just.

G

32 bits added to the metric object defined in RFC if 54 40 and that's it so basically, these are the numbers. We thought that with these numbers, it could be worth trying to propose them. This kind of this kind of extension, you see that in the 3 by 3 domain, we go down from 13,000 requested to 3600.

G

That's the reason for 4 proposed in the draft next steps. So it's a simple extension. There is absolutely no that no dependency through very improvements. Those are the numbers now the question: is there any interesting networking group / implemented in these? These extensions.

B

And if you back from the room or from remote attendees.

C

John Hardwick I've got a question just to clarify Danny Ally, so the applicability of this, if I understand, that is cases where there's really only one source which is requesting the LSP, because you need to be able to rely on for residual bandwidth that has returned not changing through some other source as gobbling bandwidth. One.

G

Sorts of meaning it is single Iorg, RPC, yeah,.

C

G

C

Indeed, in a non-hierarchical case, you know you can have multiple pcc's setting up LSP through the network, so in that case you know your bandwidth available is going to change after the computation. But yes, it was so so so I guess I'm asking how how broadly applicable is this. Is this like an arrow, really narrow thing for a CTN, or is it like actually.

G

We did we didn't think of multiple sources. Probably I mean once the information is propagated from the child PC today, our kicker PC, if there are other hierarchical PC, is that like a PC, it needs to propagate to the information to the others. This could be. This could be a solution, but the idea was a single, a single source.

G

Okay, thanks I.

B

Think we have a in progress Daniele if you can stay there for one more minute. Please hi.

E

Daniel II, so I think what John asked was like first part of my question. That is I. Think in this case this will only work, even if you are having about a single source. This will only work if, after I have made a request and I have got the residual bandwidth. I know that nobody else is making a request, because even if somebody else makes a request and uses a more bandwidth, I am I, don't I would not know, but I would like I wanted to understand that.

E

In your case, you were saying that you will. You know that for 20 more requests things are available, but at 20 first I should do path computation. So if, if in this proposal, we have a mechanism to figure it out that what is the time when which we know that the bandwidth is over? Basically that's what you want to do.

E

The thing is doing it via a reply mechanism, which is at max the state at this moment of time and with no guarantee that this is gonna continue, because this is at the the proposal is still stateless here. So I am a little confused by that I will give you an example. We do delay like this right. We have you compute a path.

E

You get end to end delay, but that should be only used at the time of path computation and then we need to rely on telemetry or some other mechanism to know what is the actual delay later on? Not the delay that I had at the time of path computation, so I am trying to apply the same logic here and seeing whether what we are doing here is a right or not.

E

Well, actually,.

G

If, in that case, if you're lucky, you say vibrations between a day, I ARCA, Cal, PC and of the child PC in the worst case, er, you don't get anything worse than with. After these. These obsessions that I, because okay.

B

Thank you and if you want to go deeper, please use the list. It's there. For that purpose. Next presenter is young or the flexible grid extension.

I

Good afternoon this is Jung Lee, yeah I think I'm going to present Pacific station for flex grid networks. We have many multi-vendor authors and research who implemented this feature already.

I

Yeah I think you know: I see pieces of extension for flex grid as early as 2009 and obviously the other story, and but now why we are presenting now because of maturity of Pisa flex, agreed a framework in secant RFC 67 to 69. The eighth has been published for a while and then OSPF T and rsvp-te, or so it's very close to maturity. I think some of them has become RFC, I, guess and or f6 you. So it's the right time and also we have deployment of this technology into commercial networks.

I

So what are the flux grid networks? I think we are familiar with fixed grid, which is known as Douglas on wavelength switched optical networks, but it deals with lambda band uses a fixed if this 10 gig system, it's a 10 gig system.

I

But here we are talking about you know: flexible grid, I, think ITT on Gina 9, 6, 9 4.1 and see that a 72 they define our new DWDM agreed, which is called flux great by defining a set of nominals, essential frequency and then channel spacing and up, and they bring the concept of frequency slot.

I

So I don't want to get into detail about this technology, but some of you may not be familiar with this. Technology is I just want to give some flux grid exemple, so basically for the flexgrid DWDM grid. Are you allowed frequencies? Slot has a nominal of frequency, central frequency in terahertz, defined by the number over there.

I

193 that one plus n times 0.006 to 5, where n is positive or negative integer with respect to 0 and that 0 0 0 6 2 5, is the nominal central frequency granularity and the slot, which is defined by another parameter 12.5 times n. Where m is a positive integer and 12.5 is a with granularity. So if you look at the anchor frequency, one died 193 that one on the circle on the bottom and you can have m equal 4. Then we have minus 4, n plus 4, so it a Q, PI's 50 gigahertz floodways.

I

So you can have a flexible floodways if n number increases. So that's the basic idea of flex grid networks, so in in p-set context we basically add one object or a spectrum assignment object along with RP and end points and other optional objects, and then we define several tlvs under that the spectrum assignment object.

I

So this is how our spectrum assignment object looks like.

I

We have a two TLV define frequency, selection, TLD and frequency slot restriction, constraint, EO v and then the corner on the mm indicate mode, which is explicit label control, ELC mode. We are debating whether we should support labor set distributed hop-by-hop.

I

We are at this moment proposing only year, simians species of science exact, a frequency slot to be used at each hub instead of each node kind of decided from the set. The PC recommends, because that's had some rs.50 implications, so we don't want to depend on something that is not available at this moment and the frequency slot selection. Tlv look like that. This is basically how to select a frequency slot. If you know our debris assignment as a land assignment or there is a way to assign lambda.

I

So it basically suggests to PC see how to select a frequency slot based on n parameter, so we have a first fit or random or other method. This is try to avoid the fragmentation of the slot assignment on the the fiber and then the frequency slot restriction constraints is basically kind of giving some tunable range because it may not be all tunable for all spectrum, so it gives it gives some some frequency slot restriction field for each link identifier. So it's a kind of recursive.

I

You may have multiple links and multiple restriction in one shot, so we are using actually what SPF are developed on the frequency restriction fill and then frequency allocation is basically reply to the request.

I

So some open issue is for action field. In terms of labor said. We only propose to support. Didn't that encoding. You know, I think it's which is very consistent with the flux grid. Young work as well in that is taking place in parallel and yeah. Don't need for frequency slot on location.

I

Tlb is subject to for the determination, but this for in the current draft, and there may be as some other issues but just wanted to propose that this might be a right fit in in the right time. So any interest party is welcome to join. You know, working with us.

B

Any question from the room well I, have one actually about the frequency slot restriction. Why don't you consider reusing the generic label set mechanism to express this restriction? Should we do but.

I

We only support in math out of so many actions there.

B

Are four or five even pre use the generic mechanism uses? You use the idea with a specific encoding right, so the.

I

Generic yeah there.

B

Is a more generic that is more technology agnostic that could be reused to achieve that same purpose. So why do you specify your new TLD there while you could achieve the same? Has any other technology? Oh that's!.

I

Good, we have a more field because you have to. If you have n and n field, you have to specify pose mm-hmm.

B

I

You know so existing that current has only one labor right now.

B

The label in WDM allows you to in flexi grid, allows you to specify n on M. So it's a specific set of label that you use as constraints that I feel that the labels that fits there exactly.

I

That's what you're proposing? Maybe we are using exactly on label 7 encoding, but out of many actions, which is only one didn't a mapping. That's what I'm saying yeah.

B

Maybe I mean again they'll get right, not abuse. Well, ok,.

I

Read the draft right.

B

By the way, you say continue to meet you de Graaff, you can with that ISO. Also in the draft that you are mentioning some pass air messages with writing program, error codes, we don't have passer in pset, snippy message.

B

I

Thank you thank.

B

B

Next presenter is far away.

J

So my name is family from Asahi, so my talking is about her. She senior Martin our arrastia association.

J

Okay, so this is the zero version crafte, and that is the first time to present it in this meeting so document the proposal, our attention to PCP, to associate a group or or Martin our RSP. So this Marty, never SP included one upper layer RSP and several nor nor nail her errands if she's. So we we have a to use case for multi, narrower RSP and Association, so, firstly, is used to afford and why the adjustment so and just here for PC, you provides a get to that.

J

Yesterday, Pennywise, for example, we wanted to imagine apnea RSP, and so, if we used to associate group within- and we can add, adjusted apnea area under the nor our north near actually at the same time. So this is the first case and the second usually reserved for the chaining of optimization on, for example, if return, if then, someone would know and Noah nail Archie is thinner, so we can use the associate the associated her type of sp2 and to offer him optimize the apnea I'm Neil and I'm Neil Aris P.

J

So this is the second is K so for our mmm and for our multi-layer SP Association. So mmm this is the assertion assertion that Association type so trace optional assertion over to the type to carry the post in the IP of IPO for and I basis, so forth, associate hypo on waste. We can say that it can be Tameka or operation competitor, so for the Ranger, I I think, oh, we can discuss innate her so and this is a new associate terribly.

J

So the challenge is very simple: with the fan or Nagar to indicator so up ranae are. Are she also ignore ours? He yeah. So this is the intentional operation, so we sin attentive to our martin.arg.

J

It's a same of rate of its associated group, so a socially obligated a way of being carried into request, staining reporter and updater and initial message.

J

hmm So once a a group award Martin never asked he is created at the Opera. There actually is associated associated with its related at know. There are P. So this is a my. My presentation for is Proctor, so necessarily is to discuss with associate professors with others and comments.

C

Any comments from the room like sort of interested to get a show of hands who is read this document.

C

Okay, so I see I, think I saw three hands not confidently raised. I think we need to see a little bit more engagement with the working group or we can really pull for adoption on this.

B

Young are you going to present next one.

I

This is young again this time, I'd like to present piece of extension for stitching LSP in hierarchical, stateful, a PC environment.

I

Yeah, basically, this is high-level, stateful HPC environment. As you see here we have multi domain and then we have domain LSP and there are multiple of them, but we need to have a mechanism to stitch in this environment, yeah and I.

I

Think there are two approaches for into analyst: be contiguous, LSP versus Protomen LSP, but I think we know that photomania LSP is para one with various reasons and the setup with photomania LSP setup is happening at or in Bodo, node and needle mechanism to stage the Protomen LSPs, and I think the motivation here is not to invent a new wheel but I.

I

Think last Chicago meeting Julian presented sketching mechanism for a P artists environment, so we'd like to use the same mechanism basically, but you know different context: the RPC is a peer-to-peer PC, but here we have a hierarchy, so we would like to use the same stitching label definition that defined in Julian's draft, and this is also applicable for actn. We have multi LSP environment, how to stitch there.

I

So basically, this is a high level mechanism. If you have a two domain, entry, Budo node at I plus 1 domain, basically recommend the stitching label for the incoming inter domain link identifier and then it needs to propagate to the PC, I plus 1 and T CI plus 1.

I

We need to propagate that to the hierarchy, the top-level peers on parent PC and that parent PC need to propagate that to PC I, which is a previous domain and then to the entry, the proto node of the domain I, so that domain, the head node may have segment routing mechanism or RSVP T include the stitch label recommended by the previous domain in this set up.

I

Basically, that's the idea. The procedure here is basically the parent PC request to the to initiate LSP.

I

It basically confuse domain sequence, optimal domain sequence based on the customer request, and the figures are what would be the right sequence of domain and then it contacts each domain, the PCE as to what to do and then, basically, in this diagram we have a three LSB segment. So those need to be some are stitched. The tester basic idea. So, in this case the parent PC agro recursive.

I

You know backward first talking to the last PC domain of that and to analyst key and then basically PC propagates to the entry Buddha node to assign stitching label and then, as you see here, BB and three three or signs stitching labor 3 3, which is incoming label to that domain. And then it sends sent back to a parent PC with the r ro.

I

You know s: 0 3 3, +, b, + 3 3 entrance and then the last one and then a parent PC or get that information and then parenthesis propagates that to the previous PC and then talking to the Buddha note entry below note of that domain en 41.

I

So the ero basically BN 41 to be and 42 and stitching labor, 33 and BN three free to complete that LSP segment so and charka see further propagates, that to OB n 41 and then 33 is encoded in the euro in the rsvp-te and propagate to BN, 42 and then 33 is a part of the label, a stack in case of segment routing.

I

So you do kind of recursively all the way to the first domain and we can have n n sketching mechanism, so this doesn't require any new method type or any new other than the two Jen draft. That's Giuliana's cause of it, and this is a key part of ICT and applicability to PCE and we actually work with the other authors of similar draft. And so that's the last.

I

The point: do you have any question yeah.

B

Generally contributor to the draft do Joan that you mentioned in your presentation I'm glad to see that you consider that the idea we meet is now raft got interests on that you you want to consider it for your proposal. However, looking at my last slide from the presentation in Chicago, we mentioned the intent to cover the rocky core PCE case within our work, so I wonder if I should take your draft here as a proposal to work all together or how has a counterproposal to to fight against that idea for the future.

B

So I I just don't know exactly how you should consider that.

I

So I mean I'm open for any possibility. What is the best way to propagate consistent piston mechanism, whether it's a PR, PC or high accuracy, so I would work on that idea.

B

Yeah title of the draft beer PC the main idea: there was the stitching label on the cut points allocated to that mechanism. So whether or not this cop had to be in charge for the further world, we don't mind but the way it's progressing. There doesn't suit me as a contributor yeah.

I

If the trust combined throughout this PC, then I think we need to kind of rethink right because it covers more and is that you're willing to change the updating.

B

The title is not an issue: okay,.

I

No problem, yes, you are willing to work merging with the okay.

K

Just clarification when you traverse the third domain, the label you're pushing is not a cell, it's the banging seat, so you have a right reference. Oh, but the Texas I'm.

I

Into a reference, okay,.

B

I

B

Jo Marika again to add some comments about chess feedback.

B

The view one of our graph has been delayed also because we're looking at the ways to maybe merge with the binding label idea of propose something more generic to address all the related use case, binding stitching whether it is flat or Oracle whatever so I think there are some common interests there, but we need to maybe limit the number of document we are progressing in Parral. Yes,.

I

I think we'll talk offline because I think yeah, okay, just.

L

Just a one comment, and the intention of the draft is clear, but I think that you provided the example to explain the intention of the draft, but there is no explanation of the real procedure in the general, so I would suggest to to make some some description. That is before the example to explain the real intention, because you explained you list a lot of PC mechanism and so on in the draft. But the real intention of the draft and in the contest whole PC story. It is not so clear. Okay.

M

L

You start immediately with the with the with the example, but it's better to have a little section to to describe their the procedure at the intention. Okay notice, I can be done.

K

Depending on number of dementia, don't reverse your increasing number of labels under step? You might think about the MSD and probably describe how you are going to use binding sheet to expend. So if you cannot put number of labels media to traverse and turn pass, you might need to do extension somewhere in between or a priori, you hit the egress from particular than me.

I

We can discuss yeah I, don't think I understand. So we can talk offline. You may run out of labels. Okay, oh you may run out of labels. Okay, okay, we can talk offline, okay,.

C

Okay, so function.

B

Next presenter is herion.

N

N

Was having great fun, I was reviewing the experimental code, points draft and, and now you've woken me up. um So I want to talk about this draft, which has been around for a while timed out for a number of months and then I came along to rescue it.

N

What I've tried to do this time around is rewrite to inject a bit of excitement and and passion and update the process. The old process used to use specific messages and I've changed that for no new messages, but the purpose and functionality is the same, which is when we use PCE to control or set up an LSP.

N

We have currently no way of telling the head end of that LSP. What the purpose of that LSP is and that's kind of a whole we've lived with this whole for a very long time, mainly because it used to be the head end that actually asked for the path. So they had a new white wanted on LSP and then, after that, we've lived with it sort of because an LSP from A to B.

N

Well, it's probably meant to take the traffic that's going to be, but when we set up parallel, SPS or tunnels in the network- and things like that, we have currently no way of telling the head end what to use the LSP for so this document addresses that and the intention is not to reinvent or not to invent new ways of describing the traffic that will go on an LSP, but to pick up an existing mechanism and one such mechanism is defined for bgp called flowspec, but be very clear. This is not bgp flowspec.

N

This is simply using the BGP encoding.

N

We are not talking here about programming, the ASPRS for IP traffic flows. We're talking about telling LSP head ends how to behave so. The mechanism, firstly capability. Advertisement no point in in telling the PCC what to do. Unless the PCC can understand no point in asking a PCE to do something.

N

Unless a PC, you can do it so normal capability exchange, then we define a new pset object, called the flow special object and you can pop zero one or more of those on all of the usual suspect messages, and each object describes a traffic flow, so it describes a set of traffic that will go on the LSP you're dealing with inside the object is a single TLV.

N

Now that sounds like really stupid. Why don't you go straight into describing the traffic flow with multiple tail Viers? The answer is we wanted to break the the TLV numbering space so that we could reuse the flowspec numbering, so we needed to put some something in between, and so we've got this sort of container TLV, and so the sub clearly is that can be in this called flow specification.

N

Tlbs are a set of TVs that when you combine them describe the flow and, for example, those might be destination prefix or source prefix, and and when you add a number of them together, you describe the flow. So those TVs come from a range 0 to 65535.

N

Fortunately, BGP only uses the range 1 to 255, so we're able to carve out 1 2 to 5 five and say if you see one of those go look at the bgp registry and that's the type of flow descriptor we're using that we've then got plenty more for ourselves to describe new flows that are not used by BGP and an example of such a flow is for multicast traffic. So if we have a point-to-multipoint LSB, we want to describe that traffic.

N

Bgp doesn't care about that, so it doesn't have one we've also added one for a VPN route distinguisher, which means that you can say traffic for a particular VPN will go down this LSP.

N

So I did an example.

N

We set up a new point to point LSP and we want it to be for traffic for a couple of destination prefixes, so we would send a PC initiate message saying set up this LSP and here's a here's. A flow special object containing a flow filter TLV with to flow specification, sub TL V's that describe the prefixes, the verifying the hex. There is an exercise for the reader, it's probably wrong.

N

What do we still need to do? We still need to push on with implementations. There are a couple of people on the fringe of implementing for prototype or moving towards product. We need to put some examples in the document, because that will be really helpful.

N

We need to look at whether we simplify also streamline the main use cases, possibly removing some of the BGP flowspec things and a really sensible thing that was pointed out to me this week is during the capability negotiation. Why not say which flow specs you support and which flow specs you don't support. This is something apparently that BGP implementations get really confused about, and it would be really neat just to say straight upfront.

N

This is all I support, and then we have to consider the other big thing that again hits BGP when you have some overlapping descriptions of traffic, which one takes priority, how do I decide which LSB to put the traffic in if it fits matches to different flow specs?

N

It's not a new problem. We see it for BGP. We even see it for static routes when they get installed and what we need to write down is clear, unambiguous rules. Whatever we decide, they should be, and then lastly and the chairs, from help with this, is this in scope for the working group, and if so, is it something the working group wants to work on or should the proponents go away and sit in a hole.

C

And so on, the reply to a last question that um so I I think this is in scope. If we accept that LSP initiations in scope- and this is just a curl or it's about so I- think it's in scope and since we all worked on LSP initiation, I assume you'll want to work on this as well. Otherwise we only have half a solution right well,.

N

I I would agree with you, except we've got this far without needing now. I personally believe, it's really dumb that we've got this far with with people kind of cobbling things together with CL eyes or net Kampf and pset. So I believe this needs solving, but we are where we are and- and so that's why I asked a question.

C

So anyone else have thoughts a lot. They want to contribute I.

K

Think in stopping very much needed we, we tried to abuse Bishop before so I. Remember profiles. We had some vendor till with in recent droughts, so we need to do it's a question whether it's not too much and specifically mixing data plane with control plane I mean maybe matching con. R.G is my such a great idea before the rest. I think it's very much needed.

G

Daniela I agree with Java and just one question: I often with this binding, your core. Is it something that occurs often or like configuration so why I.

N

I imagine that this depends ok, it depends on whether you're using your PC in in a fairly simple way or whether your PC is very aware of what the traffic matrix is on your network and it's balancing traffic across LSP is and is, is totally managing the network. So ok.

G

And then in non-political, quick answer, Rizzoli well.

N

Ok, I will retaliate by saying what's the arrival rate of LSPs yeah. These are unknown questions.

K

Back today, the only way to get traffic into LSP if to resolve next hub right. When your next stop reserve after talent of the USP you send traffic over it. This gives you ability to not, to you know, go into BGP configuration start playing with next sub, which is about doing it today. So it's the only way to do it more granular, as our per next hop in VPN.

C

B

The next presenter is traffic in.

E

Right, so this is the solution for PC as a central controller. Next slide. So just a background. We have the architecture document which is there in the t's working group, and this has done working group last call already. We have a use case document which has been adopted a couple of ITF meetings ago and has been progressing well, and this is now in the PC working group, the various solutions meeting, those as per the architecture and the use cases which are specified in the t's document.

E

E

So this is just the sort of like the document map that we have in the current PC working group. The first document is talking in terms of a general piece, ECC mechanism, mainly for our hop label download, and this also have the base mechanisms like what is the changes in the messages or objects, as well as the mechanism to synchronize labels.

E

When the session flap happens or session gets terminated and rejoined, and all the base features for PC CC, then we have an SR document which only talks about the changes needed to handle segment, routing, srte, LSP and the label exchange make a label propagation mechanism for that. So for this we need to add a new piece of object and that's what's being done in the SR document, then we also have.

E

Then we also have the sync draft, which talks about the various optimizations that we can do with respect to sync similar to the LSP state synchronization. This is the label DB synchronization next slide. Okay, so in this slide we describe what are the procedure procedures involved, especially from the base document point of view. The description you will find in the architecture document as well as in the use case document.

E

The idea is the LSP is being provisioned as an explicit label instruction on each hawk based on the influent path, so each router along the path will download the forwarding instruction and also reserve any resources as needed, and the mechanism to do that is via pset. So piece up is a way to do that, and also the label space.

E

We need to take care it, so the router would give some label space to PCE to allocate labels from to make sure that there is no clash between a locally allocated label and the label which is allocated by the PC on behalf of the router. So this is a simple mechanism for how a PC, CC LSP is established next time in case of segment routing again the description of the architecture. In the use case you will find in the referenced section. The main change here is the SR label.

E

Stack is still downloaded using the existing mechanism. That is the segment routing extension which goes to the head node and on the head node. You can give the label stack. This is more about how the labels are distributed, that is the SR labels that Jason c-level the node label, those are assigned by a PC and distributed via the PC protocol. So the idea here would be that we may we may not need to use the IGP mechanism, that is on every node allocation of a s, ID and node label, etc.

E

All of this is done centrally by the PC itself and, of course, that will have some benefits that you may not need to configure on every router. Things can be done in a Sdn environment in a much more simpler way. So for this we would need a label map which is different from the download function that we had in the previous case, where you had an LSP for the LSP on each hop. You are downloading labels here. You are assigning a label map to effect and assigning that for this node or for this adjacent C.

E

This is the label that you need to use, and this needs to be sent on all peace obsessions so that all pcc's can see it and also we need to handle. How do how do we take care of redundant pcs and the label assigned by one PC is available unknown? Who are another PC and again. The label synchronization mechanism should take care of that next time.

E

So the extensions that we have are basically the capability, the first. We need to make sure that we advertise this during open messages for the base case. We have something like a label download where the label is allocated by the PC and via a new message. We call it in the label update message: the information is downloaded on each node along the path in case of segment routing. The labels are not allocated but LSP.

E

They are allocated based on the topology, so for a node or a prefix or an adjacency, we assign a label and then that label is notified on all the sessions that is on all PCCs to all pcs again using the label update message, but the mechanism is with a different object and other things.

E

Then we also need to make sure that we handle the session termination process very, very clearly so for this the procedure is set that once a session goes down all the labels that were received on a particular session or marked stale and and when the session comes back up again, we will try to synchronize again.

E

A special process needs to be in order. The SR labels, because SR labels are not for LSP, so we need to make sure that there is another alternative PC which can take ownership for those SR labels. So we have defined a procedure for that and the label DB synchronization the base synchronization is already defined and the optimizations are further handled here.

E

The label DB synchronization, is little different from LSP DB and that is also described in the next slide.

E

Next slide. Please, okay, so this is a the label DB synchronization procedure. So since the labels are located by PCE on that space, we need to make sure that how do we handle if there is a session flap or if a session goes down, so those procedures are basically listed down here. So this procedure is broken into two steps. The first the PCE will come on session up. The PC will try to on session. First sorry, let me start again.

E

So the first thing is that the PCC will mark all the labels received on this particular session as tail and then, when the session gets up again, the PC will try to update all those labels. Any labels that is still mark still will be reported back to PC, saying these are the stale labels. What do you want me to do?

E

What do you want me to do with them, and then the PC can take suitable action for SR label which are not LSP related, because what is gonna happen is that NS pdb synchronization will also takes place so LS pdb synchronization will also try to read a legate and made assign the same labels or use different labels, so that process takes care of the labels for basic mode, but in case of SR mode we would like the labels to be valid, irrespective of which PC allocated them, so that procedure is also listed out in which a particular SR label control might be given to a different PC.

E

For this purpose we have a labeled report message as well, so we have a label update and a label report messages described in this extension next time. So here you are seeing the message the idea is produced. There are two types of these messages. The one is the label download and a label map the label download is usually used for a per LSP basis. That's why it has the LSP object as a part of it, but for asar we will not be doing it for LSP.

E

In this case, we will use a new object, called FAQ which identifies the node or adjacency or a perfect for the sr.

E

Lady looks like so as, as some of you would have seen this being presented in previous hackathons and previous bits and bites this implementation exists, but now, since the PCC is documented, these have been adopted, and this now is the time for us to start making sure that the solution that we have is it a good solution, matching those architecture and use cases, and if there is any concerns, and if there is any comments, we welcome them and we would like to move this work through the working group channel as and whatever are the comments that we get from the working group so that we can handle them smoothly.

E

C

Thanks Teresa any comments, add roof.

C

So I guess I have chair hat off. This is John Hardwick. Okay, so I have a couple of comments for this. I haven't read the drafts, so my apologies for that tell me if I'm asking silly questions here. The first question is I thought we had this idea that we could solve this problem by instantiating one up our space on each node in the network along the way. So I was kind of surprised to see these new piece of messages yeah cannae differently. Why why we need the new ones or why would want our powers?

C

Piece did not fall out. Yeah.

E

So I also like the one hop LSD mechanism quite well, and it worked very well for a basic per hop LSD instantiation, but trying to put this for the SR became a little difficult and because, as you know, that we don't have an LSP at the time, we are allocating a label mapping. So though we can retrofit it and try to make it work, it was just not very clean, so the implementation choice at that time.

E

What we made was, let's have a new message and see how it goes, but we are completely open to the working group and whatever working or feedback that we get, we will change it and I know that my co-author Adrienne is I. Think I can see in the queue he might have some opinion. So I'll give the floor to him.

N

Adrian Farrell yeah, so Dhruv and I exchanged email on this when when I was, was actually paying attention caused by him. Writing the sides and I'm pretty much in the same camp as John. That I would like to make this possible or as possible as much as possible use existing messages rather than new messages. So I think Dhruv and I won't have a little huddle about this afterwards and see whether we can't at these collapse some of it into using existing messengers.

C

Thanks- and it kind of brings me on to part two of what I was going to ask, so so you mentioned that one of the one of the rationales for having separate messages was to cope with the SR case and I had a little concern with the SR case that, but we were sort of saying that we would bypass the I GP mechanisms for label distribution to the intermediate nodes and, if we're gonna, if we're gonna, do that I think we really need to justify why we're gonna. Do that.

C

At this point, the slides saying that.

C

Centralized nature of PCs is better than the IGP 4 yeah. Sorry it Riverwood dog, some dogs on the line. Yes, so I think I think we need that. We need to justify that before before we really build the protocol around that assertion and that that to me was a sticking point, yeah.

E

I think, though, this discussion has taken place in both these drafts as well, so I think we can reload the architecture and the use cases document they do delve that, yes, the IGP mechanism is valid and it's useful, but if pc is also managing the label space and as we know via doing it, I GP mechanism, this the assad draft is become little heavy, with respect to the srgb and other mechanisms and anycast and other things so having a pc mechanism to manage the label.

E

Space has some advantages, so what we can do is, in our document try to make sure that we highlight that clearly that why we are doing this.

N

Search agent again- and I I agree completely with the dog.

N

B

N

It's always always right, and what he says to me in this case is that we have control plane mechanisms for doing everything. That's in this document and what this document is doing is saying yeah, but there's also Sdn, and maybe PC is the Sdn controller. So here we're saying for LSP is perhaps we don't need to use rsvp-te, we can touch from the nodes and for segment routing we're saying. Well, maybe we don't use the AGP. We touch the nodes and there's there's BGP example of doing that in out in the world.

N

Now whether that is the right thing to do or not is a wider question.

N

But you know and I'm not sure we want to have the the debate on whether Sdn is the right way to run a network. Maybe we do, how long have you got.

C

Now long enough.

C

Okay, thank you drew on.

B

The last presenter is young.

I

This is, you know again. Actually this is called piece MLS discipline state we have a to individual draft, one is for a kinetics and the other one is optical extension.

I

Yeah I think I think we need to understand. Where does this work fit?

I

Actually, this is applicability. This fulfills the applicability of PC of attn, NTPC I, think stateful htpc fulfills multi-domain coordination function of a CTN as well as.

I

Yeah customer mapping, translation function and VN Association, which is another draft, basically fulfills virtual service coordination function and this piece MLS. Basically, a fulfills abstraction function with the support for abstract apology in both southbound and northbound, which is known as MPI in the actn context.

I

So this is the high-level applicability of piece set LS. As you see here, device report link state information using P set protocol to is charge EC and then the chart EC sent to the parent PC of this link state and T information.

I

It's a recursive structure which fits to ICT architecture, and the idea here is that we only incremental e update and change. You don't have to wait. The entire network, OSPF t LSA to converge and then report the entire package anything happens in local lincoln node. We basically transport to the controller, so the controller would be are having the up-to-date information rather than waiting for OSPF T to converge and then maybe PCP less package that using busy pls.

I

So this is a very native piece of mechanism for that and we also suppose for obstruction, so key features of piece MLS. Basically, we have a capability report for the link state and T information locally and remotely. If you don't have a direct connectivity to a controller, it indicates that it comes coming from the remote and also support for synchronization and, as I said it's. The most important thing is that this is very incremental update capabilities added so that we can benefit for fast convergence and we also have a mechanism for backward compatibility.

I

If we have a GP or busy pls learned information, we indicate that where we learned from learn that information from and then we have an optical network extension as well for all T, N and W zone and flux grid, so this is very simple: we define one a new link state report, message where you can specify link state objects, we basically a protocol, ID and then flag and some other flag indicate remote owner and LS ID LSI deep, is basically is a unique identifier of.

I

The each northern link would be unique, uniquely identified by a pizza lsit, and is it remain constant for the lifetime or peace obsession and it can carry local and remote link, state and T information.

I

These are details of sub TLB that we defined and I think. The most important thing is that last idea, I think there was some decision was to be made, but it was put on hold and then I'd like to have some three implementation.

I

We have hierarchical transport, PC controller, which is driven by a tree and KT, and then it was shown in the last hackathon and at the end bits and bytes in South Korea, actually the previous ITF 97, and then we have another: oh no space controller, which is open, source, open source, a CT and project. Actually we have a github indicated over there. We implement the piece MLS on SPI as well as NBI, and another implementation which we haven't documented in the current draft is a city TC.

I

They implemented stay for PC controller. They actually published a paper in act on conference, which was which just took place to excel go in Spain, and then they reported applying piece F of Lux grid networks using active state for higher courtesy, implementing p-set LS for obstruction mechanism.

I

I

P7S completes actn applicability to PC and Ohio State for HPC and.

I

We have, as I said, a number of implementations have been reported publicly and then we actually enter comments from Ramon and we like to ask for decision because decision was suspended, but I'd like to make a decision for this. This work, which.

O

Yes, my name is ping Prometric and so I like comment is the implementation report actually is we did there's a POC with Miss MLS and we have cities Recovery's schemes based on the SDN controller. We are very interested in the recovery time from the working past. The protection paths when the parry happened, I think that we find that PC virus is very useful to the reduced response times when the pair happen. If you think about time, critical applications like a recovery, I sure I think that pc verison should be very useful solution.

B

You remember a ranch. Well, we will read that links that synchronization is useful feature. All tomorrow we already have is ste OSPF de BGP is T topology young modules on I probably forget some of other things. So I still don't see the rationale to put that in yet another TCP based protocol All Tomorrow's, you mentioned on us as a prototype there, almost on audio, already support various protocols, including some of the ones I mentioned before, so the future is already there. So why would the routing area define yet another T synchronization support for that as.

I

I said OS 5000 is a CT. You have to wait for full convulsions distributed using RSVP. So as it been indicated for mission-critical recovery, you know you don't have. You can't afford waiting for conversions, so this is Inco improvement from existing IGBT mechanism and bt. Pls also used always fifteen mechanism and then packages using PGP transport so and I. You say this one is actually proven in the experiment.

I

How quickly you can fix the problem to avoid the blocking, and so I kind of you know, ask for working group to respond, because you know your kids saying that we have other mechanism or other mechanism is not same as this mechanism. Well,.

B

Maybe you can improve others if you want to add you know you.

I

Know avoid 50.

B

I

50 I mean that's very obvious right. You know.

E

Now we are shifting to.

I

More centralized Jung is actually binary. I'm, it's not binary. Okay, it's a text protocol and we don't know how fast it can converge. Computer binary. We have actually some experimental result that pioneer is much faster, so we can show it to you if you.

B

By neri, but we already have at least three one of them being BG pls. Also it's based so.

I

They don't support incremental update. You can update increment Lee and disappear less human.

B

I

Pd yeah, but would you rather work on OS, 50, extension or piece of extension to achieve the same thing? That's the question, it's a philosophical question and then not many people know implementing to impel us anymore. It's kind of fading away. Unfortunately, then, what.

B

Is you know, let me disagree with that with my operator hat on operate right on again all particular key part I'm, aware of don't support a GP, at least for routing the management traffic, so adding more info in the IDP, which already there is participate Pro on adding a new protocol, because because piece F isn't deployed everywhere to support the feature that duplicates something that has been proven existing over more than 15 years doesn't make much sense to me. Yeah.

I

I think that's your personal opinion. I.

B

I

Just now your working group had on it. Yes,.

M

I

Last time, Chicago I think if I remember correctly, I think Adrian is here right. It's still here thing is: make a decision. You know I'm asking for working group to decide. Not you know, I don't want to convince with you, because we disagree on some point but I like working group. A list have some. You know working clear indication whether this is some use for eating or now we have to reinvent ation report and it's already deployed. Why?

I

What's the problem? Actually, if you have always PFT extension to do this and implementation I would compromise, but we don't have. We haven't heard such thing. We don't want to. You know change that. We rather change on this part of.

K

A few points you don't need to wait for SPF to converge at the moment. There's an update. It will be distributing to BG pls and go north soy, its sub second and I'm.

M

Not saying this work.

K

Is not needed so.

M

K

For optical domain, but GPS doesn't exist right. It's very much needed. I still have my reservation in packet domain, specifically as a blink requirements to full mesh of peace obsession to every device. No.

I

It's not obsession to every device. You can remotely learned, so you can have a direct touch, no thien report for remotely one. You want to be fast right, yeah I mean that's too fast. It's not it's different issue with the convergence. Convergence takes a long time, and so all of them are control.

K

Plane so I wouldn't call any of them fast. I mean.

I

That's a different.

K

Issue yeah you're.

I

Diluting some issue is some more fundamental issue, so that's not the issue we are talking about here right so.

K

To rephrase I it still need it, especially not people demand, there's no internet in packet. If you have customers who are asking for it and find it valuable, then probably we should be doing it. We are ATF to follow if not I, gp+ BGP provide pretty good solution so and maybe you should still be doing it, but having different focus. Sure.

I

I list, the optical I, think we have a lot of more information than packet and this proven very feasible for flex grid networks and so on. So NPC group also working on at you in TLS. So at least we can. You know, as for that, yeah.

P

Holly I would like to add some simulation results, because we have some kind of simulation on both PC Paris and together with ITF young models running by that call for rest comfort, protocol I think they did. We tested only on topology discovery and reporting scenario and the commanders and the simulates. The convergence timing, and we find a gap between the two solutions is the Pinery is about two or three times faster. Then a kind of text based solution.

P

So that's why we believe this McCann's of me and the solution is quite necessary and, moreover, besides the article besides the optical demand, all this kind of piece have solutions, because the lack half IDP BJP on the transverse I'd there is still a future upcoming demand from say, microwave side side. So it is also required to have this kind of generic PCF error as link-state as a starting point for us to do some technology, specific extension.

P

So currently, what we can see already is we can see the future of optical extension and microwave extension that we firstly I think the first milestone we need to achieve in this working group is to make sure that the link-state generic link states, a solution is adopted and complete.

B

Around again, I would like to her some feedbacks from my fellow operators there, because if this specification is part of vendor specific black box, I don't care if it's not or not. It's part of the black box I really believe that, whether it is packet or optical or something GPS can support. Like microwave, we already have a common set of tools within the routing area which are IGBTs on B GPRS.

B

If we want to push the starter for what those are the ways to go, if you want to turn your optical LS into bgp LS, you have a blessing.

I

B

I

I want one comment for you: is we have a lot of transport networks that doesn't implement a Sun gmpls at all and what we gonna do? You know this is the best bad and that's why I see it is implemented itself for flex grid networks, I'm.

B

Not questioning the fact that it is possible, of course it is I, mean.

I

B

One optical networks that doesn't run on IGP, at least for the manager on traffic purpose, but I, know plenty of them. We don't run this app.

H

As Microsoft I've just heard that there is a performance benefit of TLB, to be honest, I mean this is a parser issue. Xml and chasten can be transmitted and passed incredibly fast, and if, if there's a speed fan, if benefit is an implementation downside, so I don't see that TLV is anything to be considered here in that discussion.

P

Voila, okay, I need to clarify litt, because we, mostly young and I, upgrade that there are existing similar approaches. But what who we are proposing here is not to arguing the other say it's bad or something evil. Even we have simulation, we are seeing the Pisa Paris is something that should be coexist with our other solutions and complement free rather than competing with it hazard. We are not a fully overlapping in the scope. That's our point.

C

Can we make this final commonplace.

B

I just wanted to rephrase my question: are we a standard development organization or catalogue development organization.

I

Yes, oh I, think you know I ask you because you're neutral here, as a co-chair, at least you know, I asked working group whether you know how do you? How does working group feel about this? As you know, consensus process? You know the procedure, we haven't done it and we have a lot of interest implemented scheme and you know report it so.

C

So my thoughts on this and I'm trying to be as neutral as possible here both of us and the previous thing that Drew was saying. We have examples of occasions where we're using P set two distribution which would traditionally be distributed by the IGP. So this moves P set. You know further away from the path computation provisioning side to be more in the distributed database game and it seems to me to be a biggest step and when I think about what we charted to do in this working group.

C

It's not completely clear to me, but we charted to do that kind of thing. So I think I need to have a conversation with our ad about the Charter and the scope of this working group and whether we are even in principle, allowed to adopt solutions which do the kind of job that you're asking now it could be. But it's not and we need to reach out to take this on or it could be, but it isn't most there's no drop, but I think that conversation needs to happen. This okay and.

I

I have response for that. Do you think this PC CC, which is adopted by RTS as an architecture, hood, that the original PC function you envision? It's not right. Obviously, no.

C

But but I think the charts, the charts was expanded to take on path, computation and provisioning later.

I

Assignment as well right, yeah, centralized yeah, RSVP T has a decentralized a label assignment procedure already sure PCC is overriding, so we are changed. It's a changing world and why not link.

C

State update using PC well, why not that that would be changing charter as well, so so I think I have to I have to answer that question before I can really adopt, but I mean assuming we answer that I'm interested in the room. I know.

Q

Berger speaking as T's chair yeah in T's, we've been looking at basically Sdn control of te networks and from from my standpoint, I know the authors don't always agree with me. That's the really novel part of a see TM is. Is it's Sdn for T networks? Right? That's it right. We do have some discussion. We actually talked a little bit about this morning where we're looking at PCE and piece F as the way to go from the controller down to the network mmm-hmm. Whatever the network may be. Maybe it's an element.

Q

Maybe it's not, and so we've been acting with the presumption that that moving piece F towards an SDN control protocol was okay that doesn't change anything. You just said where you've got to make sure that it all lines up with your Charter and your ad, but we sort of been assuming that you're going to go that way. Okay, I, read, I read what is being asked for here is consistent with the tea's work on Sdn control of TV networks is that him.

C

Thanks so I'm just concerned to make sure we're not overreaching I, think it's all good as.

Q

I said it doesn't contradict it. I'm just saying that we've been heading, we've been going down a path with an assumption of where your group was gonna, go yeah.

C

Q

It was our assumption, it's good for you to decide where your group's going and.

C

So the question for the room, then, which I think we have to ask who wants to see P sub LS adopted in this working group, raise hands four five: six okay, I can nine hands and who does not want to see P soap Ellis adopted in this working group.

C

Okay, I see three hands; okay, so that's.

Q

I think would be interesting if hearing from Julia and if he thinks that the notion of piece Epps use in an STM control, T Network is appropriate because I'm not sure if you're saying no to bTW pls, because you don't like the specifics or no, because you want to keep the distributed model. The fully distributed control model.

B

I'm Jane Regan I mainly want to avoid duplication on other laps between the protocols we have on the table on. This feature is already more than were covered by others.

K

So having been building routing protocols quite some time, that's the reason we built a BGP able to cope with huge amount of changes at high-speed, with a large amount of information passed between us. This app is not really built for this frequency in this amount of information, so I think you need more semantics and more focus on parts of the network that are not as dynamic as really dynamic packet, Network so again, going to optical to microwave I'm I'm.

K

For this, because often this is only protocol available, implementations looking at packet I have my doubts again. If people want to implement it, maybe they love to hang himself but I'm, not convinced.

C

We're officially out of time here, sir Adrian we're on borrowed time. If you you want to make a quick comment, Who.

N

Am I going from I, don't.

C

Know whoever's going to come in and tell us to go, I think.

N

We're the end of the schedule or.

C

N

We can go on till 9:30 tomorrow morning. You can make so Adrian fell and it may help to to flip this and look at what harm could it do rather than what benefit? Could it bring and I think I hear Julian saying the harm would be competing protocols doing the same thing and I might answer that with yeah.

N

But apart from burning a few people's ITF resources is I'm actually going to damage anything allowing the market to decide what it wants to deploy, and if somebody wants to waste their time implementing it, they might be right and onto a winner or they might be wrong and lose whatever.

B

May I just saw Peter a piece of answer to to start with with American operators at home. My experience of vertical networks is that many implementations I've been using the fact that there are too many competing solutions to agree on a common way to implement such preventing interoperability, which is one of the main goal of the IETF. As a result, I still believe by the IDF should minimize the number of solution. They're not increase them. We.

I

Are just asking one simple TLV here, which is very implementation efficient, you know with. There are many many other piss-up solutions you saw today. There are many many objects and till these we are asking very simple change here, not measure so I, don't know what I understand your disagreement. I respectfully accept that, but but I have different opinion.

I

So what what is your you just ask people? What's your decision, I mean make a decision if either killed or continue on. You know it's been a while, so we like to hear of some your own rotation with the 80 and then let us know, but you see the I need.

C

To come back to you, I think I see some some strong support and strong opposition, and so it's not a it's, not a clear consensus away. Right now and I will be easier for.

I

Lead you know sending to the email list, because we have a lot of people not here of.

C

Course I mean I go. This was not an adoption poll. This was just from for my information all right. The next step is I'm going to talk to it's. Never.

M

C

Scope: okay: we continue on the list. Thank you.

C

Thank you, everybody, that's the end of our meeting and we look forward to seeing you next time at IETF, 100.