Internet Engineering Task Force Interim Meetings, 17 Jun 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: MPLS WG Interim Meeting, 2021-06-17

Description

MPLS WG Interim Meeting, 2021-06-17

A

Been recorded now and uh the agenda is being presented on the screen for today uh law. Do you want to speak about the agenda.

B

This is pretty much the agenda that was left after the last meeting. uh I put on the use cases one more time and I put the um action time action I can review and then the discussion that was going on now on indicators and ancillary data. I think um if time allows we go there. Otherwise we take it next time.

A

Sounds good by me and anyone wants to update the agenda or have something to add to it propose to add to until they end.

A

A

Okay, I think everybody's happy with.

A

Agenda so we could, we could do uh the action item review and um you know um now or I can give the ball to hawaii. uh You are immediately go with the order presented.

A

Shall we go with the order that you have.

B

Loa, I think so because this is something we delayed, so I think we should start all right.

A

Okay, uh why are you, uh uh can you hear us? Yes,.

C

A

I'll take the ball yeah, but you want to share from your side.

A

C

Okay, uh can you see my screen.

C

Yes, good morning, everyone um yeah today uh I'm going to talk about nps extension, header architecture. This is uh basically a dropped um named. A uh uh uh extension head architecture is actually um um accompanies uh other two drafts about extension, header indicator and uh uh the extension header format.

C

So first, let me.

B

Tell you one question: when, when we're starting, there is another one another draft on. Oh.

D

Yeah, or are you going to talk.

B

Are you going to talk about that one also, or do you want to do that next time.

C

Basically, uh that draft is in more detail this. This traffic also covers the the some basic concept in that draft, but that's of this gives more details in different type of natural scenarios. um I'm not sure at this point. People are interested in learning those more details, but uh from this talk they will get the basic idea, so it will be covered in this.

B

Yeah, I agree, but that means that we also would like to have at least a couple of people reviewing the other draft, because it's yeah, because it's really detailed and it's.

C

Yeah yeah there's a lot of details, but I I expect people will uh understand the the basic idea and, if there's more interest in uh knowing details and then uh yeah, we might talk about it in the future, okay, yeah. So so. uh First, let me recap some basic concepts that we have so far.

C

We like to support mps extension, header to support in-network services and the functions in mps networks and the extension headers are located between the mps, labels, deck and the original upper layer payload, and we need some indicators in the label stack to indicate the existence of ampere's extension header.

C

um But one interesting things about extension header is that um we have a new concept of extension. Header pass. um It's a uh this. This extension header parts or ehp um each is just a sub part of an rsp. It means it doesn't uh necessarily uh or in uh fully overlap with iosp.

C

uh It can start uh uh and end at any node on the lsp, um but the one requirement is that the both end nodes of ehp must be extension, header capable, which means uh because the the the header need to add the extension header and the tail end need to remove. The extension header and the a specific extension header is only valid, is only valid on a particular extension header path associated to it.

C

And there are two types of mps.

E

The first type.

C

Is a hobby hub type and it is supposed to be processed by every node along an extension header pass um and lsr and uh rsp can be configured to ignore the hbh header. um There was.

F

An interrupt in there you know.

C

B

G

H

B

Yeah, no, I was just a question if I remember correctly and extension had a path is equal to or a subset of the lsp, so it it could count an entire lsp.

C

Yeah, it's good power yeah, but it can be just a sub pass yeah. We. I will show example um in later slides: okay,.

C

um And uh another type of exchange header is a end to end so use or edge to edge. This means it's a. It will not be processed by the transit rsr and it's only inserted by the um header, ehp, node and removed by the tail each hp, node, and only also only processed by the ana nodes.

C

So here's some more details and the um only on the on the path there will be some uh extension header, capable nodes and the incapable nodes and the only dh capable knows can precise. The extension header has configured.

C

So this such capability could be announced through igp protocol extension, so each nose- and no it's a upstream um upstream- knows capability if it can do uh extension, handle processing or not, and each non-capable nose should ignore the chain header and the forward the packet as euro.

C

So that's to guarantee uh so the packet physics header can be successfully forwarded, um one one or more extension. Headers could be added by uh one or more uh each extension, header capable nodes.

C

um So so, but to add a new header, we we have to ensure that um the analog the download enter under downstream can remove it. So um otherwise the extension header cannot be added and also to optimize the operation. uh We use uh some fec uh uh label to actually indicate um there.

C

There is no exchange header in a package explicitly so with this uh um label, then the the we will know the node can immediately know that there's no extension header, so it doesn't need to scan the label stack or to find it try to find it. So I will use example to show how it works.

C

So this is a example. um We have a label switch path from node, a to g.

C

The the upper case node such as a e e f g, are exchange header capable, but this lowercase node, like a b and the c, are extension hydrogen incapable so on this label parts we have a set up of five extension header passes, which means each pass will add a new extension header to it.

C

For example, the first pass eh p1 actually from node a to g. It covers the entire level, speed label, sewage path, and we have some other other uh passes as well. We can see that some of these ehps uh can overlap partially.

C

So so by allowing this a very uh flexible um uh pass process, an extension header usage and you can support uh various different network internet services, um so which also means uh like sending headers actually can is possible to be added and removed, removed uh anywhere in the network.

C

So this is a fairly uh flexible so to to to support the um the the each of the forwarding. Actually, um we use um some um uh uh some some, some um like the dod and the du uh method to distribute the labels.

C

um For example um in in this case um the g will uh advertise uh the label. Folding label for the label switch pass using the uh just a uh just a like, as shown in it's a figure.

C

um The the label 203 202 and 201 uh are ipfec, which means um it's just it's just a normal as normal um labels for forwarding. So it also means um there's no knowledge about the existence of the fec, so in this case any node, any extension header capable nodes when it sees such a label, it will need to check if, if there are extended header in the packet or not, um if a extension header in capable nodes see such a label is just a forward as euro.

C

um However, there's also other the fec called no extension header present fec. So once this label is uh distributed to a uh each extension extension header capable nodes, uh then uh the the node can use this label to tell the downstream downstream node that there is no extension header in a package, so the downstream node. Once you receive such a package with such a label, it will not check the exchange header and the directive forward packet.

C

So in this case the performance can be optimized.

G

Can I ask a question here.

C

G

So if the extended header is a end-to-end header, you know there is really no need to to scan it right. So I assume this indicator. uh Well, I mean uh uh present indication you know is only needed for.

I

For uh have a hub extension headers is that um yes, uh but.

C

I I mean even for even it's a end-to-end extension header, the internal node is not supposed to uh process it, but they can still look at it. uh So what is.

I

C

um Some time it just gets the information from from it. I I I'm not sure if they say um exactly necessary or not, but the point is it will be not processed, but it doesn't prevent you from looking at it. um So um at least um so so I think it's a possible uh still to um provide it or if we, if we usually agree that, there's also no need to to look at it at all, then um you are right for the edge to edge um type of extension.

C

Header you will you can just um but semantically um here. We just use that to show no eh present, but it doesn't tell no um uh hope by hope or end to end, so it will be. Don't differentiate that so I think it's a uh it's better uh to um to not differentiate uh what type of extension in the in the in the payload uh in the package.

C

Another reason I think, is that um we still need to use this fvc label uh to tell a node, which is a actually the tail node of the path it it. It's indeed a need to process it. It's a essence. Header even is a attract type.

A

Sorry can I ask questions uh yes sure, please, okay, uh you are saying that uh a label fact will be allocated to indicate. uh Eh is present and no note present.

A

So by default, eh is for every label we allocate is present by default.

C

um Noted by default is a label just tell you nothing about the existence of fec, which means if um eh capable nodes receive a normal label. So it doesn't know if there's a exchange header or not. So it need to check.

A

What tells the node that there is an eh header?

A

What is the yeah? How can a node tell that an e8 is present.

C

Oh yeah, because if I insert um if I receive, for example, there are two cases if I uh I'm a if this node that had a node is, of course, the extension header capable nodes, and if it knows it's a um uh it's a it's a it's a it insert extension header to it, then it will uh use a normal um uh label ipfc label to forward it.

C

Otherwise, if it doesn't, if it sees it, it finds there's no extension header in this packet. It will use a no each present at vc to forward this packet. So this way the the downstream node once they receive this package.

C

If it is received this and no each present have you seen, then it know immediately that there's no extension header. Otherwise it need to search.

A

Okay, so what you're saying is that uh the top label indicates the presence of the eh? Yes right! uh That means you, okay, so that the the the gash way was that there is.

C

Oh, no, it's not to tell you the presence of each uh the eh. It's a basically either tell you, I don't know or explicitly tell you there is not so so. If, if you find this I don't know, then you need to continue to scan the label stack to try to find the indicator.

C

If there's no indicator, then there's no extension, header for sure.

A

Oh so, okay, that's it! Okay! I didn't understand it that way. Okay, it's not clear from what okay from how you explain that I'll read more about it. Okay, yeah.

C

um So so so um for, for example, in this case, no, if we have a, we have a a path from a to g right, then a will add a new extension header to the package.

C

But if you're only using 203 label 2 3 to forward as top label to fold the packet to b, then b receive this packet and because it's incapable uh is incapable and it just forward. The packet to d now d receive this package with a label 202 and they say: okay, I don't know if there's extension header in it or not.

C

So I need to search and after search node d find there is a extend header in the packet, so it will use a uh 201 sq201 to forward the packet to e and similarly e user uh user, fec php forward packet to g. So so then, and then the g will uh terminate the extension header.

C

But if there's no extension uh header at all, so okay.

C

A still use two three four two b b use: two two forward to d. Then d will need to check the exchange. Header find there's no extension at all and it will use 301 for 2e now e node e once it receives the package c 301. It knows, there's no extent header at all. That's well directly forward packet to g, so so in uh in this case, you can see um the the node is present. Fc can help to accelerate the processing.

E

The e node is going to allocate uh two labels for the same ip two zero one and three zero one.

C

Yeah, okay: this is these- are fec labels yeah for the same path.

E

So do you have any example like uh uh where the the extension header lies and stuff like that in the stack.

C

uh Can we can, you repeat your question.

E

Did you have any slide where actually you can show the uh where the uh extension header lies in the uh mpl.

C

Stack data. No! No! No sorry! I I I yeah! I didn't include such an example in the draft, yet okay yeah, but uh uh actually I I think that another draft in more details gave actually actually gives uh some figures um yeah yeah, to show the real real example yeah. So yeah you can. You can take a look at that and another draft okay.

E

So another thing: uh uh how actually we can correlate that uh this extension header should be processed uh on being a d node or e node or g node.

C

um That's a that's! This is that's configured um if, um if, if the node is on the path then- uh and it's a hbh type node then on, then then that that node is is also each capable and it should um process this exchange header and if it's a um configured as um end node on a path so and this this configuration should bind to a particular exchange header. Then then that extent header should be removed by that node.

C

So, in this case that says all uh configured through the control channel.

E

Okay, in that case, that should be only one extension header in the stack anytime.

E

C

uh This could be multiple uh extension right. uh So in this example, you can see um we can have a five extension headers, but the first one will be effective from a to g, the second one from a to e, the third one, from d to g so which means uh at node e extent, header two will be removed and nf uh extension header, four will be removed and and node g.

C

All the other three extension header will be removed.

E

Okay, so so then, in that case like for each and every uh extension, header insert and removal, we need to have a corresponding uh label to that.

C

Yeah, uh that's how we identify no more! No! No! No! That's only if I understand your question right where we have only one indicator um in the label stack to tell there are extension headers.

C

So if there's a more than one, we have only also only one indicator so in the label stack, we cannot tell uh uh how many headers we have. We just know that there is. You need to go to the extension. Header part then go through the chain of extension headers to find the uh to to find the one you need to that. The node need to possess.

E

Okay, so if you can send that uh the description of the extension editor, I can take a look okay and say: yeah thanks man.

D

How you you say that you can insert actual extension header anywhere. How do you decide where to insert the header.

C

D

Receive a packet on d and you choose to insert new extension header, will it be push on the top of the stack or somewhere in the middle.

C

Yeah it's a uh it's a is that from d to g could be another extension header pass, um for example, for some uh application, uh such as I o, am, and uh I'd like to monitor the collector that launched data from node d to g.

C

Then we can just add the iom, header at node d and request the g to remove it. So, uh but but this is just a part of the entire label switch pass, it doesn't need to overlap with it completely, um so so so yeah. So so. In this case, you can see uh at node d. There are already two other uh exchange headers in the package, um but this is third one um uh also also um if we have multiple extension headers.

C

We organize this. In this way, the all the hbh type are kept in front of the e3 type.

C

So so this can also help us to improve the performance a little bit, because our hbh are supposed to be processed by every node and um e to e is only for the edge nodes and also um another reason is that I put the hbh earlier. I also has a higher um possibility to be uh still in the within the reach of the cheap processing capability.

C

um So so this can be processed.

C

um If it's a beyond a better buffer window, then the node cannot be processing, but in that case it's um um it's a um the the default uh behaviors should still forward the packet without dropping it.

D

I have actually that explained quite a lot. Thank you for that. uh One, more clarification question: um do you assume that all the nodes can process all the extension headers.

C

No, uh I mean even asa extend header capable nodes, it can be configured to support some extent, header or node, to node support some others, and if even it can support some extent header, you can also configure it to not process it, because this is a for some um at least the four uh one reason for that is uh for the performance reason. If, if um processing such header, I can over uh load this current node or are causing other performance issues, then the node can choose to be configured to ignore the success header.

C

So I think this can all be configured or or they can can determine this in real time, depending on the um current traffic um um uh traffic load, um for example, if uh for the uh again for the iom case, um so that needs quite a lot of processing and if actually doing the processing um cause a packet drop or uh or slow down the forwarding, then then the node might choose to note process it.

C

I think that's a should be supported.

A

For you, I have two questions on the slide before you move on. Yes, um the first is: how do you indicate to a node, let's say d, uh that it should process or maybe the is not a process uh eh1, but not eh2.

A

So so, basically, okay, okay, yeah, basically number one. That's question.

C

Number one question number.

A

Two I'll tell you the questions, and you know you feel free to answer them. The second is you know, how do you extract e, for example, to pop only eh2 and leave h1 eh1? It is the it's the endpoint of eh2 but looks like it removes the h2 and keeps h1, and these are the two questions.

C

Yeah, okay, I think these two questions are related result all about how we configure the extension header plus um for the node d, since it's uh actually, it's belong to both uh uh eh p1 and the http each p2. So by default it's supposed to process both extension headers, but uh it's a can be configured to ignore on either of that.

C

Yeah yeah also configuration you can say: okay, uh either you are supposed to process. You are actually you can process these two two extension headers, but one of them. You just tell don't, don't don't do it? You can.

A

Configuration if you think of it is you have to go and touch the nodes and it's it's a dynamic thing. It's happening in real time, right, yeah,.

G

Yeah yeah and related to that, it's not only process and also the question of removal. Whether.

C

G

Remove the head, or not header or not.

C

The removal is a is a mandatory if it's a end, uh it's a end node of the path it has to remove the remove extent header, for example, node e must remove the uh extend extension header too.

G

How do you know is the end? Yes,.

C

That's uh that's also the um that can could be done through other um protocols but uh or through the control configuration.

C

As I said earlier, when you insert a essential header to the packet, you must know there is a downstream node as a pass end to uh to to be able to remove it. Otherwise you can not insert it at all, because that causes a um problem.

A

Yeah, it's not clear why you, because the lsp in your figure here is from a to g yeah. When you said the path is ending, I got confused. What do you mean by power? I mean the past is.

C

The extension header part, so um so so only you can set up like header parts.

C

Then you can insert the the extension header to this pass so so, which means in this figure you can see for every extension header it has a. It has a pass.

C

Start from node and the antenna and enter some other node on this label switch path so which means that the end of extension, header parts- you have to remove that particular extension header.

E

Yeah, that is the confusion. Even I have you know like how the stack look like on when a send the packet out, so that will explain know like um what all information you have and then uh where actually uh it will be, removing those ehb headers.

E

Oh esp, is not the header each piece: here's the inside.

C

E

The data, the the the additional extension data you said, you're going to remove. If, if you have a ehp2, then actually he is going to remove it right. So, if you can give an example of the label stack, what actually a is producing okay and then how how actually in each node it's getting uh removed. That'll make things more clearer.

C

Yes, okay, okay, I I, but unfortunately I don't have any number just so, let's try to explain it from node a you you can see in this figure. We will have a two extension header inserted to the packet right. Then then we also need to uh insert um a indicator uh extension header indicator in the label stack somewhere.

C

um Then we we just forward this uh uh this packet, um so so, b and c are both um both sides each incapable. So it will note try, uh let's just do the normal forwarding right. The packet will reach the node d. Then d will check d. Will either each capable it will check check the label stack.

C

It will find the indicator find the indic exchange header indicator to tell okay. There are some extent headers in this package. You you need to look at the node d will then will then uh search through the extension. Headers um list will find these two is 10 headers and then based on the configuration in this node, it will choose to process them uh one or two of them or or it can also be converted to do nothing about them.

C

Then the packet will be forwarded to node e e is also extension, header capable.

C

Then it also exam examine the label stack to find the indicator and based on that, it will continue to search and find the two extension headers and the now e is configured as a fast php parts tail node for the hb2.

C

Then it will definitely need to remove the second extent header and it also decides to process the first header or not. Then the packet will be folder f and then to g and node g. The first exchange header will be removed again. So so here I only talk about the first and the second extent header. Then there are also some other three uh extend headers, let's say: follow the similar processing.

C

J

So yes, three um do you need to put a result header at a without extension, okay,.

C

C

Put one header.

J

The one the the label say no extension, header.

C

No, no! No! No! If if uh we have only extend header uh plus three right, then then uh a a there's, no header right, a cam. It can put a nose header um fec in it to fold the packet to d. So so so d d will receive this and the d node there's no stationery, but once d inverted the new stage header to the packet, it will use uh the other, um not the normal fps ipfvc label.

J

Okay, thank you.

F

So the thing that I mean I know I helped write this some years ago and all that, but the thing that worries me with all these things is: do we really want to be pulling packets apart and inserting stuff in them, or should we just be have some universal marker that allows you to um uh to say you do not process on the path. I mean it's a big deal pulling all this information off the front of the packet.

C

uh Pulling up you mean they're pulling out. Some uh information means that you.

F

You no no you'd have in order to insert a header. You've got to strip the entire label. Stack and you've got to strip all the headers in front of it and then push it, and I'm just worried about whether that's a realistic.

C

um It's a actually uh in the package processing. This procedure is called. uh Sometimes it's called depressing how you assemble the uh output packet after the processing. um In that sense, actually, the the package already.

C

Be separated into a different parts. You just need to um reorganize them to form the new uh package, all right.

F

So so you are assuming a particleized forwarder, which is a big assumption um about the forwarders now and if it was as easy as this, why did anyone ever complain about the number of sr labels that we wanted to push on packets.

C

The number of ads are labels, that's a that's a, I think, four or four mtrs sorry. I mentioned right. Yeah, yeah,.

F

From pssr there's a big issue with the number of labels you can push, and here we are talking about pulling potentially very large numbers of labels off and potentially arbitrary length.

B

I'm just worried.

F

B

Rebuilding these, whether we can do this wait, wait a bit. What you do is you put one indicator in the labor stack. That's the only time you attach a stack.

B

The extension header goes as uh ancillary data after the boss.

F

Right right right, so I I said, but people would but I thought I just heard that we were going to proposing inserting information in the stack.

K

Or including information.

F

After the stack after the stack- yes in the middle of the lsp to insert information after the stack requires either a lot of work or one very particular, processing model that, I am not sure, is widely supported.

F

So just be careful.

A

Yeah, I agree with stewart.

A

Yeah, there's a uh imposition limit and a scan limit of number of labels and well.

F

And also not all forwarders, I think, can do particle forwarding, which results in an insert in the header. Can they.

C

In in you, you you, you are seeing inserting new headers in the uh network.

K

Is expensive, yes, and I'm not sure, and I'm not sure, he's universally supported by a long long way.

C

um It's uh actually, I I believe it's a just um to to to my knowledge. I think it's a actually not that hard to do. It's actually easy to do uh in many uh in the hardware switches and also in software.

B

C

You you you, because uh yes, it's needed um for, for example, in the uh in the existing uh in the iom, uh truth mode. We already know that that's a possible to keep adding data to.

J

D

C

That will expand the size of the header. That's.

B

The equivalent to.

C

Insert some data in the network.

F

Right, well, hang on a second first off. I am not sure how widely insert io am is projected for deployment, I'm not sure how many people can deploy it today, but we're talking about largely universal or quasi-universal services here. So I wonder if people with knowledge, detailed knowledge of the vendor, implementations could um put in an opinion as to whether.

C

Insertion is possible. Let me state in this way no.

F

No, no I'd like to.

C

F

Let's hear from the vendors whether they can support this characteristic, okay,.

C

Let's not use that example just say: okay! Well, you used it for all the, uh for example, for the srv6.

C

It's inserted. Actually, it's a it's a it's a um um inserted in network right well,.

K

C

K

Okay, that's not signed.

F

C

And for mpos, you will need to um push labels to the to the um to the to the packet. It's also added the new headers, it's the equivalent. Now that's.

F

Not the same, that's not the same insert is not the same as push, and you know that so another.

C

F

Before we carry on, could we hear from some I'm neutral these days by the way I don't work for huawei anymore? uh Could we hear from some non-huawei people whether they can support this feature.

F

Of course, if you uh yeah not.

C

You you, how you.

F

I'd like to hear from others on the call yeah whether they believe they can support this feature.

A

I will leave it open to the vendors on the call now, but I think it's fair also to take an action item and ask the vendors. uh You know feedback on such a insertion uh and transit lsr and- and I can take an action item if any one of the vendors wants to give their opinion. Now, please go ahead. I I I know why uh why your's opinion or we know or use our opinion, but if anyone other than.

A

Wants to comment go ahead from the vendors.

A

Okay, I can like I promise I'll, take an action item and you know uh we'll ask the vendors to please. uh You know.

L

A

L

uh I think we also I mean there's the data plane capabilities, but there's also the control plane capabilities to set all the stuff up. I mean, I think the overhead of setting this stuff up is going to be substantial.

F

Indeed, I mean.

A

F

John, we could in principle I mean it may be hard, but that's simply a matter of software. If you excuse the term no.

L

I'm talking to performance.

F

Yeah yeah yeah yeah I mean if the data plane can't do it at performance, then we should stop talking.

L

About it, no, no, no, but the control plane performance of setting of all this messaging to set this stuff up is going to be uh extension.

F

Okay, thank you.

C

Yeah, so so so so far, we only talk about the data plane processing. Of course it will involve also involve a lot of our control plane, but there is a uh it's not covered yet and definitely needs future work, and also in this uh just for the purpose of a demonstration. We actually show a fairly complex example, but we don't expect actually in reality, we will ever need to handle such a complex cases, so so so so so because we we all know there, there are costs associated with um extent, hand processing.

C

So in reality we may uh want to actually limit the person number and also the uh the past uh construct for for the extension headers. So so so here we just see okay, e uh zero or zero or radically. We can uh support some such kind of flexibility.

M

Stuart ian here: um okay, for clarity, when you say vendor, what do you mean? Do you mean what a sick design team, or do you mean a box producer who may or may not design their own asic or a box producer who uses merchant silicon? I'm.

F

Trying to understand how feasible this is all right, and um so my question really was an abbreviation for of the question to the vendors yeah. If we were to standardize this facility, which would be useful for all sorts of things, this insertion thing would this be supported across all lsrs or some class of lsrs, or not really be feasible at all. Okay,.

M

I I certainly uh think I can say with some uh caution around taking me at face value because it's been a while, since I've been poking around in the detailed implementation of the data path, that this would be uh at best frustrating to implement and at worst not possible on certain platforms.

M

I did look down through the list of people whose names I recognize and don't see- people, for example, from broadcom or even people from some of the vendors who have their own asic development. So I do think that the question needs to be put more broadly than this group.

F

I I agree with you, I agree with you. I.

M

Am really worried about concept? I have been bothered by this since it started one of the virtues and one of the reasons why I reached out to you about the indexing. The proposal is, I thought that that might mitigate it, not not mitigate the insertion problem but mitigate some of the computational efficiency problems that are always the upper bound of what you can do in the data path and I'd rather spend those cycles doing other things. If possible.

F

So I think we probably largely agree and um the idea of sort of short-circuiting a header seems to by a pointer or some offset. This calculation seems much better than physically removing it, and I'm kind of of the view that if you didn't have the foresight to put the put padding space in the header when the packet originally started, then it's too bad. It can't go in there. I.

M

I generally agree, I think there might be some exceptions to that uh in in very particular circumstances, but very broad strokes. I agree with you. Yes,.

F

I think we're probably aligned here john.

L

Well, there is another issue which is that a may not know about the existence of ehp3 or or hp5, so it can't pre-allocate for them, so it would kind of have to.

F

Push its own stack up. Well, so you could argue that that maybe the right thing to do is to build your own stack, if that's the case, so to terminate the story.

C

um So that's the same thing you you just saying you. If you don't put new data uh to the head of the package, if you insert it somewhere in the middle, then that's a you have concern on the performance so.

L

Stewart was saying that you might that uh a might have to pre-allocate for all of these ehps, and my point was: it may not know about them.

F

Right- and my point was maybe the right thing to do is to get the packet scrub, the overlap, get the packet to to d and um then get it and then strip the headers off and start again so make d, a gateway that uh well.

L

Then I have to do the same thing.

F

F

So I I I think that that we really need to be really careful as to what it is we want to do and whether there are simpler ways of doing it.

F

And I don't think we can assume the a well we will find out from other people right, but I I don't think aris any assumption that you can insert data on the fly uh it's going to carry across the overwhelming number of platforms, but I may be wrong. We're prepared to be proved wrong. We do need to know from the manufacturers whether it's feasible in any reasonable time to be doing insertion.

J

Stuff, so are you saying it might be better if we just do everything at a.

F

uh Only either push everything at a.

J

F

F

Push the packet get the package to d and then rebuild the stack at d. You know.

C

As long as you will do this in network, it doesn't matter where you do it. It's the same.

K

It's the same processing right. No, it's not the same.

F

Push splitting your packet apart is not the same as dumping everything that's on the front. We do that all the time and pushing stuff on the front which we do all the time.

C

Yeah you, when you say all the things include, the label stack right.

A

Terminating the label stack yeah, yeah.

F

I was assuming you were too comfortable.

C

Here the structure is the pack structure: is a label stack plus a list of extension, headers plus the original payload? So you are saying at node a or some some particular node. You will remove all the label stack and remove and add the extension header and then put the label stack back.

F

That's exactly.

C

The same process.

F

No, it's not put the label stack that you.

J

F

To extermination on there sorry.

J

F

You have something.

J

A you so at the uh rsp head and you add all the extension headers.

F

J

Even for esp3, you add a, but you indicate it started, processing like um starting from d right, so d notes is that need to be precise if, before there are any capable node, they just ignore it.

F

So there are two solutions. I think, let's just take um uh what you you can either get the packet to d and then strip anything else off and recreate the packet make d, a yeah gateway, make it say a switching node or you can get the packet to d push, for example, ehp3 on the front plus the lsp and then set g up so that it knows how to first remove ehp3 and then remove ehp1.

F

I think probably what we need to do is this is really going back to the requirements. Isn't it this is going back to the we should figure out what it is. We really want to do.

J

Sp3 uh they don't go together. Yes, p1 means there is a like a the the ehp. The extension header is head to the end, and the esp3 means you only have it part of the lisp.

F

Right, so what you could do is you could push ehp1 push the label stack to d at d, you can pop the label, delivering you to d push ehp3 and then push the label to g.

F

That doesn't require new things from from lsrs. Inserting ehp3 on the fly does require something new and I just wanted to verify that it was feasible.

F

Are we really talking about.

G

uh Inserting, uh no, I mean uh putting a esp3 at a or just leave space for uh three, but still let b to do put in the energy.

F

I I'm capable I'm cool with either of those approaches. What I, what I am concerned about is the the feasibility of adding information below the label stack and midway along the um the path.

C

So stuart, as you just described when we, the the so-called insertion, is just like you pop something you put it in the right location. Then you push back the what you popped, then that's the insertion right.

F

Well but but but can they actually do? It is the question: it's a huge amount of data relative to what they normally deal with.

C

J

C

Find some yeah, as you said, find some uh vendors or some other experts hardware to um talk about that. So.

F

Even with your even within your own company, you need to be sure that all platforms that might want to do this have that capability.

F

It's all very well thinking that some platforms for some specialist applications have got it. That's fine! So long as this is only deployed in places where those platforms are the only platforms um deployed, it's much much bigger to add a general capability to mpls, because that requires that it's feasible on all likely types of implementation that you will meet, and I just want to make sure that we know what we're doing. We really need to talk to what I've been loosely calling the vendors.

F

But we do need to talk to to to people to understand that they're happy with that. Otherwise, we'll come up with a solution right and we'll put it in the in the um in the uh to the working group and it'll, probably fester on for a while, and then someone in the vendors will notice and then we'll have a big fight. So why don't we find out to start with whether this is feasible, um whether it's a significant increase in the design to do it, and whether the value of doing it is justifies that increase.

A

Fair enough, I think, that's an action item. I took already stewart and I asked the attendees you know to to update that action item man uh while while I'm talking I want to ask ian, uh I didn't catch uh for what vendor you were speaking uh on behalf can can someone enlighten me on? If he's uh did you mention what what vendor you gave your opinion.

A

On ian, maybe it's a way: okay,.

A

Okay, I'll leave it uh as duncan ian then.

A

A

Do you still have material? Why are you or you're open for questions generally yeah.

C

I think uh yeah, I'm almost done so uh obviously at least just some uh um very uh initial work and there's a incomplete and in this draft they also leave many uh empty chapters trying to cover uh different uh other scenarios like rsvpt tunnels, vpn and just segment routing, and also, uh as I mentioned, there's no um uh too much about the control plane is covered, so this uh all uh to be done, yeah, so yeah um yep. Basically this uh that's all. I have right now and the other questions are welcome.

A

Yeah, ideally, we can get back to the feasibility before we go and throw control plane extensions agreed. um I have a doubt. You know on your figure there, where you have nested, uh ehb uh or multiple hp's. Can you go back to slide four, please? Okay, this one: okay, yeah, okay, so in here I think, maybe was mentioned.

A

Also to give the credit um a could have inserted ehp1, ehp2, hp3 and hp, 4 and 5 all at a, but somehow we magically indicate that d is supposed to uh process ehp1 and each b2- and you know and e, is supposed to process one two and three and four and then avoid this insertion in the middle right.

C

um You can do that, but this has some issues um you know. First of all is overhead right. If you, if you, for example, in another example, if I just have a very long path but between every two pair of nodes, I needed to add an extension and extension header.

C

Then if you put all the extension header up front from the beginning, then you will end up with an extremely um large packet or the hammer overhead too big, but actually in one node only you only need to press process one. So that's a very efficient or it also may cause a uh mtu uh problem right. So so, um in that sense, uh sister for the for the overhead concerns, there's a no term. I I don't think that's a you know.

C

Ideal solution, and second, is uh is actually uh you know um make a if you you, you stack too many exchange chats together. Then it increase your search cost right, because you will just do one uh in each node, but you you need to find which one and there's a other cause about it.

C

The third is that, if, if the or has too big, then we we all know that for most chips, there's a concept of a header buffer window.

C

um If some extent header is just a because some earlier header too big then push those other headers out of the window. Now you cannot see it and you cannot process it so so, in this case, it's useless to put extension header there.

C

um So so far, I think, for these reasons uh I don't prefer to you know, to put all these 10 channels up front.

G

A minor detail here is that I think whether you put it uh all the headers there or just uh leave the space there.

C

Leave that that's a uh also impossible, because each header is a has a different size and we don't know what header we will use. So I don't think we can leave space because we don't know the right space.

C

F

Well, maybe you could provision, for I mean. Presumably the network operator is expecting these things to get um to get added. So it's not infeasible to do that in a well-defined network.

C

Well, for example, some extent header gender- maybe just need a a few words right, but some may need tens of words. So the.

F

Question is: do you know that that does the operator know this.

C

F

C

Yeah so first thing: how can.

D

C

D

Can this won't be very dynamic? uh I liked his example he gave we want to do telemetry from node d to f and that could be on demand because your network is con constrained or there are some errors only on that segment. So you want to perform those operations dynamically, not pre program. Those headers upfront.

F

You could do that cure and by by it all depends on whether you also have to do the operation at e or not.

F

Even if, if you want to do uh just path segment, monitoring which we just which we thought about quite a lot in the mpls tp days, then you would normally push a whole new front on the packet.

F

See you could it you, could you could do it by instrumenting between d and f, um over a tunnel uh def.

D

Okay, then, we have to understand the trade-offs right trade-offs of tunnels.

C

D

Versus providing this extension header capability.

F

Exactly and that's why I want to understand what is actually feasible in the medium future in the um in the lsrs.

F

I mean I'm not against new lsr's doing this, but the value of doing it has to be sufficient that people would deploy the the the solution and be prepared to live with nodes that couldn't do it, but we we just need to to ground ourselves with this.

D

Yeah, I think I uh I posted in the chat also. It might be interesting to see how this solution can be made constrained just with push and pop operations, rather than talking about, insert, remove.

K

I I agree with you.

C

No matter what I I think here, the key is to uh maintain the such kind of flexibility right. We don't want to uh restrain the actual the flexibility, uh because first, we have seen quite a few existing network services which might require such a flexibility and also we don't want to uh close the door for for the future development.

C

um So that's that's why, um whatever uh scheme we dropped, we should uh support uh this kind of flexibility, but just of course just consider also consider the visibility in real design.

C

G

One thing the worst considering is that sometimes, when you need to do add, add a header insert a header in the middle of something it's possible that it's. That note is doing something special and and- and that special note is, has some extra- I mean it's it's. Maybe it's able to do something more complicated than inserting a header.

G

Maybe I don't know if it is acceptable to say that okay, this kind of operation is only in theory. It can be done by you know, but in reality only certain kind of gateways will be performing this kind of insertion. So it's okay, yeah yeah.

C

Yeah, that's a kind of a capability right for some node is a capable of doing that. Someone is not so, of course, you have to um consider take this in into consideration um yeah for, for, I think, that's, that's a uh just a should be advertised as a node capability, and you can only set up your extension header pass according to that capability announcement.

F

Well, the perspective on this, though, is that we have lived for nearly 40 years. I suppose, without needing to do this in the data plane, and if we do introducing this into the data plane, we have made a major change to our concept of layers and so long as we're prepared to sign that as long as the ietf as a whole is prepared to sign that off then great, but we have lived for a long time without needing to do this simply by thinking a bit harder about other alternative proposals.

C

Yes, even for srv6 extend header is supposed to only be added by the anandos the host right, but uh um I think here we are talking about some brand new uh in-network services. It's a different. It does require the service to be initiated within the network, so which means that some nodes in the network has to do the work. It's not not just a host can do the work, so actually some routers on switches in network do the work right. So.

J

C

A new requirement- and I think we need to cope with that.

F

No, no, no. We need to validate that requirement. First,.

C

Yeah yeah, so so I already uh showed a bunch of uh um use cases, um but briefly- and I can talk more about that- but um all for all those services that require such capability.

F

Well, we do need to understand well.

C

Unless we, we don't want network to support us and.

F

So so so it's all a question of whether people have got money that they're prepared to put on the table calls the vendors to do this and remember that every millimeter millimeter of silicon you take for this is a square millimeter of silicon that could be used for something else like increasing the speed or increasing the number of ports or some other function. So we do need to know whether these are services that customers are prepared to put their hand in their pocket and pay for.

G

Feasibility is one thing, but well.

L

G

When you mentioned the later or violation, uh I don't think we touched upon that. Did we.

C

I don't think that's the layer, a violation at all, because all these are belong to layer. Three.

F

C

They've been on two.

F

Different sub layers within layer, three, yes,.

C

Yeah, you can see, you can see the sub layer, but it's all layer, 3 network layer, functions.

A

If you take the example of ip in ip tunnel, you can always encapsulate another ip header and have its own extended headers in it, and then it terminates at a certain point and then resume the original ip uh in here. I don't think I see the delineation of nested lsps.

A

um You know the similar like you, you talk about ehbs as as, if it is an lsp, but I only see a flat lsp, I don't see nesting of lsps.

A

So if you had, if you had lsp1 lsp2 lsp3 and then you are nesting them somehow, I would have understood, but you show one lsp, which is flat, but you have nested paths.

A

Which is confusing like in ip world, you would do encapsulation of the ipe packet. I think that may be related to the layering concept.

G

A

G

Not a the layer or a nesting of the lsp, it's really just the where some extension headers are applicable. For example, this is just the.

C

G

But here between d and f, you have another yeah you have. I.

A

Asked jeffrey about that, if we can do an indication kind of thing that this extended header is applicable to this node, uh but I don't think he's doing this uh like there is no indication. Is there.

C

There's no yeah, there's no indication uh in the package. That's.

A

Down through a node will have to process all the hps. If, if there are ehbs, you cannot selectively process a specific ehb.

C

But it's a it's a that's just configured. You can see all the.

K

Extension headers.

C

But you can select, I don't figure to process some of them.

F

um Well, you've either got to to indicate that in the lsp or you have to indicate it um by some other means in the packet, and that's one of the reasons why we liked the sort of the pointer arrangement it kind of made it clear which ones you actually did in the flat arrangement. The only thing you can do is to be selective as a result of the characteristic of the lsp or do all of them, as was suggested.

G

Right, depending on the uh relying on configuration, I don't think it's going to work out operationally it's going to be very cumbersome. I.

G

A

Okay, uh any other questions to why you on this.

B

I have one thought and I haven't read up on it. So it's it's a real question. Ipv6 has extension headers. Aren't they doing this type of processing.

F

Yeah but it's kind of a bit of a mess, really you kind of have to figure out for yourself on on the path. um What um your which headers um you want to process and remember, there's a big big argument going on in uh in six man about whether you can add anything in the path.

B

Okay, so they're having the same discussion as we had had here.

F

uh Well, I mean they they've, maybe someone who knows a bit more about the current state of s arc and can tell me, but I thought that the there was a bit of an impasse going on over there and sr would like to be able to do in-network in session and uh six-man are saying: no, you can't architectural violation.

F

C

I don't think this: um let's just violate the existing rfc right because uh but they I don't think that can't be called the or what is it if it.

F

Is an architecture, it's an architectural violation, if you, if you, if you um do something, that's contra to the definitive um design of the protocol, well, actually.

B

My point was that we probably need to check with the six man or someone else what they're doing, and it wouldn't be bad. If we said no, we can't do this and then six man go ahead and does it.

F

Well, sort off I mean remember um you, there will be a certain class of hardware that could do it, and we just need to be careful that we also are prepared for there only to be certain classes of hardware that could do it over here. If we do sign it off.

A

Just to add on this discussion, I think there is no problem if you encapsulate uh with a new header, uh no no problem at all there, uh I think, inserting on the same ip header is the issue that.

F

Indeed, indeed, indeed- and I agree- and it's the same here- I have no objection if someone wants to push essentially create a new stack and then um with it, with all its with all its ancillary data and then pop that off and then continue as you were before I mean that's just normal tunneling, so I have no problem with that.

F

It's this other operation, that's a new operation. That gives me some concern.

C

I I I don't think that tunnel is a solution, because many of the surveys um I did just exactly apply to the arena package. If you apply tunnel to it, you basically change the behavior. That's a that's not acceptable, for example, that again the iom is used to just to measure the performance of the um the the normal user traffic.

C

You have to apply it to the to the packet as is, and you don't you, you cannot put it into another tunnel that will change everything so.

D

Does anyone also there are other use.

C

Cases like rfc, oh no, um uh sfc, so functioning, it's just to use the existing label uh to to indicate the um you know the the the the function chain, but you put all the other, uh the the the pass indicator and the index and the other metadata in the extension header.

C

So that's again this you can know that just to do this by applying another, a tunnel header to it, that's um impossible, and we have other examples. If you, if we examine through the existing use cases, we'll find that's not possible uh just to try to use a another tunnel. Header too. Okay,.

A

Are you okay, go ahead, stewart.

F

No, I mean I would just want to know how valid these use cases are. I just want to know for, for example, we say a lot about iom I'd like to know how widely we expect that to be deployed and how much of a reasonable.

F

Case it it, it is um so I just want to know. I mean it's already well, citing use cases, but they don't. They aren't use cases that have ietf consensus yet, and so um we need to be careful when we just you know someone as as imagined a use case. We need to uh be careful how we temper that against what really needs to be.

F

Ietf consensus for a significant change to this major.

F

Protocol- and I think, maybe that's a good reason for um starting writing a use case document and um see how how much consensus that gets amongst the um the the ietf, both in the mpls group and in some of the other groups, that you know that the management group, the people who need to manage it, the people who need to build the routing protocols etc. Do you think we need to see how likely it is that this is to be, would be deployed.

A

Agreed yep, there is an action item on us to start a use case, wiki page and uh I have uh uh updated that action item yeah. I can give you an update on that and you know, while we're at it, uh we can ask the whole attendees and I will send an email to the working group to contribute to the use case as uh yeah.

F

I mean I know we agreed to wiki I I am worried that actually we perhaps really need to get this. You know close to an rfc before, and I'm not doing this to say this to delay it, but these are major major things we want to do.

F

We do need to have some feeling as to whether it's real sorry excuse me.

F

I'm sorry I couldn't get to the mute button in time um so yeah we we do need to do something, or rather to test this before we do major major things, um because it's not fair to well, I, I suppose, actually vendors wouldn't put all the development cost in to respin silicon unless they thought they were going to make money out of.

A

A

Yeah, I think it's a fair ask uh stewart for a document to progress uh and uh to give you know, get blessings on that document before we progress on this protocol change at.

F

Least before we commit large resources to the protocol change yes, so.

D

Tariq and steven, I have like a half a page structure on how to go about the use cases. So when you have a chance I'll, I would like to share and get some feedback on sure sure.

A

D

A

That's great actually kiran and, and I we do have two more minutes- uh that's what the clock is telling me and I'll grab the ball back and uh go back to the agenda uh unless uh you know any uh lower, you want to preempt that.

B

Oh go ahead: it's fine.

A

Yeah, I think you had a use case uh discussion. uh We did definitely have some good discussion here, but I just wanted to point out that we have added this wiki and uh it has minimal uh minimal set of use. Cases that we need to expand on um we've talked about most of them in c2am took a big bulk of the discussion network.

A

Slicing is, uh is another use case that we want to cover and time sensitive networking we talked about it, inserting a deadline, timestamp that a transit router can inspect and schedule the packet uh accordingly.

A

um You know that that the deadline timestamp, where does it go inside the mpls header or after the bottom of stack? That's a discussion you should have. And lastly, network programming was an item that you know. I did not have much to elaborate on. There's there's a lot we can do, but uh we wanted to see what use cases we want to address in mpls.

A

um The document that you have is in the spirit of this right use case yeah.

D

But I have it's a very small one, so let me quickly share it in one minute.

A

Okay and you know yeah- maybe you can add a pointer on that wiki so that we can.

D

Yeah I just wanted to get some feedback. Can you guys see the screen.

B

Yes, okay, you can see it, can you make it larger, like I don't know how to make it larger.

A

There is a 15 yeah. Maybe you need to start everything: okay,.

D

Is it getting better.

B

Oh yeah, that's better! Yes! So.

D

Instead of looking into specific use cases like ts and all tsn and other things, I think those have already been done and I wanted to categorize use cases in the sense they are relevant to mpls and obviously my personal interest is in network slices, and so what I'm trying to do is can we do use cases in some kind of buckets or categories that things that sit on the data path and then something we will have to do from the traffic engineering perspective and the things that are um controlled through the operator?

D

And this is where some kind of service control or the monitoring functions will come in. So I don't know how network programming will fit in here, but something like uh I actually took most of these bullet points from that special label. Draft from kiriti and a few things which were not clear to me were about the entropy and flow id. So if we talk about, for example, entropy here, can we do it better or what are the uh drawbacks with the current problem, current solutions so that we need to do something differently?

D

So but this is the high level structure, for example, we did talk about the slice identifier and where should we put it and the corresponding slo identifier, and these things are discussed in the document? On top of that, how can we use the new model to provide security and reliability for network slices?

D

We can develop a use case around that as well, because these things were extensively discussed in a network slicing framework and definitions context.

D

And then, from the traffic engineering perspective, it is also possible that, for a given slice you may uh two flows within a slice may have slightly different requirements. That is also something we have discussed, and so it will require traffic engineering, type of constraints, some additional information from whatever we are calling fai or the extension headers or whatnot.

D

So those type of use cases could be categorized here and then obviously how operators need to control and monitor their network. That could be a separate category. So this is how I was thinking about it. It's slightly different than what you posted on the wiki.

A

It's a good start, I would say: uh um well I'm you know I'll leave, others to comment and maybe offline. We are over time and now.

C

Three minutes over time.

A

But um you know make sure you add that content to the wiki and uh definitely I think we can give it another read and give you feedback, um but any anyone else has any feedback to kiran on this now.

B

uh Yeah quickly, I think this is good. It's getting closer to what what I need to understand this, but I would actually like to see someone with an interest in the area pick one of the use cases and try to work it through to make it like 80 percent finalized. So we see what we're actually looking for and what the difference are between the different use cases.

A

Okay, you're looking for volunteers, maybe now.

C

A

Have left already, I don't know it was it's a bit late, but maybe we should ask on the list.

B

Yeah, that's fine, but kiran you're willing to work with this. Aren't you especially.

D

So I can contribute a lot from here, but I wasn't expecting to do most of the work here. It's I think we need experts in these areas to fill the stuff.

B

Okay, so where do we have the experts.

A

Oh, who are they.

A

You know it says who okay, I think yeah we should keep it open. We had a couple of volunteers and, on the use case, the documentation wiki at least the wiki. I can tell you who we had on the action item. Kiran was one of them for sure, but.

B

You and me, but.

A

Now there were more, there were more. I.

A

Had uh we had, we had why you we had kiriti kiran, uh lower tarik stewart uh are on the hook. They are.

B

On the hook, well, I think most of those people actually said they are willing to help yeah yeah. So I would actually like to spearhead one of the use cases and see where it goes. Okay,.

C

Yeah I have a, I have several uh solid use cases um uh about how it will works in this scenario and uh yeah. It's actually it's not. I. I didn't see that included in the list, um but uh yeah I I I might in the future uh meetings. I can talk about them.

B

Well, how are you.

C

Actually, what you.

B

Should do is actually add them to the wiki.

C

Oh okay, so so you may I I can directly add this wiki yeah, okay, okay, I'll, try to do that. Yeah.

B

Okay and the kiran, the same goes for you. You need the text we saw here. We want it in the wiki as quickly as possible.

D

Yeah, I would do that and I'll try to add more details for the network. Slicing aspect that I have in mind.

B

A

Okay, I'll, I want to alert you that I'll. I need to stop the recording now soon. uh If I can get a okay from everyone.

B

No, I think it's okay.

A

Okay, then I'll stop.

B