Internet Engineering Task Force 100, 14 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF100-MPLS-20171114-1330

Description

MPLS meeting session at IETF100
2017/11/14 1330

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

A

Hello, can you hear me someone in the back like curiata? Can you hear me okay? So if anyone wondering what we're doing we're trying to find adapters for the projector, we couldn't do that. So we Rick Nick, ran down to the shop and bought a new computer and he's trying to set it up. If we take a few minutes.

A

Here we go so please take your seats, sit down, focus the front of the room we about to start in in a minute.

A

Is this one better that one okay? We use this one.

A

A

This is the mpls working group meeting in Singapore.

A

We have a, we started out with a pretty light agenda, but it's actually been growing over time. So we will try to keep people to the allocated times. I wouldn't just want to check one thing so Fang are you going to do the Jang update, okay, fine? Then everything is set and we have all the slides. You hear we have all the slides exactly one of the first times ever.

A

Normally people come running up, the slides on USB sticks and things like that and I asked rambling cause, giving nick time to.

B

C

D

Think this is okay. Now, yes, yes,.

A

So time to start you have the note well, this is actually the third version of the note well I've seen this week. They are the same. They are little bit different, graphically yeah. It basically says that anything you do say and publish and kind of write down on a whiteboard or whatever in an ITF meeting. Here's a contribution and you are required to follow the IPR and copyright rules set up taken down in in the Odysseys I.

A

Can speak to the room if you want so let's go ahead. We have the administrative information here, I knew rakish. You will take notes on etherpad anyone that actually want to help him can do that, and also anyone that want to takes note during the meeting can actually send them to Tarek. After the meeting it's very helpful to get ex extra notes coming in from different sources.

A

You know where to find the meeting material in the data tracker.

A

There's a meet echo I haven't there are a few people on I, don't see who it is eirick right there, okay, welcome, Erik and then yeah. You have the agenda on slides at the meeting materials which my bad. So this is the agenda. It has filled out a little bit over the last day or two, but we still well within I think we have like five minutes left at the end.

A

A

Stuart, you are not only you. You are number eleven talking about report on what actually was discussed on by in the past working group. Yesterday we have slides, but we don't have it on the agenda. So there is 1111 through Lokhande that agonda okay, move on blue sheets has been started, keep them circulating and bring them back to the shares.

A

We have four aratus. They are currently in a state where it looks like they are not approved, but basically every Sunday mail to Deborah later today and say approval for admin huh hold them for potential updates of the documents.

A

There is a little bit wrinkle on that, but I we covered that in the in the mail that to do we should the last row, the last two virata's point to ipv4 and ipv6, and they wrote essays written point only type of e4. So we need to recap yet, and we approve the data, prove the errata okay.

A

So we have an issue that we discussed in pals working group yesterday and that's on md5 when we kind of designed an LD P like 20 years ago.

A

Md5 was not state of the art, it was just something we used and it's have over time practically become deprecated.

A

We have taken initiative between paths and MPLS work group chairs to actually start writing a draft that actually tells people what is needed to implement, instead of or together with md5 in in the future that we actually can move over to Evangeline.

A

License we have no outcome Laysan, but we should have one. We should actually tell itu-t that the MPLS TP shared ring protection has been published and I think we approved with a couple of doubt that it hasn't gone out and I. Don't know why. Okay.

A

Jump in coming: okay, okay, we also had two incoming license from.

A

Itu-T and BBF vs its riders to us and other working groups. If we need to coordinate on that, we have five new RFC's since last time and that's a little bit funny, because you had people making a routing area, presentation on Sunday and I. Looked at the old sides and I said we are doing like three or four Horace's between each meeting and I said well, now we're not up to that speed anymore, the agreement slower, and now we did five. Instead, there are three four, so we keep in pace next one.

A

We have three documents in the ISD review: Deborah had comments on one of them and I think you will psyche to send a mail to to the author on that, explaining what what the issue is or vxb expect me to do it I do it. She will you send the mail to the or a okay thanks and then we have three new working Doctoroff strengths last time, okay, so a couple of documents has been updated, especially the.

A

Young models for LD, P and I am LD P and the spring entropy label that actually will be discussed later on the agenda. We have a number of working group documents that is going to show up. Part of some of them will show up in a state of support. They actually had two different state to support with doing yang separately towards the end of the meeting, and we doing the other documents in this working group share status. Report. Okay,.

A

A

But this is the I think the header is wrong. It should be non-working of document, because this is all the individual document yep and those are things we looking to actually starting the work into adoption, Paul for in not too far future.

A

A

Yeah, this is continuing the list. So here is a short progress, update the r-mo draft. What the authors say is they are fairly happy with the document as it is. There are a few outstanding issues and they are requesting comments and I've been kicking a couple of the authors actually to go and actually fun people actually do. The reviews.

A

And then we have the ampulla summary fRRR zbt, so it was kind of recently adopted. Haven't changed that much in van please review. If you have a time and then the.

A

The static young and based yang models- they are, they are working progress and they are progressing. There have been lots of changes around, not particularly the draft, but in the environment, for the off so I think you have a stable environment. Now, okay, we asked for a status report for each meeting and this time we have six missing, which is actually a little bit better than used to be, maybe because we have a few address at the moment, but we are. We are getting better and better response on on that request.

A

If you feel that you are an author and have not responded to that request for information, don't feel too bothered. It's not a big problem. Anything is under control. We we know that okay, so Stephen says said not every author has actually got the request. You should have it, but I taught that Eric about okay. Next, okay,.

A

So we ready to jump into your agenda.

E

A

It's interesting when you laptop.

A

F

So I'm Stephanie kievsky I will present you the update on the entropy label draft for spring in question. Sure.

A

I think you sent me mail and you actually presenting a final presentation before giving to working group lost cause again. Yes,.

F

A

Agreement, you and I had I think yeah.

F

Okay, so just a key part of history and a reminder of the purpose of the draft, so we want to give the ability to provide entropy to achieve a good load balancing when we are putting some traffic on top of an SL s. Artie turner and the main challenge here is when we are using an SMT eternal. We are stacking, possibly a lot of labels. So where do we insert the entropy label within with within the stack?

F

So if we are looking at via existing entropy Labour RFC, we are putting the entropy label just behind via maternal label. But here we don't have one toner label. We have many journal label, so if we put it just behind the last label Fermi, there may be some issue for the routers to look at it because it may be too deep. So, yes, there is a challenge that we need to to overcome.

F

So this is no draft, not too old, beta quite old now, so we started in a 2014 and we came with multiple solutions and one recommendation, which is to insert one or multiple entropy labels within this stack, which corresponds to a particular Assad C Turner, and we need to insert was label and at a readable depth to make the routers on the path able to read this entropy label and use it for load balancing.

F

So there was a first working up last call on this document. It was I think on May 2016, but this is working. Hopeless call fail and the main concerns and disagreements- and the draft at this time was first on the definition on what we called V. Our eldest of the readable label, depth and also V n hope. You label capability, as that we associated with it and also ow, was and also the proposal on how to insert was entropy.

F

Labels into statute was seen, as maybe too strict, while other considerations may need to be taken into account. So in Chicago we had a meeting with a lot of people to try to solve this issue, and we came with a new proposal which was introduced in version 5 of the draft, and then we updated based on the comment area we received. So what are the big changes?

F

First of all, the main solution does not change, so we are still keeping this idea of inserting one or multiple ili al pairs within the stack at a readable, labeled F. So what we are improving in this latest version of a draft is, we are improving the definition of our D, so this readable label depth which changed now to what we call an entropy readable label depth why this change?

F

Because in the description we found that there may be multiple use cases for the LG, maybe something else at the entropy label, so how to may be able to look at five labels, but it may not be able to ash env entropy label inside. So there is a difference between reading the labels and being able to do a particular action on the labor that it can read. So we can, with this new definition of entropy, readable labeled, which is dedicated to entropy labor.

F

This means that if someone has an overuse case that involves the ability of a router to read the label stack, there may be over readable label depth defined.

F

So the ER LD definition is the ability for router to read an MPI within an MPLS packet on its incoming interface. So it's as a number of label on the incoming interface, starting from the top of our stack, and the other point is that it's must be able to use these labels in its load balancing function, which is an important point for the entropy label. So this means that, as a consequence, if the entropy label is within this er LG, we are sure that it will be used in the load balancing function of your outer.

B

Critic on Bella I think it's important to say because we're making this change to say you don't have to actually read the labels in between I. Don't.

F

Tell you very well I'm your bit far from the mic I just.

B

Pick up the whole thing. Okay, thank you. I think it's important to say that you can read the entropy label. The rest of the labels are not so important because the entropy is captured there. If you can read all of them great, hmm but if you can read to that point, for example, if you think that you have Micro code, that skips everything looks for a li and then says, I want the next label you're good you're,.

C

B

Mean maybe a little tweak in the wording? Okay,.

F

So the other thing is that there is a need to advertise with ER LD values of this capability of a router to look at an MPLS label on doing via action based on V entropy label. So, as a consequence, if a router advertised the error, G value, we conclude that it is entropy label capable. So this means that we don't need VLC a part of this Aroldis value, it's combined.

F

So when we are advertising the ARD value, it means that the router is and hope you label capable so which may have an impact on how we are defining the protocol. Extensions after to advertise our RG value. We had also some discussion on the bindings hidden because bindings when we are using a binding seed. There is a kind of action of stitching between to LSPs. We can stitch NS our LSP with another SR LSP by, for example, expanding the stack.

F

We can stitch Inessa LSP with an l, DP LSP, maybe with an RSP and as we are doing stitching, we need to be able to know if the tail and the real tail end of the air, ESPYs and Hopi label capable if we want to push an ela yell on top of a binding seal. So there maybe you need to advertise a kind of ELC associated to a bindings, because it's not the end of a particular Turner.

G

Short term and sure, unfortunately, binding seed disappeared from SPF draft by mistake. Actually it was supposed to be the recipe tearily that stuff, but it disappeared completely, while still nASA has dropped, it's still there for lgp, but not for the first case. Where you combine a tunnel, you can.

F

Use it to bind an LDP LSP, so you may be able to propagate the ldl-c from LDP to a saw. Let's.

G

Not argue about semantics, the point being. We will need to reintroduce it in separate draft, given that SPF drafted passed everything.

F

So the the main point is that at least what we need to do is to say that we cannot put an air layer on top of a binding city if we are not sure that the tail end is a and hope you label capable great okay,.

H

Thank you, Greg murski, City, so I understand that you are envision that it could be in a stack that you read. There will be multiple ail couplings there. Maybe yes and the text says that basically, then, how you handle this situation is your local implementation or local policies.

H

My question is that do you think that it might be useful to have with more strict policy saying that the first UIL that you read should be used at some point, question.

F

mmm I think from an implementation perspective, it does not change compared to the existing RSV entropy label. So if the existing and hoppy label processing is just to look at the first one, it works. We are not changing the data plane here.

A

F

A

A minute we are getting close to the end of your time. We are actually going to issue a working group last call within well one or two weeks. Okay,.

G

I

I understand you.

A

Should probably take the comments to the working group last call you.

F

Agree and regarding so the strategy of insertion of the entropy label, so we are considering multiple possibilities so, based on the comments that we receive all so examples.

A

If it wasn't clear, I cut the line creatives in line. No one more I think.

B

We should say that they all the eels that are inserted should be the same otherwise put because if, if you hash on different ones, you don't want to go in different directions. Right.

F

I'll take it to the list, but is there really a need to make it mandatory to be for VL to be the same? I, don't think so.

B

F

To be simpler, better ya know, but it's.

B

Probably not necessary if I always as as a router in the path, if I always pick the same. One.

J

B

It's scary for me that if I pick it different, if I decide to go deeper, that the flow might be hashed differently.

F

So the conclusion, so we addressed the comments that we received, so we hope that we solved via main concerns that were raised and it's time for us to have implementation of this. So we want to close the work as soon as possible, especially because also it blocks via IGP and will be pls advertisement of this er LD. So, yes, we need a new working oblast, call to ensure that we.

A

Have a consensus, thank you.

K

Right standing, the magic box.

K

So I've split this I've split this up into a number of phases. This discussion so first of all we're going to discuss the objectives of this technology and this approach. So our objectives were to tunnel MPLS segment routing over an IP network in order to connect to MPLS are in PLSS our networks together, for example, a pair of data centers. Our other goal.

K

Primary goal was to enable SR to be introduced into legacy networks by tactically introducing s are capable nodes and strategic points so, and one of the the consequences of the way we have chosen is that, though it wasn't a specific object as a specific objective. The system is IP neutral, that is to say we can support ipv4 ipv6. We don't care, it just works. So look at the two use cases. The foot, the top one which we've seen before, is basically a an SR in UDP tunnel joining two SR domains.

K

The other one at the bottom is showing the interconnection of s are capable nodes, but that we're using to tactically introduce SR into this network. So a technical summary of how it works so remind anyone that hasn't seen it so it's RFC 75 10, which is MPLS over UDP. We think that we should focus on just this one encapsulation.

K

What this does is to encapsulate a normal MPLS sid stack in UDP in in IP, and we address the use of the IP address to send the the packet to the next s are capable node along Chane, the UDP destination port indicates MPLS below. So this is IP carrying UDP UDP, says MPLS next and then the we go through the CID stack and into the payload.

K

The IPO control planes are just like MPLS SR source processing is just like MPLS Arbonne encapsulated in UDP and IP to the first route identified by the first sit in the stack to legacy transit nodes, it's just IP, so they simply forward it. Don't care whether they're v4 v6, they can just cope with.

K

It also goes through firewalls nicely and anything else that might be in the way an SS are capable node will process the CID stack as normal, and then re encapsulate in UDP and IP to send to the route identified as the next one in the in the chain, whether you do some optimization like moving just moving bytes or whether you really do a reincarnation. That's up to that's up to the the the hardware designers to decide final hot strips out the header and just forwards, the payload as if out of a tunnel.

K

So a little more detail. The IP, the IP header, has got the source and destination address, and the next protocol will always be UDP. Udp header has got a source port which provides entropy. So this fully supports entropy within the the IP domain destination port is MPLS in UDP. The CID stack, as I've said, is exactly like the CID snack would have been in MPLS, and the payload is the unchanged IP header data, whatever you want you to carry in your life, IP could be a suitor. Y could be.

K

It could be anything soon as the city versus man's advertisements are just like for MPLS segment, routing the IGP or bgp advertises the address of the node or link and the associated said all said. Types are supported. We need to add advertisements in routing to specify the encapsulation type and the inaudible hotpot this behavior. So those are two things that we need to add: source processing.

K

We building impose the LSS our stack, we encapsulate in UDP, we encapsulate in IP and do a fib lookup and guess what there looks exactly like: RFC 7510 non transit, not honest, transit non. This are processing, it's important, that we have to go and be able to transit, ordinary, not IP nodes, and we can just do that. It just looks like an ordinary plain packet. There is not even a hint in this packet that it is special, so it just behaves exactly as normal. It doesn't need to worry about options or anything.

K

So it's just an IP packet, entropy works exactly like entropy does in an IP network, the the five couple or whatever that you would normally have, and the TTL decrements as normal. So she's absolutely standard what about a transit, SR, no processing node? If the packets addressed to me I, do this not otherwise I just forward the packet I. Finally, a UDP inside and I say this is MPLS in UDP I, better, take a look!

K

I look at the top label in the MPLS SR attack stack, extract the CID and look up next hop IP address and pop that stack entry and REE encapsulate the packet.

K

It says here if the draft explains this processing in some detail, because people had been saying that we weren't being quite clear enough as to exactly what has to happen. So what were the key changes to err on back here.

B

Yeah- it's probably not best to call this SR capable the a little more than that so long as you define it. Yeah.

K

Yeah I I we're not precious on the names. If you want to call it something else. So please send your suggestion.

K

Key changes from 0 0, so we clarified the forwarding information. We've clarified what happens in transit knows we care about the entropy handling. We clarified the PHP processing in some detail. Php posting turned out to have some subtleties and we're thankful to for Jeff for helping us out with with that, we've clarified the egress processing and we've clarified. Processing of erroneously received messages, control plane, a summary of the existing control planes and the extensions required to report support PHP have been added so moving forward.

K

One of the things that people have talked about is additional encapsulation types. This draft describes how to do it for UDP. If there is a need for other encapsulation types, then I think the right approach is to write up a series of data plane, specific encapsulation documents that explains how they work in those particular cases, because there will always be subtle, T's so with we think that they should go out in separate RFC's. If and only if there is an established need for that particular one control plane.

K

We think the control plane should also be written up independently, and the reason for that is that, having proposed that we split the data planes, we would like to have as far as possible a single control, plane document that essentially is extensible. So it will just say what the encapsulation type is, and there probably be another document that explains any of the nuances of that, but essentially to have a core control plane document that is capable of extension to multiple encapsulations.

K

That way we are future proof, but without initially cluttering the document up with types that we don't know whether we need on on. So it is a simple solution to a simple problem. It will be useful to have the and discussed in the spring working group and we are presenting it in spring later this week.

K

We would particularly like experts to to flag up their concerns and missing functions and our view the solution, but in our view the solution belongs in the MPLS working group, I.

I

Manchu Manchu from Siena, so I have a working group related question. We have overlapping graphs. You have this. One I think there is a following one, which is identical to this one. So we need to decide as a working group whether we are going to process both of them or we go. We are going to combine or what's the deal here.

K

We're talking to the two sets of authors are talking talking to.

I

You, okay, so you plan to combine the effort and we're talking.

K

Okay, I think we'd like to go on to the next question. Please no, no I mean if you had another question, that's great, but.

L

Don't yeah I had a question related to which I asked on the mailing list, but I. We said that we would support it, but basically the question in the following three envisioned that this technology supports into working between segments routing with MPLS native transport. So I didn't quite hear your question, sorry I. So the question is so. This is I. Call this segment routing over UDP right. Yes, would it interrupt with segment routing over MPLS I.

K

Yeah, actually, that's why the.

L

Way, I would say it working. If that is true, we have to specify the entropy behavior on how you map the entropy from the UDP source port into the entropy label on the Impella site, which was presented by State Farm, and there will be some complications with that problem. Yes,.

K

We try it does do that. My co-author changed it they're already. Checking on that. I did.

L

I read the latest one and I, don't think so.

K

H

If it's not, we.

K

L

Address that we.

K

My main question is the.

L

Draft assumes that that is interworking possible with yes, our.

K

Assumption is the interworking is possible if there's any bits missing, please tell us and we will fix it. I.

M

Don't know how that can you play how to work, because if, as our two men different ADP alia, so how does it knows which the nation IP we can in Cape for fortune for the first hop label.

K

Sorry so she's, how does the how the two disjoint.

M

Assad as a two men, yes, is different at the area. Yes, so he hotel, he knows to label the label, let's label we can in cave which nation I p yeah.

K

Oh right, how do you know the labels in the two different domains.

M

Because we change the label to UDP header, so it must know which IP with this nation IP is the canon cape, well I, guess with I. Think.

B

It's about, how do you know, which is the next s, are capable.

M

Node I mean if it is tragic area as a domains to add area. So you can you can there, if you don't know which, which new IP kin-yuen Cape so yeah alien? You can sit.

A

Down, if you good, I, think.

K

We can answer the question actually: okay,.

A

Right try, it would be quick, we'd be running away over time. I must.

K

Stand here then,.

N

I think the answer, if cur it is a restatement of your question is right- is that you do not target the next s are capable node. You target the next node identified in the SR stack, so the UDP tunnel goes between things that are in the SR stack. Not between us are capable nodes. Okay,.

A

And rest take Liss now next to say: oh, if we have to add stuff, we will using current.

O

Hello: everyone I'm Tiago from Huawei. Let's talk about unified sauce, well, construction, using MPs label stack.

O

Major changes, since there were three version include the number of coaster on frontpage had been reduced to meet the causer number limit requirement.

O

Some tests had been ended to clarify how to a while and really performing hash on the amperes and Rotom packet. When we encapsulated that MPs 17 packet with IP based tunnel tender such as UDP tunnel, handle most specifically when a capture later couldn't obtain. At least one Egypt label from the label stack does receive the MPS as our packet. It strongly recommended that trippy information carry in the original you see. Mps over UDP packet should be stored when stripping the label stack when sleeping the UDP pan handlers.

O

In this way, the triple handler could be reused. That means it can be directly copied.

C

O

F

O

Tunnel handler in this way it can overcome the load. Balancing issue associated with the current MPS Emirati scheme due to the label label, stack deep tips and maximum label in certain capability hardware limitations, as you can see from this figure no matter, the underlay is MPs ipv4 or ipv6.

O

The sorting instruction it uniformly encoded as empty label stack in this way.

O

This technology combines the best of the two technologies, that is simplicity of IP underlay and the flexible programming capability, the MPS overlay. That means in this approach, the chaff, engineering also salting capability- is realized as an overlay capability.

O

And you can see from this figure the unified, so loading can be seamlessly integrated with the current MPS Rypien technologies by using consistent network programming, instructions that is, mps label stack.

O

Since the unified salt routing layer region, the existing, powerful, MPs and routing technology can into work with existing MPs and routing technology seamlessly, and it's very beneficial for the Ingram incremental deployment of MPs and welding technology. For instance, in the EPE case, the fabric between the u.s. and the ingress could be IP fabric.

O

There no need to upgrade it to be MPs fabric. In fact, Google pressure is a concrete example of this usage.

O

First Universal rotting leverage existing hardware capabilities such as MPs as our forwarding capability and then MPs of EDP tunneling technology. Second, it fascinates the Ingram incremental deployment of MPs, as our third is overcome, the load balancing sorties associated with the parent MPs as our first, its can seamlessly integrated with existing MPs within technology last. It works across both ipv4 and ipv6 Conway's.

O

Implementation status currently Nokia has implemented it. Cisco had developed demo for this June. While we had decided to implement it. That's all any comments or suggestions.

P

This is Andy Cisco Systems I can see that this draft I'm a co-author in this draft and the previous one that was presented. They are not really offering any new MPLS standard. They are not offering new behavior in the MPLS forwarding plane nor the control plane. Is there a particular reason why they are sitting in this working group.

P

Spring is a much more appropriate work there. For here, that is really I mean MPLS over UDP is an RFC at the lsfr. Gre is an RFC MPLS of l2tp is an RFC. Why is it this sitting here.

N

Adrian Farrell I can answer for the previous draft, which is 75. 10 was done here, and this is basically a statement of how to use 75 10 and it doesn't change segment routing. It doesn't change MPLS. It's a really simple use case.

P

If it's a use case for MPLS or spring, should it be informational, for example, or is it wiser to standard track.

N

Yeah, who cares that sort of decision can be made 100 years in the future when it becomes an RFC? If.

G

So vim Broadway right point about mapping between entropy field and UDP header and entropy label, so entropy labels could be good when they increase entropy. They could be extremely bad when they cause different treatment within same flow, so there are no difference in the way it drops describe this right. What we need to define here in this working group its how properly map, because every time we hit a star capable not that address it- will have to do mapping mapping has to be done in a consistent way. It will use additional hardware resources.

G

So good thinking is needed to address this and it's different than 75 10.

P

If we were talking only about mapping the entropy to the UDP port, this has nothing to do a segment routing. This is MPLS over UDP right, but this is called year segment. Routing, if you want to, if you want to do something related to MPLS into IE, feel free to do that, but not use the terms source routing because it has nothing to do with it. You I can do this for VPN labels. I can do this for whatever label its MPLS. Only so you meant routing should go to spring.

A

Can you explain the difference between this draft and previous draft.

O

Co-Chair Lauren Matheny is the purpose. Email the to technology are exactly describing the same technology I think.

C

In my point is.

O

They are describing the same technology from different styles. Maybe it's the word job in more suitable for those guys who dislike amperes or not much family with MPs. So we need to disclose some details about how to use amperes, Oh, UDP.

A

So please respect I, only cut the line after Ollie, so please sit down and.

Q

A

Did cut the line if you didn't get it.

Q

A

All the time due to the list, that's right, it belongs, go to the mailing list and that's very long.

A

Yeah, that's what I were going to say. There is a further presentation of these two drafts in spring tomorrow. Maybe we can take more discussion there, but if I remember this spring again, that's pretty full oops.

R

Yes, Martin speaking, they are on spring agenda and we have 10 minutes dedicated to the discussion on the tool, raft, 5 minutes presentation and ten minutes discussion. Okay, if you want to discuss more, you can.

A

It's great Gregg, it's your.

H

Okay, it's probably reverse, or they thought but never mind. Okay. So recently there was a discussion on mailing list about bootstrapping clarifying the procedure of bootstrapping beef, the session over NPOs OSP using LSP thing, and the question was that what is the behavior of the far end and agreement and I believe that there is proposed text that everybody agreed is that the behavior is determined by to follow RFC 82 29, which is a new version of OSP thing.

H

That means that the sender of OSP being that bootstraps MPLS VFD sets a return mode. Our it's working but RFC 58 84 states that the if the control packet has to be sent before any reply will be sent to the OSP thing, which kind odd, but at least understandable- that that purpose of this LSP being that bootstraps, the beef. This session is not to verify liveliness of LSP, but the bootstrap FD, and actually that's. Why I mind the predation. There is a reason to send a control packet first before they reply at the same time.

H

So there is ambiguity in 58 84 what to do what the far-end does with their beef D discriminator t o V, if it commanded to send reply, should it include it and then how that reply may be interpreted by the sender, because just single locally allocated discriminator by the far end is not sufficient to identify the BFD session, because the sender of echo request requires its own discriminator to do the multiplexing.

H

So here is the proposal that sender of ingress lar should set require mode to no reply and responder should not include the discriminator till v in MPLS echo reply when replying to echo request with a BF d discriminator tod, I had a comment on suggestion on a list from carlos that he suggested that it might be more elegant to say that ingress lar must ignore, be the discriminator. If present in MPLS LSP echo reply, that's nice too. So.

H

Because we discussion- and it was kind of extensive discussion- I- believe that it will be good to agree on some behavior how to reflect this behavior, whether it's errata, whether it's a 58 84, this or draft or non evolve open to the working group discussion, suggestions and probably we can do it. Oh here is Caretti that his opinion definitely so.

B

um Kuryakin Pella, the first thing is I'm, not sure what we're trying to save by saying that there is the the LSP ping should be sent where they do not reply. You can send it, but they do not reply. But typically, today it's sent with a reply. The problem is, when you send it with a reply, and you don't get a reply, then you think the LSP is down from the ping point of view. The BFD is something else, the so I.

B

If you go back to your previous slide, I'm, not sure why that's in I think I. Okay, if.

H

I may respond sure again. The purpose of bootstrapping of sending this echo request with the BFD discriminator is bootstrap the BD session. Okay.

H

So that's why I think that, logically to say, I want this BFD session and I really don't care about the reply, if the be, if this session is up, if B, if this session fails to go up, you will send me reply with error code.

H

B

All I'm saying is it doesn't matter which way you do this so long as you're consistent? If the sender says, I want to reply, send a reply. The BFD session comes afterwards. I do agree that for the second part, either don't send a discriminator or ignore it when you receive it on the ingress, but the first one I think is.

H

Again, that's why I use should, because it's like a clue that there is no good reason to send it with a request of reply. But if you want to you can so you are still complying. That's why I shoot I mean.

B

Ping is an independent way of knowing whether the LSP is working. Eft is a different way of knowing it which can operate at a higher speed, so I think it's just yo for the cost of one packet make sure the ping is finished, and then you can start your BFD session I mean. But that's just me again.

H

This is just a proposal: okay,.

B

And then, if you go back, one more slide, I agree that it doesn't matter in which order you send the BFD message and the reply. If you are sending a reply to the pink, this should be independent. Okay,.

H

But I need to point. The current text is quite explicit about it and that's one of the reasons why I put no reply, because that makes implementation easier. Sorry, I have this scar.

A

H

I know: okay, yes, thank you. I.

A

H

Iiii eating my own time.

A

H

Okay, let's take it next I will try to be okay, be in demand more over. So this is an update. The first presentation was in Prague and the idea is that in point-to-point we can start as a sync mode and then switch to demand demand mode. So that's the basic idea of how to use the main mode for MPLS LSP over point-to-point.

H

So that's a history. The scenario is that, because the return path might not be are correlated with the four or five that exactly with LSP that monitoring the proposal is to once the session comes up. Their ingress, lar I can set their demand flag, which forces the node B in this diagram to cease sending VFD control packets.

H

But what we suggest is that once B note determines that there is a failure in VFD, then it sends with the control packet over IP network indicating that so it's lost in diag mode that we sometimes refer as are di indication and that's the red one. It's update so that clarify how encapsulate the packets and note a will respond over IP because again receive notification of the failure.

H

There is no reason to send the packet over MPLS LSP, because remote node indicates that this failed Whitely failed, so node a will send a VFD control packet with the F bit set, which will indicate to be to cease to send this trailer identification packets. Otherwise the big continues to send them once.

F

H

And node a at the same time marks this VD session as done goes to our lazy mode and then switches to demand to a sync mode, so switches to sesang mode since packets once a second. If this path is restored, then B again will respond to a sync mode session will come up and a again can put the session in demand mode. So here we go again. So that's how it's envisioned. We welcome comments. Suggestion, questions and yes, I, think that we clarified where adoptions might happen. Ok next place.

H

H

Okay, that's as well update to their work that Ben first presented in Prague in.

H

Spring so so happened that we have only so far LSP pink defined for MPLS data plane and this work tries to complement and expand on spring Auriemma to set and discuss and define, describe applicability of point-to-point VFD over segment route with MPLS data plane.

H

There are two options for encapsulation, so it could be encapsulated as with IP UDP header, as described in 58 84, using the Martian destination IP address for the four in the six or it could use Gale label and ACH encapsulation.

H

The problem with the ACA sh encapsulation is that then we don't have a source information and the source information is helpful. Doubt that's. Why we're proposing, if r1, to use a CH encapsulation that you will need to use this source TLV again, BFD reverse path like in 58 84.

H

It could be decided by their local policy whether to follow IP network or some available segment route in the reverse direction, but at the same time there might be scenarios where controlling reverse path is useful and we propose to use with a bootstrapping weather, VFD, discriminator, TLV control, be the reverse path that can specify you either facts as a segment route or can specify segment route as a set of labels, for example in central control environment. It might be a useful way to define the segment route, just a set of ordered set of labels.

H

We had a discussion and something that we intend to update this document. The point that this new tell V will be a new entry in Ayana registry, so it would not be in effect sub govt registry and again, we are looking for comments, questions and working group adoption time.

A

One question yeah.

Q

So, for because these LS, these are you know.

A

Q

Color, the you in directional.

A

A

Q

So I see no mention for a similar TMP where you don't need is bootstrapping and everything, and it's simple and it's fast mm-hmm, okay,.

H

So you're asking why not seamless beauty? Yes for many reasons, and we can better discuss it on the list, but I would say that seamless, BFD less controllable, so you cannot say where the return path is seamless. Bfd is okay, but.

F

H

Can discuss it in more details in the list? Okay, thank.

A

C

A

Next, no more questions on this. You have to take it a list.

C

A

Now, if I spaced out evenly as nine minutes.

N

Okay, I'll try to do this quite quickly because it's already been presented in the SFC working group, so this is another of those documents where it has their slight debate about where it should live so slide about. Where should we talk about it?

N

That's all the chairs problem for those of you who don't know SFC a quick architectural overview that packets are classified given a service function chain that needs to be executed and that's expressed by forwarding through service function, forwarders, SF, FS that deliver to local service functions, get the packet back and then forwarded onwards. There may be a thing called a proxy between a and s FF and a service function, and the point of that proxy is to allow you to use legacy service functions without being exposed to the SFC mechanisms.

N

So what we're trying to do is not obsolete or replace the work that the SFC working group has done, but to enable that work in sorry guys and find it really hard to concentrate on talking while you're talking, I.

N

Sorry and I don't mind you having conversation, but if you want to do it while I'm presenting please do it outside, because I can't think and hear you at the same time,.

N

So yeah we're trying to enable the service function, training function in existing MPLS hardware, so essentially we can make an MPLS router that exists today into one of these SF F's, and we want to do that in a way that supports label swapping and label stacking as well as mechanisms, and we want to achieve everything that the SFF SFC architecture allows, including metadata.

N

So what we're doing is using a basic to label unit, that's a context label and a service function label, and we we push those onto the stack and we use them slightly differently for swapping and segment routing. So in a swapping case, this maps nicely to the fields in the nsh that the SFC working group defined.

N

One of them is identifying the service path that we're on and the other is showing where we are in that path to deliver to the service function and we get the TTL as well for free there and that looks sort of fairly logically, like the nsh there's a little bit of constraint that we're playing with only 20 bits where the the nsh has got more bits to use. But that's just constrained on the number of paths that can be supported in the network.

N

The stacking approach takes multiple instances of this to label unit and you can use that as the context label delivering to the SFF. So it's a it's a SID and then the service function label underneath delivering to the service function.

N

That's local and then you strip those two off and off you go along the path metadata is, is the big question and possibly the the main reason to do this work in the MPLS working group, putting metadata inside an MPLS packet between the label stack and the user data is something that gives me the heebie jeebies, but so we we've defined a way of doing that with indirection, where you push in a special-purpose label and a label that says this is where the an index to the metadata and.

N

That that table that that index, what it maps to, can be populated by a number of different mechanisms in band out of band management, plane, etc, but we define a way of doing it in band, which is to send a packet which has all the labels on the top. That will cause the packet to follow the service function path, but instead of having user data there's a special purpose label that says what follows is metadata, and then we pick up metadata encoded as an LTV.

N

Just the way the service function, training working group have defined it, so the this data would follow the path and would be picked up by people that care about it and otherwise would pass through.

N

So we've been working on this a little while and and polishing it. The author thing here, it's relatively stable. It took us quite a bit of effort to come up with a solution that looked as close as possible for the label swapping and the label stacking approaches, and we wanted to make it work with the best control plane document. That's out there.

N

We think, from there onwards it's pretty obvious and it's in the MPLS charter in particular, because it asks for new special-purpose labels, but we leave it up to the chairs etc, to decide where to put it and then questions.

O

You propose to MPs based searching approaches in the former is same that you just propose another containers.

F

O

Contain SPI and si values is my understand, correct.

N

There's a 2-2 label stack entries, converting.

O

The note reuse, existing MPs forwarding papers right, it's a no difference from them. I set you based.

N

Forwarding behaviors it's no different from the forwarding behavior, except that it will work in existing hardware. No.

O

N

O

Different dead format, but the current champions forwarding behavior Athene quickly changed the.

N

Current NP RS forwarding behavior is well I, can't speak for your hardware, yeah.

O

Yeah, in addition, it's also a state for self chain approach, its Mac, similar to the asset based approach. Do you think we need to stately estate for searching approaches being idea.

N

Do we need stateful service change? Yes, the service function. Training working group has defined stateful service.

F

Function join him.

N

So yes, I, do think that the RFC that is shortly to be published is right. Yep.

O

But in your job you propose another container for SPR and si values McCoy chains. Do you think it's value to reinvent the MPS label, stack format based search approach, white.

A

O

A

Know this start to look like discussion, it's very suitable for the main list. Okay, it's taken two men. Listen to that! Oh you.

K

A

People in the queue now next.

O

A

O

Difference because.

A

I mean cancer on this arm.

Q

Yeah, it's a do not have the same. Commenter and I said see that the reason you're saying that it should be here because you're defining a solution and there's need to be worked here but I think before you define a solution. It needs to be dealt with. Nsc group, where.

F

Q

Is expertise in terms of is this right approach, because there.

F

Are other proposal.

Q

In this area and doing this work in ambulance working group as a starting point would be wrong thing to do, because this is not the place the need. We can come back here. Yeah.

N

If you're saying I should present this in a service function, training working group I agree with you and that's why I did earlier. Okay,.

F

Step on home, Orange I agree. She said this is an obvious solution. It's a straightforward! You just told that you are targeting the existing hardware, but I'm clearly worried about the label stack size and the ability to push as many labels, and we need, especially because today we already has some issues with SRT yeah.

N

I tend to agree that, certainly a significantly long service function path might have some challenges with the label staffing approach.

N

Although it's it's kind of neat that you can indicate the the SFF in the label stack but yeah I mean I, it's a kind of trade-off between Stewart and me about which we like and I, particularly like the swapping approach. Yeah.

F

I fully agree. The the main point is that we still have this boundary of how many label that we can push so as a vendor. Do you think that, with the next generation of hardware, we can put I, don't know 30 labels to ensure that we can cover every use cases?

F

Ten, tens of thousands?

F

N

F

You will be able to do this. Yeah.

N

I agree there are, there are limits. Thank.

M

L

One thing: women Erik's from not women, Eric's, not here at one clarification when we do metadata in the stack case, do you envision to copy that metadata in in multiple parts of the stack if the service function needs to consume that all the time or how would that be done? Yeah.

N

We in so this isn't stashing approach, obviously not swapping guys. Originally, we rewrote it up like that saying. Well, you can put metadata multiple times in multiple places because you might be targeting emitted. Some metadata at one service function on a path and some metadata somewhere else, and then we looked at what the nsh does and the the nsh is. You know the metadata goes all the way through and thought. Well, let's start with just putting it in once, because.

L

We need to have a behavior on how we interact with service functions if they do not, let say, support that metadata and stuff like that right. So.

N

Yeah you define.

L

N

You're absolutely right, but that is an SFC working group problem, because that problem exists in nsh.

L

Okay, but if we define here to be either on and Billis transport, no.

N

That so the the, if you get metadata, delivered to you as a service function, and you don't know what to do with that metadata that the behavior for that is is for the SFC working group. Yes,.

L

But there will be an implication of that behavior based on the MPLS. That's a label stack which you are imposing to that function. So.

A

My feeling about this is a excellent discussion for a mailing list, both here and in SOC. We have Jim coming up the chair of the SV working group. If you want to comment now or comment after the Lord next presentation you can do which everyone know.

S

I was actually just stretching my legs, but so no comment.

T

Hi, my name is Sherwin from juniper Networks. Actually, we propose another nice order for the to leverage. Mpi was a protein together with SH for the service training function. Somehow so, on behalf of all the causes we kind of proposed this matter previously so who mentioned so the unified its source routing? Somehow the name here we can overcome the boundary between the IP and mpls and which is perfectly to define a pass for the service chaining, maybe in between the multi-party center and so on.

T

So whether this is a am PR space, D, Center, segmenting, visitor center or IPP city center, all the services can be passing through here. So then on. The next part is here: if you look at the service function here, so a majority for application right now, they don't understand segmenting our NP RS capability. Yet and a lot of capability boxes not even can manage the the network service either function. Yet so we I actually proposed a measure for SS SF further to assign a label for service function.

T

Here we know we had the in discuss with other people to try to assign the label for the service from pass. The hope has for another label somehow. So it's still in discuss right now. So, but the idea here is kind of or you landed it into the service function and the services of order, whichever the in a different packet order, the sequence here: the label design, which know that you go to next, then some special special function like a here.

T

We have a self-service function, which is we need to remove all the label stack and maybe pop up the network service header for that which we can discuss in later here. But you can see the proposal here actually proposed. You can the controller or service provider or anybody can define the pass from the very beginning either way this one is a label or the IP here. So even in the middle here you have a No, Sammartino IP capability box. Here you still can design assigned a label for that one for next one.

T

So the here's the label for four other two here- maybe the OVS software capability here when this one handled all the process here, then they come back with this label. They will map into the UDP tunnel or the UDP interface then send directly to the OVS to process and so on. Then you also have a service to classify and you can you have an antenna solution here, so we believe our segmenting or MPAs label could be a very good way to do. The final pass.

T

We're never intended to include the meta data directly into MPs label stack, is causing somehow our problem and so on so but there's indicator shell, who mentioned for the MPS packet forwarding, then you, if you try to include another header, such as a message here, you can indicate the next header will be message here. Yeah I mean that can be part of this. The transportation pass can be part of the even a TCP session, the the metadata somehow, but we use message as a container to contain the metadata.

T

Only then, all those kind of a pass related the information- will go to the MS label or the UDP tunnel here. So the idea here is for those service function. If they can understand the same protein, understand a network southsider, that's good, so we can set up the neighbor directly to them.

T

Maybe they can understand that if the the the guy doesn't have any clue, then in that case, I may need to remove all the labels here and if they can't understand the network sets to decider, then I will pass all the networks of spider information. Spi. Si information to the processing then come back then base down those one. We can put all the label back here so sometimes there's a mapping between the requirement for them.

T

Mapping between the network service, header and the sex I'm routing label stack here, but let's put a more stateful information on the SFF here. But if you really want to keep this as a for other very simple, you may have.

A

T

So basically, the here is the advantage of all this. A proposal is kind of. We know that a lot of people working on the vias, LOM + SH a solution. So here we actually a proposed big because that we Aslan such only can't define one segment here. They have known I, don't have a pass information. So our proposal, we have a pass information which can provide end-to-end solution. Then we have a less status on a folder here then we regarding the performance here. We do not need any special treatment here.

T

The performance will be MPs performance, very good here, so do the post for IP and ambiance at here. So that's all from my session.

A

S

Jim Keisha so actually have a lot of comments, but but I'll try and keep them small.

S

So so I understand why Adrienne's doing what Adrienne's doing, because you know and he's not hiding the fact that MPLS really can't mimic everything that NS age can do and and you're very clear about that in in in the document and you're trying to get a mechanism to do a kind of n sh thing using the existing hardware.

S

So so that I can appreciate what I'm struggling to appreciate is why we want to build service chaining capability into segment routing when it's already been done, bearing in mind that n sh could quite easily do the segment route in function. If we wanted it to, we just haven't pushed that and and if you think about it, a traffic engineer path using an SH is simply a service Jane Bill of SF s sue them. So so you could do that quite easily with n SH.

S

Now the biggest problem is the services, and you need to talk to the service vendors because they're, not typically at least from what we've seen they're, not interested in having to build an MPLS stack or a segment routing stack on their devices. They want something simple and easy to implement, which energy H is yeah, understood.

T

S

Now, if you insist on doing it with segments rowdy and then my my my suggestion would be that you actually integrate segment routing with nsh. In other words, what you do is you strip off the segment routing at the SFF, and you use the path ID from nsh, coming back from the service to tell you which segment routing stack to push back onto the packet.

T

Yeah actually very good suggestion we actually think about it to SPI to get back all the understand.

A

It was that yeah. Ok, thank you line, cut off Sam, okay,.

J

A

I think one question to even first Jim Jim, ok, so I think that the appropriate thing to do here is that the SOC shares and MPLS working group shares actually discuss on how we want to proceed with these deaths. Okay, thanks, ok, less than one minute Sam, okay,.

J

Sam Waldron I'm trying to understand you're, bringing the context of data plane into yourselves, so you're pretty much making every SF to support the data plane. So.

F

J

Question for you, there is what, if it doesn't support. Sorry, mister question. So what's what, if the SF the Nord support the network's tab? Oh yeah.

T

It so the SF of service function. If they don't support any side. Note you know SH we can remove from SF folder and passing all those information to the search function. We can remove it that we can. We are thinking about to get back out early by the liberal stack so.

J

In other words, let me ask you white: why do you have to push the data plane into this whole realm? Why can't you do just.

A

T

A

For each presenter left so su Fang you next.

A

It's not the right presentation, we know that.

U

Right this is a presentation supposed to be done by Taric, but he is not being able to come here so I just give a brief update on behalf of a Eric.

U

So this is update on the activities for young modeling in working group. We also provide some information for the dependencies in other working group which are using our models.

U

Okay, here's some working group documents, so we have on campus I'm Kaz static, hardest piece and I'm PRS, our DP and PSI mara TP. So these are for working group documents for the Empire's base and Static we're still working in progress because recently there are some changes in the young area, so we have been waiting a little bit so now it's a pretty much ready. So we are walking around the updating the model copy, an MBA, an MBA combined and we were trying to, along with the some other models affected by the nmda architecture. So.

U

Those models in cause not naught RC 80/20 to which is ITF routing and also the interface model 7223. They have posted an MBA comp and model, so we are ready to update our mode also and also we are trying to align the model with the another draft in the RTG WG, the rotten pipes.

U

So after that, we also trying to get the review from young doctors, so those are the items were to which we are trying to do for the photos to models, and then we have our DP and armor DP those two models or will be recorded separately next from buy camera. So this is to pre-k the size here. So we have other working group documents from other working groups which are using our models, including the RC bt e BF d e and s are.

U

We are have some individual documents here. We have Orion related and here's tpoem and rs peeping and the author's are actively working on those models.

U

They are committed to finish the work and they are asking for comments, feedbacks situations and any active participation.

U

So we also work many feedbacks. The comments are any thing, we're missing here and the team or be happy to finish those that's it.

A

Okay, thank you.

H

Just a quick note that probably I should have mentioned that and helped in the slides that next for M POS OEM yang models would be 374.

A

V

Okay, hello, everyone I think you're running late for the time, so this is going to be a very short update, anyways. So this is a combined update for LD PNM LVP yang model activities that we have been doing so first I'll go through LD, be a very quick one and then we'll go to M, LD P. So since last ITF I, post ITF 99, we have few things pending for ml DB or for LDP drafts.

V

We got a couple of reviews by young doctors on our revision, one as a revision revision to that we have to address. One of the major comment was to align with this NMDA model, a revised destro model, as well as specify some other default values and some other clean up. So these were the main pending your atoms forever or LDP draft pending that from post ITF 99. So what we have done since then the meteor the team has been meeting since then.

V

We have addressed most of the comments from the young doctors review on revision, 0-1. Actually, all of them from the young doctors review comment on revision 2. We have addressed some of them, but we haven't fully finished addressing all of them, so we plan to do this before the next IDF and we have a palatable model to become an MVA compliant and we have specified the default values for most of LTP parameters.

V

There are still few pending things pending discussion among the author and the teams, and we have changed the hierarchy a little bit that I'll go through in the next slide, so this unfortunately missed a deadline for 10:30, so we posted drop just on Monday yesterday. So so the tree now in LDP looks like basically LDP discovery. It was mistakenly under global, so it has now moved back to.

V

It has moved back to now like an on the same level as appear and the global her rks, as well as in terms of open, config star that we have originally in our model. Then we started way back in 1992. Since then we have actually presented this model update a VI TF. Almost it was config in state model. So that's gone now, so it's now an MVA combined. So we have only rewrite parameters as well, as you know, read-only without any specific configured state subtrees within our model.

V

So that's an embryo comprised we have done for the next step for this model, as I said, we appreciate. First of all, we appreciate yangjia receive you excellent comments. We have few comments to address and we have. If any further comments comes, we have to adjust those I think we as an author. We think that this document is getting very close to working with last call. Once we address all, there was remaining comments as well. As someone will clean up. We expect this next revision of the document to be ready for a working with Pascal.

V

So we not yet calling but can go last call on this document, but hopefully by London ITF. We should be able to call a working to blast cause or it goes out last call on this document, so that is the status and LEP any comment: question before I go to Emily.

A

A

Call before the next idea, we.

V

Are not calling yet I'm saying we are hoping that if once we address all the yang Yang dr. zira comments, an extra vision that will post there should be almost ready for anything, will last call I. Think we'll make this call at that point in time. So we're not calling working class call yet any other comment.

V

All right, I still have M.

G

V

And that's a short one yeah! It's the same side drag after that, okay, so all right so for 4m, l DP also is getting close to you know his final. You know final journey, the main changes V, which were pending for ml DP as well, were alignment with the nmda. Compare you know, data model as well as default values for our configuration parameters, so we have since last ITF also updated or model to become NMDA compliant.

V

Changes are very similar to what I, just you know, highlight it in LEP, and we also review posted revision 3 for this. This particular draft on Monday, together with LDP drove for this draft. We haven't even request. We haven't even gotten yank across review and I. Think we're formally requesting a review.

A

V

A young doctors at this point I'm already questioned yeah. You already questioned lower thanks a lot, so we have requested a young doctors review and then we hope to get some comments and address, adjust them in appropriate time and post a new revision. So for this document next step is not working. Last call basically to address you know: young doctors comments that we get, but next ITF LDP is the one that we are pushing and hope it hoping to get working blast cough.

V

That's it a short update on LD penalty drop, any questions.

A

Okay, thank you.

A

Now we actually back on time so I think Adrian next or Sharada.

W

Good afternoon so I'll be presenting the MPLS SR path, identifier. So the problem space is an interface is running hot and it's in s our network, so multiple SR paths using that particular flow. Passing through that particular interface. We need to find out which s our path is taking, how much traffic and based on that. We need to reroute the SR paths, so the SR does not have any state in the core. So on a transit node, we really can't figure out which s our path is carrying.

W

How much traffic in a very easy way, counting at the ingress would also not be sufficient, because SR is inherently CMP aware. So what happens is a if you measure traffic at the ingress? You really because there is ecmp hashing in between nodes. So you really don't know in a particular transit link which s our path is contributing for how much traffic. So that's the problem, space and also the source, because in SR you just pop the labels and then you move on. So you really don't know where the originator of the traffic is.

W

So you only know where the traffic is headed to based on the remaining labels in the label stack.

W

So high-level solution is to insert an SR path, identifier in each MPLS, SR packet and then count them based on this identifier.

W

So the the sod path identifier, has to be globally unique because you are going to count on a transit node, so the asad paths which are passing through the transit node should be globally able to identify the SR paths. We should be able to find this globally unique value in the packet header, and then we should be transparent to. Let us see input implementations, yes, do.

K

You mean globally unique in the true sense: I mean ipv6 globally unique. What do you really mean domain new, unique.

W

It's a unique identifier which, which can unique, uniquely identify the SR paths in the entire network, irrespective of from what the ingresses you.

K

Mean the main unique yes,.

W

H

Okay, so if you're planning to use this or any function on a transit note, then you will have the same problem as an entropy label. Yeah.

W

We can go into the solution space and see what the solution is and.

H

Another question is: have you looked at draft and POS source label from 2014 Yeah.

W

Right, yeah I do have taken a look taken. A look at the source label draft phew you a couple of years ago, I guess in MPLS, yeah.

F

W

Similar but it was not putting a unique path: identifier into the packet: it was putting a source label, I guess so, with just the source label, you will be able to identify. Who is the source of that and from that source there can be multiple SR paths. You wouldn't be able to figure out which SR path, yeah.

H

But see the thing is that even with the second label you have, because in the transit notes, you can have a CMP you're still losing this physical path identification. So you only know where the source of segment route send it. But you don't know how the note traversed, because this packets can be a CMP in the transit, knows yeah.

W

So the problem space is to on a particular transit link. The problem space is to figure out how much traffic a particular s our path is carrying. So problem space is not to figure out what is the exact path of a particular s, our paths, you know the problem space is like you have a link which is running hot and you want to know which are less that path. So you already know which are less. Our paths are going over that link and you want to figure out how much traffic each one is carrying.

W

So that's the problem space we trying to address.

Q

W

Know this kind of distorted picture so.

W

So the presence, so we are inserting a path identifier into the label stack, so we need a way to identify that there is a special identifier in the label stack and it's not really a label which can be used for forwarding to identify that we need a special indicator label and this has to come from MPLS reserved label space. So this is called s our path indicator label and below that there is s our path, identifier.

W

This is a unique globally unique value for each s, our path. So this is a 19 bit identifier and there is one leftmost bit which is the C bit, which indicates whether there is a node identifier below it or not. So altogether you, you have two models. This is the first model where there are three additional labels. Getting added first is the path indicator. Second, is the path identifier and third, is the node identified. Node identifier gives you from the originator of your ingress node of this particular SR path.

W

So the advantage here is if the path identifier is globally unique you you always know from where it originated, but if it is local to a particular node on which it originated, then you really need a node identify. So when there is a node identifier, this path, identifier, is coped per node pouring rest node. So you get 19 bit 19 bits of path. Identifier and.

W

20 bit of node identifier, which together, can be used as a unique value to count the SR path, SR traffic, for each path, so the second model is just uses just two labels. The top label is the SR path indicator and the bottom label is is a path identifier, and the C bit indicates that it's a to label model based on whether it's 0 or 1, so in in this model. The path idea fire is a nineteen bit identifier, which is which has to be globally unique across the entire SR domain.

W

G

Yes, so set you're going to end up competing for label spaces and rip your labels. However I think so, how are you going to derive the binding between special label and, let's be associated to it? They're going to be sounds out of bands. That's going to do the correlation right. You'll have something name of the counter, probably so I'm not clear with.

W

G

To resolve value of the special label to the counter associated particular LSP right, yeah.

W

So the way this works is the forwarding plane will look for the special SPI, which is a MPLS resolved label special label. So you know in the label stack the the forwarding plane is going to look for this particular label, and then it knows that below. That is an identifier. My.

G

Point what you're trying to do is more applicable the generic MPLS, where we've got 20 bit label space in segment routing any label outside the sRGB is special anyway, and we've got a Cyril B, which is the local block which could be the for this purposes and it just seemed a label per domain. So your space label space is shorter and it's already it's their plane. So yeah.

W

I understand what you're, suggesting and I think that could be one of the solutions where you you. You allocated a special global block which is specifically for asar path, identifiers, and then you provision it on every, nor that this is the block which is special, which is which is specially used for desire.

G

You, sir, it's called SRO B srl.

W

B is local block. It's local for every node.

W

So Jeff I don't think srl B can be used. We can discuss offline because srl B is local to a node and what we really need here as a global block. It's going to be a new.

G

Global make it global from configuration management perspective. At the point being you only need one label, you don't need special label and then indicator that there are special label nope.

W

You still can't use the same because srl B is already being used for binding sites and other purposes. So you really, you really need a special block which says. Oh, this is a star path. Identifier is used for counting and not for forwarding and that doesn't exist today in yes on, you need to introduce I'm, saying it. That's okay, I mean this is one of the solutions. Yes, think.

G

W

This yeah, this is one of the solutions which gives you only work with one label you can. You could achieve what I'm explaining here you could achieve with just one label, but the problem with this one label approaches you really need to dedicate a global label block for your SR paths. I mean you know, there's never a good number. All you know based on deployments today. You might think that you a hundred thousand labels and then tomorrow, that's not sufficient.

W

You know those are the problems that you know that have to be, but this is a valid solution, but for deployment there are certain problems with this global block and partitioning the labels, and so.

K

So I've always been that the rule that kind of Eric and everyone kind of taught me from day one and MPLS is never ever use a special-purpose label. If you can use an ordinary label to do it, I believe that there are they're unlikely to be more than a couple of thousand nodes in your domain, so why not just take a couple of thousand extra labels and use them to indicate source? You can special-purpose processing. If you want it's only a couple of compares to find out whether you're in the block or not sorry,.

K

They need to know they want to identify the source nodes. Also, let's be so.

A

Talk to talk to the mark and you need to be pretty quick about because now we're using still time next presentation, yeah.

X

I'm, marching from college I think actuators are too many options that can be used to identify err. I surpassed here's one label solution, two labels, three or four labels that every searching has its own pros and cons, and we need to discuss whether, which one is better for this yeah.

W

G

It's just while working wrists are talking to pretty much every hardware vendor on them as this stuff. The world is not asteroids, yet you might think there's huge cost associated with increasing label that maybe there are two three and P use. We can go ten plus labor, but for the rest, where you're pretty limited.

W

Yep there's a concern. I do agree.

W

Where do we place it in the label? Stack it's very similar to entropy label problem, so you need to be able to read that get that SR path identifier. So the solution we will we would need- is very similar to the entropy label that was presented in earlier today.

W

So another option, so another problem is the sub. S are passed, the you you could have bindings, it's used in your label stack and then how do we account for this? These? These are sub. S are passed like these would get replaced by multiple labels.

W

So what we're proposing here is to is you really need end-to-end SR, pass identification of those paths and then accounting for those and then so, even even if the interrupts, the SR path, identifier, is appear multiple times in a label stack, they would all have to be same and they cannot be different.

W

So forwarding plane procedures so when a packet arrives, so the the forwarding plane will look up for the special label and then, if it finds a special label, it will check for the seabed and use s our path, identifier plus node, node ID, or it will just use this our path, identifier based on the C bit and then dynamically create counters. If they don't exist for a particular interface and then account the traffic on power interface basis.

W

So this is just describing what are the differences we we had this binding seed, which is used, get us, gets associated with NS our path in the network, and then it is used to steer traffic into the SR path and there were questions around whether binding suit and SR path. Identifiers are the same, so I have tried to list out. What are the differences? Like scope is binding. Cities could be global scope or local scope s our path. Identifier also have similar property, the purpose of bindings.

W

It's it's different, its steering traffic into s, our path, whereas accounting traffic for s our path identifiers. So when you when, when it appears at the top of the stack, the binding seats, are popped off and replaced with labels tax, whereas the is our path. Identifiers are just popped off and binding cells have a 20-bit size and s our path, identifier, as have 19 bit, plus one additional leftmost four Indic for indications.

W

So in spite of these differences, it's possible for an operator that he can allocate an SR path identifier and use it as a binary. I use it also as a binding set for that particular SR path. Identifier,.

G

So one more comment about using binding seats to to create sub bothers. It has implications to control plan because it's app is not full mesh protocol. You usually have peace obsession ingress. Not if you want to instantiate binding seats on PHP, not to the knot, that's lost in your MSD. You would need to dynamically instantiate this obsession to that knot or we need to extend bgp or we need to do something. Today's console play and doesn't solve this issue.

A

G

A

It just imagine it. You asked using your own time for next presentation now, so we're five minutes left om evening. I was.

K

Only going to say, I P fix can do a lot of this already. It can look, any label stack and report the number of counters and count the number of instances of seeing it. So we should really be trying to use technology. We've already got.

W

You mean IP source and destination based.

K

Net flow, okay,.

D

Hi this is a wah. I have two questions. One comment. First. Actually the comment is I agree with the special global label. You stopped the special purpose label, so for notes, it's like the way you do global aid. Since it's our global nodes, it's you can create the global. This kind of calculating sits, like you know, traffic counters it. That is a good suggestion and the comment is go to the slide where the dynamic creation.

A

Sorry, we need to move on okay.

D

So the question is like you know, you said that dynamically the node has to create this counter, so the node may carry thousands of flows, so there'll be hardware issue. Creation of you know, apart from sushmi I.

W

Think you can go through the draft we've tried to address it, I mean what are the concerns and how it can be handled with respect to dynamic creation. Okay,.

A

K

So I raised these subjects in the pals meeting and lower suggested that I give a heads up over here. They arise from a discussion on the panels. Ethernet control word problem, so the first problem that arose was that RFC 67 90, which is the e Li draft, is a bits, is soft on the definition of how it works says. If a Transit LSR recognizes the Eloi, it may choose to balance solely on the following label: the EF entropy level.

K

So the implication is that an NS that recognizes the e L cannot be assumed to base its ecmp decisions solely on the entropy label. Now that impacts two pieces of technology, it impacts the IETF Powell's Ethernet work, we're doing where some operators have reported miss ECM, peeing packets, and it means that you know we can't rely on those things like the fat label and the e Li alternatives.

K

The other one is synonymous labels which we're working on here, which also has a problem and in fact I am in general. Has this problem we're changing the stacked with the OEM in may mean that you miss route the the package?

K

We don't get a fate sharing, because it's not required that the e Li method and get you out of jail, so I proposed to write a small draft and bring it to the next IU TF, which proposes tightening up the rules in all of that, we can rely on the entropy label system to to work and allow us to some alternative stack designs that we need.

K

The second thing is that it appears that well, we know that lots of vendors do ecmp based on packet, inspection of the IP of the MPLS payload, the IP payload, the some implementer implementations appear to detect zero X zero after an MPLS label. So I can assume that that means it must be a pseudo wire control word carrying Ethernet, and then they do packet packet inspection based ecmp.

K

Unfortunately, then it was get it right and operators have been complaining about it, causing problems and expense, trying to figure out. What's going on, the problem surfaced in pseudo wire, but the the wider issue arises from this type of ecmp and any recommendation needs to be documented in this group anyway, as it's a P Rooter problem. So I propose to bring a drafter the next IETF on the the subject. If anyone has any thoughts, I would be more than willing to hear them.

A

Thank you and time yourself. So this is the end of the meeting.

A

It's a reflection here is that it's actually more activity on the mpls mailing list when we have all the people in the same room than it is when the people are working from home, I, don't know or from the office I. Don't know why yeah! Okay! Thank you! Thank you! Everyone and see you in London there spring ah I have a question. We have only one of the blue sheets where the other one blue sheet.