Internet Engineering Task Force IETF 115, 8 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF115-SPRING-20221108-0930

Description

SPRING meeting session at IETF115
2022/11/08 0930

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

A

uh Confirm that you are hearing RS, it would be appreciated. Thank you.

B

I don't know we can hear you.

C

Oh, we can hear you no problem.

A

A

A

D

Can run this night.

A

Because I've already started go.

E

A

A

Okay, good morning, everyone or good afternoon you're in Spring, rocking Rupa uh we're a full station today. So we're going to start now remember that the session is being recorded on including a video. If you are in the room.

A

This is the, is he not well, you need to read it if you haven't read it, especially if you are contributed foreign.

A

For ITF uh 115, so if you are in-person participant, you need to to sign in using mythical multicolite.

A

This is being used as blue sheet, and also this thing is being used to uh to queue on the bike, so you have to enable queue on meticulite before going to the mic so that we can under a single queue for both Olo code and remote attendees, uh but obviously keep your audio and video off. If you are not using the light version, I saw something very important: um everyone need to wear a mask anytime, except if you are actively drinking eating or speaking at the mic.

A

This is uh very important. This is going to be checked, including during the meeting. So please, uh please make sure you have a mask if you're a remote make sure your audio and video are off unless you are actually presenting on the usually your headset is a is a better audio quality.

A

In terms of minutes, we're going to use a collaborative tools which is available at the following URL uh you're. Welcome to help to take notes at least please check and correct your name and comments. You can do so.

A

Ihf is moving to a new Wiki system, so spring working up has moved to the new Wiki it's available at the following URL the week has been slightly reorganized. uh It has also been updated. So thank you for being about that. uh You're. Welcome to to check uh whether the content is uh correct during the migration, especially, you can check whether your request for last call or adoption code is still there and still correct.

A

Okay, so since July uh we have adopted a new policy in the working group, so we now among data an implementation section in the draft, at least before working up last caller.

A

This section is based on the b205, which is about improving awareness of running code with implementation status, section we're a bit more specific items. We request all items either identified in section 2 of the BCP to be a to be filled.

A

You can put not known it's fine, but just to check that uh is not lost, it's not blocking for progressing to ASG, but we do request the best effort, so you can feel non-reporter does not apply, but something needs to be written.

A

We also um ask for a statement that the implementation um is compliant with all mercen should in the specification and if not, which one are not followed.

A

On as per PCP 205, the section will be removed before RC publication, so you can check the full policy on the wiki.

A

But it's just a reminder: it has been discussed on the list.

A

In terms of a document, so my mistake in the slide, the working group- Plus Code- has not been started. Actually we started, but we we stopped it because the implementation section wasn't there, but we are about to start again the working plus code on SR education segments.

A

So please review and comment it's important for specification to be uh to be supported by the group and to be reviewed from a technical standpoint. So it's very important. Otherwise the graph will not progress.

A

In terms of classical, we have an ITF last call just started on a MPS pass segment.

A

With nsh integration with um with segment protein.

A

So that's all for document status. This is the agenda for today we have a full agenda. So please stick to your allocated time, which include time to present on time to to discuss.

A

Is there any any comments or bashing on the internet.

A

Anyone removed no, so if not we're going to to start with the first being a Rakesh for MPS Network action.

C

uh Good morning, everyone, my name, is Rakesh Gandhi from Cisco Systems I'm, presenting the mpls network action, header and coding. Solutions uh draft on behalf of the co-authors listed um many thanks to all the authors for um working together, collaborating and producing this converge. Unified, Solutions I, really appreciate it. Okay next slide, please.

A

C

Next slide there.

C

Yeah many thanks to all the contributors they've been co-authors as well, but with the limit of five authors. um So many many thanks for all your inputs and contributions next slide. Please and next slide, please so uh in agenda. We have this being presented in past tomorrow. There is more time allocated for this presentation in past. There will be good discussion on it as well um and we're just presenting uh in spring because of some Sr mpls um implications on it. The scope is we look at the scope, the solution that's presented in the draft.

C

uh Some we have reserved our codes. uh There is some ordering there's some good discussions happening on the action ordering backwards, compatibility and the next steps next slide. Please.

C

So the scope of this draft is uh for the mpls encoding Solution. That's uh in the label stack. There is a another draft for the Post stack highest draft, so the both of them together form the complete mne solution and the scope is to meet them in the requirements and uh framework. That's already adopted by the mpls. A working group next slide please.

C

So there are two parts to the solution: one is the network action, the sub stack header and the second is the action encoding. The header is basically a bspl label indicate indicating that there is a substance there, which is encoding parameters like the scope, the ordering length and whatnot, and the action is basically a TLP, so opcode length and the ancillary data is the value next slide. Please so.

F

C

Test mentioned: there's a bspl. uh There is a length of the header for the, so a lot of work has been gone in defining this encoding for easier parsing, especially in Asic. So there is a land uh that the scope is there. If you want to do on the end points or hop by hop or on select nodes, um there is some discussion ordering there's a beat. This is, it must be executed or the order is specified or it's an optional next slide.

C

Please, and the second part, is the X and encoding part, which is a tlv, so you have uh op code, the data and the length of it. So it's uh not recognized using the land. It can be skipped. uh There is a known awkward handling. uh So if you don't recognize it, uh there is a way to specify either a Skip and go to the next one based on the land or drop the packet or just forget about M, A and just forward the packet.

C

So uh this is basically, uh if you can see this as a toolkit and how application will use this toolkit, it will be up to the applications. uh So the the programming aspects of it and all the parameters are in the solution.

C

Next slide, please so, uh for there is a substack per scope uh so for the hubby Hopper selector a2n uh scope, uh there's a sub stack. uh This is uh defined to make the parsing and processing easier on the midpoint nodes next slide. Please.

C

So we have reserved some, of course uh uh there are four or five of them. First, one is uh to say where the offset is for the Post Tech data. So this is to allow the uh the gsch kind of uh existing um data or header to be carried another one is an OP code to just if you just want to carry the flag based accents. There is a third one is for the flag, based Excellence with data, and then there is a another one to carry uh the post stack network access as well.

C

So that was that's on the next slide um yeah. So we can skip this as well yeah, and there are two uh special uh of course one is the upper 127. So it's a seven bit of course. In case we run out of it unlikely, but there is a way to extend it, and 126 is if there is no uh aim stack action and there is only a post-tech accents. uh 126 is a reserved for it next slide please.

C

So there is some discussions about ordering how it should be executed. So there's an OB Define. If it's set, then it must be executed in the order. That's encoded: if not, then it's based on how the application Define it there is some discussions about what should be done in stack or post stack, uh so uh there are some flag base so how that should be uh uh executed as well. So there are some examples in the draft on what the authors think can be done. uh Welcome your comments on that next slide, please.

C

So this is about ordering between instac and post stack as well. So.

G

C

C

So there is a lot of uh brainstorming and thinking went in to make sure the solution is backwards compatible, especially if you're only going to do the end-to-end processing uh or end-to-end m a uh we don't want to upgrade the penultimate, node or midpoint nodes. It should be transparent to it make sure the ecmp is not adverse affected, uh make sure that it doesn't Alias when existing reserve bspl it can coexist with gsh. So a lot of the uh thinking has gone in, but there could be something.

C

So if you have feedback on on this aspects, please let us know and next slide. Please.

C

We'll skip the advantages so at this point, I welcome your review comments and feedbacks. As mentioned, this is a converge, uh unified solution. Among all the authors, um uh we receive lots of good review comments uh and we are addressing these comments. uh Some cleanup is required. There's some discussions on the scope at ordering, um so on all the aspects that we presented today. uh Let us know if you have feedback comments and that's all I had.

H

uh Grand whiskey Erickson, so you mentioned that uh the offers paid uh special attention to uh end to end uh operation of MMA, so basically, when uh anime is expected to be operated only at egress, uh but my understanding is that uh there are other uh options. There is a hubby Hub and there is what's called select.

H

um Given uh it's currently indicated in very high level of encoding.

H

uh Do you see that uh different modes can be combined together, for example, so some functions are like iom being requested to do hubby Hub, while, uh for example, uh generic uh Pro indicator is clearly end to end.

C

Yes, definitely so uh there is a sub stack for hubby hop, and that is a substack for end-to-end. Only requirement for backwards compatibility is that the m, a bspl if it's exposed or under received packet at the no receiving it, and that does not understand the bspl. It may drop the packet.

C

um So that's the only constraint for the backwards compatibility, so the Ingress and cap node needs to make sure that along the path is never received. Vspl is not at the top on the received node that you cannot understand.

H

um Well, that was not really my question. uh Let me rephrase so, for example, imagine that, uh because of uh maximum stack that along the path um we can put um Hub by heart and end to end at the bottom of the stack so to do hard by hop and end to end Network actions with the current encapsulation, do you see it's possible to do it on the one special purpose label, or that will require two special purpose labels, so two Network action sub stacks so.

C

The the one special purpose label we can have multiple copies of the sub stack and we can have copies with different scope, so you would have one sub stack with hop by hopscope and another sub stack with I2, Esco and hubby. Hops uh substack will contain the iom, and the second sub stack with the same bspl will have the flow identifier for I2. Okay, thank.

H

A

Okay, thank you any no.

C

That's uh many thanks. Thank.

A

A

And now we'll we'll move to um next presentation for interlayer Network programming um presented being uh U1.

I

Is my voice? Okay,.

A

I can hear you I'm going to share your slime. Yes,.

I

Good morning, everyone uh this chapter is on the topic of slv6 foreign Network programming and the authors are from Huawei and China mobile next slide. Please.

I

uh First I will introduce the background operator, usually have a multi-layered network. The layer 3 is normally IP based technology, where different technology could be used for the underlying layers. For example, there are two another one: the closed layer, Network programming and the optimization is expected. It is considered more efficient compared with the independent planning for each layer, but it's also considered more complicated as the way 6 enabled Network programming by encoding Network instructions in IP Handler, but currently only the network instructions related to ipd are defined.

I

So we come to user srv6 for the network layers under IP, so we think slv6 can be further extended to achieve the same needs: internal Network integration between IP and the under layer layers.

I

So this document describes the use cases for the internal Network programming and we propose a new srv6 function for this purpose. Next slide, please foreign use cases for the inter-layer programming. These three scenarios are very common and widely used in The Operators. Network first case is IP and Optical Network integration in many scenarios in the network. The underlay of IP network is the optical network, but in some cases Optical parts and IP parts may not be one by one mapping, so the reduction to Optical process may not be fully used by IP layer.

I

Secondly, the optical process may exist between adjacent to IP nodes, so it's not too reasonable in the layers rate polity. The second case is the IP and MTN integration. The MTN is Metro transport Network, it's a new technology and has been divided in itog.8310, the m-team parts layer uses TDM switching the intermediate nodes to avoid Hub to hope, I hope, IP packet display team, so mq nodes can support both per hope, ip40 and it also supports MTM, Parts cross connect.

I

The traffic can be carried using IP parts and team parts or the combination of the two, but currently srv6 only can be used for the IP pass programming for the MTN Network. The MTN Parts is not included. The third use case is traffic steering to a layer, 2 random member link. Each member link is a layer, 2 connection without layer 3 and this um and decency. So if we want to choose one specific Layer Two member link, we need a new function next slide. Please.

I

Also, we propose a new slv6 which called end XU in order to solve the inter-layer program in the use cases. This endpoint with underlying cross connect is a variance of the and X Behavior. It may propose it for the interlayer programming and traffic engineering. uh The end actually is associated with an underlay interface, which connects to one or more underlyings or connections, and the light and 15 from the slv6 and progressing in the current RFC 8986 is replaced by the following forward. The package, through the underlying interface associate with seeds next slide. Please.

I

In this slide, we give application example to use the index using IP Optical integration. In this figure we can see there is a IP networks. Only the optical Network, the node P1 to pH is IP nodes and the node 01206 is Optical nodes. If we want to set up a package transmission connection from p7 to the right pH, with normal segment routine solution, we can find the seedless in IP network is p7 P1, P2, P3, p8, but assume there is Optical parts of 102 203.

I

If there is taking the optical Network, we can use the NX usage to P1 to steal traffic to this underlay Parts under the optical parts. So maybe we can provide a lower literacy compared with the normal IP parts.

I

Therefore, the IP Optical interlayer path can be created, Created with a seedless. The new set listed p7, P1 and XU from O2 to O3 then go to the P3 pH next slide. Please.

I

We give another example in this slide: it's a application of NX during ipmq integration. uh We can see in the figure in the figure the operator earns both the MTN Network in the metro area and also IP network in the backbone area, but for the empty nodes. It builds two separate Network layers, the layer, 3 function in the topology and the MTN Parts topology.

I

Connect so we can use and X usage to be allocated for each MTM parts, so we can correct a zip list with nxu to end to end parts with layer, 3 and I'm two segments in this solution. We can flexible, select empty parts and layer 3 in all the networks.

I

Next slide, please also inclusion. We think the income layer, Network programming, is a significant requirements and stress to study and divide the endpoint function for this application, and any comments and famous feedbacks are welcome. Thank you very much. That's all.

E

Okay, Sasha you're up first.

J

Hi uh I'm social Einstein from ribbon. Can you please uh show again the the slide with the no one uh one little bit? Yes, this one uh I have a question uh as explained the optical path between P1 and P3 is not an IP uh an iPad.

J

My question is: when P3 receives an IP packet from p7 I think uh how does it know uh which layer two encapsulation should be pushed on this packet before it is sent by the optical path, because without this uh encapsulation P3, most probably wouldn't recognize the packet as an IP packet and wouldn't be able to forward it via the IP pass to p8.

J

uh We normally we ate if the parts were an IP interface. P1 would try to resolve uh battery IP address or something like that using our Pro uh Naval Discovery. But since the Optical path is not an hyper pass, such resolution seems impossible.

E

Hurryan, do you have any comment on that.

E

How well uh ran ran Chen you're next.

K

Yeah, okay, uh hi. uh We agree with the useless it's a lion, Network programming at the requirements, and thank you very much for your visitors to work, and we also have similar proposals uh by the way things but new. As always. Six and the bxc we have here for interlier, Network programming, the srv6 and the pxc function mechanism has been implemented by the key and the China mobile has successfully completed the basic verification of this function. Hope it can catch you and the working group attention. Thank you.

K

E

Katan go ahead.

B

Go uh kind of follow on to snasha's comment uh that uh the whether the optical path is IP or not, is I think not clear, uh but uh n dot X said, uh which is in RFC 8986 Network programming does can be used for layer to bundle member states and therefore I mean I. Don't see any reason why we need a new uh Behavior, it can be used for this Optical link as well for steering into Optical path, n dot, X existing one.

E

Okay, thank you, ketan Chetan, your turn.

L

From Huawei and firstly, I'd like to respond to Sasha's comments on the uh whether a P3 can correctly receive the packet and forward it I think it is a good question rather how to resolve the like the IRP, all the layer tool information, uh since this draft currently does not cover that details, but perhaps we can consider to uh distribute some kind of information through some control plane. That is a reply and the truth comes from Curtin.

L

uh Our understanding is uh the current and Dot X behavior is very, is correct, explicitly defined for the layer, 3 adjacency, and that kind of information are used for the to build the leadership topology and the forwarding pass in the leadership network. uh We Define this node.xu to separate it from the leadership. Apologies so that we for some Network behaviors. We don't want to mix the literacy adjacency with the entirely links so that we can have different fast computation with four different kind of service. So this is the purpose to distinguish these two food behaviors.

L

E

Okay, we'll move on to that.

E

Somebody was trying to say something: I couldn't tell who okay we'll move on to the next presentation. Thank you.

M

Hello, can you hear me.

A

M

Yes, thank you uh I'm, using Leo from China mobile and today I will present the encapsulation of BFD for The Advocate policy. This is the first presentation of this draft.

M

Next slide, please.

M

Okay, we, when we use the BFD session to monitor the srs6 policy and, as we know, uh sos6 policy has three levels and the brt session runs associated with the second list level and when we have decision done, the set the associated a second list fail and the traffic will stop forwarding and with this uh specific segment list. While all of the signals, the failed of the active candidate parts and the traffic will switch over to the backup candidate pass and all of the candid paths fail and the policy field.

M

uh Why? We? uh The second, is that uh uh what the choice of the address for the BFD- and here we uh give the two types of the BFD as DMV and the upfd ubfd means that we use the bfpi code function and you turn on the reflector.

M

And when we use the spfd the head and address, we can use the iv6 address of the head end and the and the two and the address we use the endpoint of the SV rv6 policy or specified by the local configuration and for the ubft, the head and adjust. We use the x36 address of the head and we'll use the root ball or non-root ball. uh For the tail end, we must use the root Pro ip6 address of the head end next slide. Please.

M

And uh we have the uh two modes of the encapsulation of the BFD packet and the uh the the difference between the the SRH how to uh in Captivate the SRH and uh for the track mode transport mode. The SRH is inserted after the ip6 header and the tunnel mode. We have the outer ip6 header with the SRH and the inner it's uh for the BFD packet, like the plan IPv6 pack package still into the srv6 policy.

M

Let's start sleep, please.

M

And next slides, we uh I will uh give the details of this uh two modes for both the fbd and ubfd and when the spit in chess mode transport mode, we are encapsulated. Only one IPv6 header and the SRH and for the sl0 position should be the athletic feed or the ip6 address of the tail end node, but uh sometimes the last segment of the second list in the sr6 policy does not belong to the tail end. It can be a n dot, X segment of the parliament Hub or a bunny seed.

M

So in such cases we will add a ip6 address or s36 seed of the tail and node, and the last segment will put in the SL1 position in the SRH and that's the slide. Please.

M

When the sap internal mode, we are encapsulated the inner IPv6 header, with the ability packet and the author, with the IPv6 header, with the SRH and at the same so zero position should be the s36 seed or the ip6 address of the tail and node. And if the last segment of the second listing sr6 policy does not belong the tail end and maybe a n dot X. But did this I know that without the USD flavor, if if he he has, if it has a USD flavor, it can decapitulate one in at the punishment hub.

M

So if we that have the USD flavor or it's in it is a burning feeder, we should add ipv 6 address or a seed of the tail end load in the sl0 position and put the last segment of the segmentalist in sr6 policy in the SL1 position. So that's the slide. Please.

M

The next is two slides about the ubfd when the ubfd in transport mode that it is. uh That is a simple thing and only one optimistic header is used to encapsulate the echo packet and for the SL zero partition. We use the SRA 6 seed or the ip6 suggests of the head end and the one the echo package arrived, the tail end it it will use the destination address at the SL 0 petition.

M

That is the head and node address.

M

uh One, the usbsp in the tunnel mode, we encapsulate the inner Acoustics header and the outer s36 encapsulation and the destination of the inner fps6 is the address of the head and the node and the the Outer Outer ip6 header. We use the SL zero partition should be. The isab is six seed or the IPv6 address of the tail end, and that is the same scenario that if the last segment of the srv6 policy.

M

Without the USD flavor or upon your seat it we, we will add the fb6 address or seed of the tail and in the SL steel, zero partition. So next slide, please! So that's all. Thank you. uh Welcome for the questions and comments.

M

Okay, Greg.

H

um Greg nurse Erickson um a couple questions, but um probably there uh first question is: uh what's special on encapsulation, so special for DFD, because I.

E

H

That you explain uh different modes of a certain encapsulation in the SAR modes, but I don't see that it's different from encapsulating payload uh and services that to be monitored using uh BFD and I. I cannot find anything that is specific to BFD being used over this a service, 6 modes.

M

We just work on the how to encapsulate uh the BFD packet in the atheristics policy and it may be uh have a major difference from uh for the normal date package.

H

But if you, uh okay, if you suggest that DFD should be encapsulated differently from the payload, then how you guarantee that PFD will follow the same path and will be treated the same as a uh service that you're trying to monitor.

H

uh I see that there is some contradiction, so you believe uh that BFD has to be encapsulated differently into a service six policy uh compared to their payload.

H

But then the question is: if that's the case, then what are you monitoring? Because if you encapsulate differently on a service six level, then uh the packets would not follow the same path.

E

Okay, I think this probably needs to go to the list right. A little short time, I mean I. Think Greg you've got a good question, but we need to take it to the list. Trotta you're next.

E

N

Yeah so another question that you want to know: if it's not clear why you're defining two different modes like transport, modern tunnel mode, it seems like all the scenarios can be satisfied with just one word, for example transport more and it can detect the liveness of the segment list.

N

uh So can you explain why you define two different modes.

M

uh So I cut here very clearly.

N

Okay, I will post my question on the chat. Thank you.

M

O

E

You hear me go ahead.

O

Yes, can you hear me.

A

O

I, yes, my question is um the the: uh why can't uh the sspfd packets can take the uh use the standard, srv6 programming, or is there anything special, that's being done in this graph other than using the standard, srv6 programming.

M

uh We we just use the the standard sl6 programming, we do the uh change anything of debt.

O

Okay, so what what is uh what would be the benefit? I guess of this graph? What is this graph adding outside of srv6 programming?

O

um That's uh that would need to be standardized, I, guess good, special outside of normal behavior of a packet I. Guess it's being um either to be monitored from the ahead, and you know to the tail end.

A

E

P

E

P

Jeff, Hardy speaking, is with the bft chair. uh Your presentation was clear. Thank you. This comment is primarily addressed to the spring chairs. We're currently tracking five distinct documents for BFD out of spring one is adopted. Four have not been.

P

The documents are substantially the same in many respects. This is part of what's been commented on in the last several speakers.

P

My suggestion would be to the working group that, rather than having five distinct documents, since you know, majority of this stuff is overlapping Technologies, with specific examples for specific technology. That's our v6s or V6 tunneling.

P

Please consider taking one of the documents and simply having an individual encapsulation example for each of them, since the procedures are largely the same, this will probably save yourselves a lot of grief and when things come around to being reviewed by BFD, you know for your last call. Process we'll simplify things.

E

I can certainly understand why you'd prefer not to have to review five and we'd certainly prefer to see the various authors pull together so that there's one set of review in Spring as well. Thank you, Jeff.

A

So next is a segment routine based solution for hierarchical igf, Network slices lion.

Q

Hello, everyone- this is Liang from.

R

Channel mobile.

Q

I'm going to talk about the topic of segment routine, that's the solution for hierarchical ITF, Network license uh on behalf of all the co-authors.

Q

This draft has been completed in this disability on 114 meeting and is the suggested to presenter to Spring, also because the solution is based on the segment routine.

Q

So we also look forward to 12 months and want to get your opinions on whether it can be moved forward so next place.

Q

For the concept of the hierarchical item, networks like this is based on the itfl terminologies Network, slicing, iqf, Network, slides and the network resource partition.

Q

The hierarchical HF Network slices described the networks like this, which can be further sliced or convent hierarchically. uh For example, one of the possible scenarios is that an industry slides needs to be divided into multi-customers like this. So generally, the idea of the draft is to propose a true level.

Q

Hierarchical item networks like this solution based on the statement routine level, one network slides is associated with the flexed alcohol with the dedicated sub interfaces and the level 2 Network slides is realized by using the as a policy with additional nappy ID on data plane uh next place.

Q

And this slide shows the topology and the traffic folding of the true level hierarchical slices.

Q

It's a level one is associated with a flex alcohol and the traffic is still into the flex elbow passes, using the prefixed seeds or as a value located a statistics locators and the level 2 Network slides is associated with one of a group of as a policies under the level 1 NRP and the traffic is geared into the SR policies.

Q

Q

uh The network resources is also partitioned in a hierarchical manner, kicking bandwidth resources as an example. The level one and wise is guaranteed by a little series. Sub interface with dedicated bandwidth and the prefix state or srv6 locators is used as a datably identifier.

Q

um The level 2 bandwidth is guaranteed by kills with dedicated bandwidths under the little three step interface and the NRP ID is used as the data plan. Identifier.

Q

Q

About the relationship between the NRP and the slides, actually, each NRP either level one or level 2 boost can be used to support one or a group of network slides. So it is compliant with the ITF definition.

Q

But here for the example when we actually deployment theater, it's much more complicated for low to NRP to be mapped to multi slices, so in actors in ISO- and we think it makes little sense- is the resource is already finally divided as previously described so here. For the example, the level 2 NRP to slice is shown as one-to-one.

Q

If the multi multiple to multiple scenario that to exist, we think that the solution, also it can meet the requirements.

Q

Q

This is one example for the whole solution from the bottom. Up to the physical network is divided into two inner pieces through the flex elbow and the hnrp is mapped to two one slice one is for education and the other is for the healthcare and the corresponding black alcohol. Id is 128 and 129 uh fold the education slides. There are two customers University one University two: they have different exercise points and interactions.

Q

For Health Care slices literally, there is only one customers, so for the second level slice, there is only one slice yourself.

Q

So next, please.

Q

um Based on the topology previous, the resource partition is like this slide shows for pe1 the physical interface one. There will be two sub interfaces and the under which there will be two or one kill respectively.

Q

This is for the second, the level slice for physical interface. Two, there will be only one sub interface and one queue under the sub interfaces.

Q

From this picture, all the sub interfaces and the kills are associated with the dedicated bandwidth which can guarantee the slice resource.

Q

uh Okay, masterpiece.

Q

And this is the last picture which illustrates the traffic forwarding.

Q

uh The final result is that for the normal education traffic- it's it is encapsulated with the understated and also associated with the specific flux, alcohol and it's to forward data through the layer series of interfaces and photos, specific traffic from University one and the university to accept the activistics either SRH.

Q

The encapsulation also includes the additional NRP ID and with the traffic is folded through the queue under the sub interfaces.

Q

And okay, that's all next is.

E

Q

Just a moment before we.

S

E

On I, just I was looking at the room and I saw a couple of people who don't have masks on masks on over your nose and mouth please unless you're eating. Thank you.

E

You may continue.

Q

Okay, okay, since it has been presented in this- and there is no objection we still just so- we also look forward to your commands from Spring and also want to know if we can move forward for this draft.

Q

E

Okay, Ted Hardy.

T

Cisco. Thank you very much for this very interesting draft. I I have three fairly quick questions. uh The.

R

T

In terms of just to confirm my understanding, this is an informational draft that requires no protocol changes as far as I could see so I'm I'm, not sure what work you're asking spring to to take up a clarification of that would be useful.

T

uh Second, looking through the draft, it looked like the hierarchical nature of it would normally allow you to have one level of the hierarchy managed by Sr and another level of the hierarchy, managed by something else.

T

In your University example, you might have the overall set of universities, um those resources in a slice that was being managed by Sr and some, but not all, of the slices for specific universities being in either Sr or mpls, or something else and I wanted to confirm whether you thought that that was possible in in the approach you're taking or whether the linkage to the underlying nrps made that impractical and the last question was. uh This is obviously very early work.

T

A zero zero I didn't see any uh IPR disclosures for it, but I wondered if the authors knew of any that were in preparation. uh Thank you again for the interesting draft.

Q

Hi, okay, thank you for your comments. I will try to answer your question. If I cannot answer, it clearly um welcome to move it to the main list. uh First of all about the solution. I think it's an informational solution. Yes, you are right and there is no other extensions on practicals.

T

Session again, I think your mic is on and we're getting some weird Effects. By that the end, could you go on.

R

Okay, uh it's okay! Now.

E

Yeah, the problem is fixed. Thank you.

R

Okay: okay, okay,.

Q

uh Sorry uh so I'll continue all um because there is no other extension on this uh solution, so we just propose this to uh check whether the solution, if there is any conflictions with the spring spring opinions, uh so we think it's informational document.

Q

The second one about the true level, hierarchical, slides, I, think the first level we use the flex algo is for the control plan and because of the limitation of the control plan, um it's very difficult to realize the multiple.

Q

um Slice, so we proposed that the second level slice, which is from the forwarding data plate data plan, so the second level I think they are also based on the srv6 segment routine, because we combined it with the SR policy of the services package. Folding an rpid such as so I think the total solution is related with the s36.

Q

Oh, the second one I'm. So sorry, I can't repeat it.

T

Q

T

Was just a quick question of whether you knew of any IPR uh disclosures in process.

R

Q

No, no I am not aware of any NPR disclosure.

T

Again, for both your answers on the interesting draft.

R

O

Yes, can you hear me? Yes, we.

E

O

um Yeah I just had a question.

O

Is there um in your examples, you had two layers of hierarchy: is it possible to have more than two layers hierarchy um as well? um I guess, with with the uh the semantics of the draft, is there? Is there anything special, that's being done other than what's uh defined, and um you know that's part of segment where I think the standard um is there? Are there any um a special um Diana requirements related?

O

Q

Thank you. Thank you very much. It's a good question. We also have thought about it later from now on um the full Channel mobile, it's a real natural it. It's just the true level slice, for example, I think a different business units with the operator government, Affairs departments or Enterprises of Affairs Department.

Q

Under this there will be different users and another example for the operator we think for China mobile. There are several sub operators, several sub operators located at different provinces. They also want to manage their own provinces with business independently. So I think this financial is very special for China mobile operator.

Q

We also need the true level hierarchical slices.

E

Thank you. Thank you. Okay. We need to keep moving we're starting to fall behind schedule. Folks,.

A

So next is a SRA sm2 for Sr policy. Again speaking, if you could try to pick closer to the mic, I am we're not hearing you very well every every time. Thank.

O

You, okay, um give me one second I'm just going to try to make an adjustment to my Nick, and just if you could, let me know if it sounds any better.

O

Does that sound better.

A

No, but that's okay! Thank you.

O

It doesn't, it doesn't sound any better. Okay, all right. Let me just I'll just try to speak a little bit closer to the mic.

A

O

Hi, my name is Leon Mishra I'm, with Verizon and I'm, presenting the draft of SRP MTU for Sr policy on behalf of co-authors next slide.

O

So a recap: some ministry as to how this draft came to spring. So during the adoption of draft uh PCP set, pmtu a need for a document and spring was requested and confirmed that both the pce and spring working groups, so an IDR document, was adopted in April 2020.

O

A discussion was brought up by Caitlin that the concept of path MTU assess our policy and its applicability applicability should be first defined in the spring working year before we introduce signaling aspects in bgp as a result of the PC PMG extension adoption called the draft piece of pmtu was maintained only protocol specific extensions of details, while the SR policy path, M2 definition framework, was to be developed in the spring working group as a standards track document to ensure vendor interoperability related to srpmtu, Concepts and computation. Details.

O

This topic came up is a critical issue to be addressed during the IDR working group, 2020 to GPS our policy to MTU adoption call and now again during PC workload. 2022 pm2 adoption call, as mentioned above and due to the criticality of solving this issue, related to handling fragmentation and fragmentation avoidance procedures using SRP MTU next slide updates from revision zero to revision, one so mostly cleanup. There was an update as well on the Securities consideration section.

O

So the addition of the SRP MCU constraint information can be sensitive in some defined and can be used to influence the SR path, setup and selection results in it and which results in an adverse effect. The protocol extension that includes the SRP MTU must be take must take this into consideration. This document does not define any new protocol. Extension and test does not introduce any further security considerations and then as well. Another update was the section section. Three, the SRP empty enforcement reference to separate extension to handle pm2 draft result was also obtained next slide.

O

So next steps we would like to get some feedback on some critical aspects of this graph from the working group experts.

O

um One one of the questions that we have as far from from us authors is sfpm2, TI, LFA, computation and fragmentation caveats.

O

So if anyone can think of after reading, through the draft of any caveats related to tilfa um a computation at the plr node to the uh to the merge point in any any um any uh any of that bypass Loop and any fragmentation crappy outside related there, um another question that we have and we want to get feedback from them from the working group as well as srpmq srv60 encapsulation, and any fragmentation caveats there.

O

When that happened, and then the last question is The: srpmt Binding, Sid path, computation caveat so on the source node, where the uh as our policy candidate, Panthers, bouncing forwarding plate, then The Binding sit is popped and then the labels are pushed onto the label stack or in the srv6 case, the SRH header and the srv6 package is pushed onto the label stack.

O

um Are there any computation caveats that were missing? We just want to make sure that we we recover all our bases in the draft and any any questions or comments. We really appreciate any feedback on the graph next slide, and so this traffic is fairly straightforward.

O

um What would like to take any comments to the mailing list, uh but we would like to ask for work group adoption on this job. Thank you.

A

Any any comment on questions.

R

E

Don't know what's happening.

A

Yes, thank you very much again.

O

Okay, thank you.

A

So we are now moving to 7600ps interworking uh from Square.

U

Hello, everyone I, am swadesh Agarwal from Cisco Systems. uh This document describes the srv6 and mpls interworking procedures and I present this on the behalf of all my co-authors. Next slide, please yeah. This is slides, shows the simple view of the interworking scenarios in the green. We are showing the srv6 domain in the orange we are showing mpls domain and the tasked overall is for the interworking functions has to be executed.

U

The document divides the problem into two set of things: one is a transport interworking and the service interworking in the transport interworking. What happens is and from the end, to end from the service point of view it's running either srv6 vpns or the mpls vpns and since end-to-end is an srv6 VPN. We need to provide a transport reachability to locators and that's what we call srv6 over mpls. We we do interworking functions for the locators, on these Dash oval boxes and for the when we have a mpls vpn's edge service is running end to end.

U

We need to provide a interworking procedures on those test boxes, ovals on whenever the data plate changes and that happens for mpls or an srv6 domain and the and the last case we cover is service intervoking. In this case, we have to provide connectivity between srv6, VPN and mpls VPN, and you need to do a intervoking function on some data working box. Next slide, please so for interworking functions. The document describes new behaviors one is the n dot DTM? What this Behavior does?

U

Is it's decapsulates an slv6 pack-in and look up the UN, it's carrying an underlying label below it and it lookups the label in the mpls table, and we will see how this is used in as you go in the procedures and you can see the sudo code in the draft next slide. Please and the DPM behavior.

U

Is it's a decapsulation and push the label associated with the Sid and again it is used here we can see how it will be used in our slides as we go through this, and the pseudo code could be referred again can be checked in the draft next slide, please.

U

So these are the and hidden behaviors we have defined. So what happens is when the H dot encaps is applied to an mpls label, stack, that's what we call H Dot and caps dot m, and there is both the regular Behavior and the reduced behavior for it next slide. Please so Sr policy is bound to an binding set. So in the procedures, if the SRM pillars, label can be bound to an srv6 policy as well as sr66 can be bound to an Sr mpls policy.

U

So we call these in the draft as interconnecting binding set and we'll we'll see. This concept is used to provide those interworking functions in the next slide. Next next slide, please, as already mentioned when the services are of the same type end to end, and we need to provide a reachability either to her if it's srv6 VP into a locator or if it is a mpls VPN services to a p loopback. So what it is draft does is. It extends the two well-known transport procedures to provide this interworking to create this interworking control plane.

U

One is a srpc base which can provide both the best effort, as well as the intend away. Another one is the bgp interdomain routing, which is right now described for best effort, but we will Define it for the intent aware, based on bgp, also in the future versions. Next slide, please so just to go over the procedures the Legends used are the green boxes are sizes capable, and it shows how the locators have been referred in.

U

That and the orange boxes are mpls capable boxes, and then the orange and green bar the are capable of both mpls and srv6. Next slide, please.

U

So we see these are srpc based procedures. So, let's say between 1 and 10, we are running the srv6 VPN Services, it's been advertised by the 10 learned by the one, a VPN service and what the endpoint or locator we want to reach is of a node 10 B10 is a locator. We want to reach it's a multi-domain network. One doesn't know how to reach one request: an srpc for the a certain objective or a constraint for a path to 10. Srpcs. Look at the constraint.

U

It figures out the let's say: node 2, Note, 5 and node 8 are in the path to provide that objective or a constraint, but since srpc is having the bgp ls feed from each other domain, srpc sees there's an inconsistent data plane happening on node, four and seven. So what it does is whatever interconnecting sets. We use the the procedures we Define of interconnecting sets. It use that behavior.

U

What it does is on the Note 4, since we have to take the policy 200 fabulous domain, it creates an mpls policy, but the The Binding said it's bound to is an srb6 Beast, SRB behavior of the BM type and that's and that uh srb6 BC is being once srpc creates that policy on the four and it and that's the one which is programmed at the one with one of the segments which takes to the node 4 and which will get uh expanded on node 4 to the policy MPS policy and that's where the packet would Transit transition through the mpls domain.

U

So if you see on the Note 4 what packet received is is received with the destination with the BM Behavior, we will apply the BM behavior on it and then the packet would be put into an amplus labels stack which will take us to the again.

U

The objective was to reach node 4 node 5 from 4, and that's what the prefix it we have put in the packet and then the last segment we have put is a note 7 where on the Note 7, and it would be a regular sr6 domain and it will go to the next segment, which is node, 8 and, of course, the VPN segment which will take to the note 10.. So that's the way interconnecting by index. It is used to provide that 6 over M reachability through srpc next slide, please.

U

So it is similar Behavior. It's a similar operations that I have already explained for 6 over M. The only difference is here: the edge services are mpls VPN services, so we need to create this. Srpc request is for the P loop back. It's it's called for a certain C, comma e, which is an mpls in the mpls case here on the Note 4.

U

What we are doing is we are putting an srb6 policy, because middle domain is an srb6 domain that policy, but it is bound to an mpls B said and that mpls BC that is programmed for the policy on node 4 is programmed as one of the segments on the Node one. So now what happens is when the packet leaves one it is going through the segments in the left domain on the Note 4.

U

It is expanded to a srv6 policy with the the next header being 137, because getting an MPS payload below it, and then the packet will be reaching the Note 7 and the regular mpls operations will happen from there onwards. Next slide, please so these are. We have covered the srbc PC based procedures, where PC was aware of this interworking procedures and was creating those using the enter connecting sets to create those uh pass through to the different type of data plane, but similarly bgp interdomain procedures can be used. So in this again it's over.

U

It's a scenario of 6 over M, where the services are Sr, V6, VPN services. So now what we need to do is when 10 advertise the service to node one then we'll also advertise the locator through a locator to node 7 from Note 7 to Note 4 to node one when it's advertised between 7 to 4. What you need to do is it's a it's, a regular IPv6 prefix over an elude mpls transport.

U

So we can use the 6p procedures between four and between seven and four and that's that's the way traffic will flow from one to ten next slide, please.

U

So this is the case of uh mplus being in the edge, and that means it's an mpls VPN services. So we need to provide a reachability to node 10 that has to be learned by the node one, which is learning the services uh from the 10. to provide that reachability. Today we know bgp3107 procedures. Seamless mpls is used. Where what will happen is on on the 7.

U

We will allocate a regular vtp Lu label, but, along with that, we will advertise an srv6 set of the behavior DTM, which was defined earlier right and that would be learned by the Note 4 and Note 4 will advertise this bgplu further to node one so for node one, it's a regular mpls VPN put into bgplu LSP, but on the Note 4 yeah, we will do swap operation for bgplu LSP, but, along with that, we will tunnel the traffic to node 7 with the DTM Behavior, but it will cause.

U

Is we are carrying a bgplu label below uh below that srv68? So, on the the Note 7, we will decapsulate the packet to the lookup of the bgplu label and send to node 10.. So that's the way we'll provide end-to-end reachability over the SR V6 domain. Next slide, please.

U

So these are the cases of Transport interworking where we were trying to provide a reachability towards the service endpoint. But in this case, what we want to in this. This is a service interworking, where we want to provide a connectivity between mpls, VPN and srv6 VPN running on the Node 1 and node 7.. So what happens in this case? Is there? Are these? Are these are working on the existing Gateway procedures? What happens is on node 4?

U

We have a service awareness because we want to terminate both the services as the as well as the underlay. So since we want to terminate both the what we can do is we can have a service Awareness on node four. So whatever is destinations, VPN destinations are learned from the sr6 domain. They are put into the work on the service on the service box, Note 4 and then reordered it towards the mpls side.

U

So there is MPS, VPN and s56 VPN and on the service box there is a verb IP forwarding, which is uh when you receive a traffic from one side, you Decap you look at, you, do an iplooker, and then you get the encapsulation for the other side and that's the way as we provide the interworking solution for this scenario. Next slide please.

U

So this is the last case where, instead of having a service Awareness on the Note 4, what we can do is on the interworking box. We can do a translation. That means a VPN label could be translated to an uh vpn's srv6 service set or the SR physics service set can be translated to a VPN label, using a procedure similar to interest option b, uh doing the next 12 cell phone dot box next slide.

U

Please yeah somebody is the staff was presented uh first published in 2018, and it has the data plane and the associated control plane procedures. It defines a new Behavior, DTM and DPM as well as use the introduce the concept of interconnecting binding, sits and it uses how to pass through a data plane which is not consistent.

U

It relies both on the srpc and bgp based Solutions next slide. Please next slide, please yeah. So one thing we have done is from the last ITF. We have moved the bgp protocol extensions that we have to a separate draft, so it can be reviewed in the best working group, and this is done for both it for the independent review, as well as future application applicability for the other use cases as well as we have expanded on the uh interest option b, like procedures for the service interworking next slide. Please yeah.

U

uh We would like uh the working group to review as well as adopt this draft. Also one thing more: uh there's another transport interworking draft pin there in the spring. We are working with the co-authors of those of that draft, because there's a similar one, similar Behavior being defined to see how to move forward on that.

U

E

Okay, truth: oh Jeff, you.

S

Got to put yourself on the list: uh hi a Swedish, very good presentation. Thank you. One, quick question about the PC part. uh Currently, in the document you are focusing only on a single PC case in peace up working group. We have one more document called stateful interdomain, where how the PCS can cooperate with each other to set up this kind of path. So just have a look at it. I hope that the solution can work for inter-domain cases like where multi multiple PC managing multiple domain cases as well sure.

U

I I've been looking at that and probably we can get back on. Thank you what we can do.

V

Just Japanese or Microsoft, so the drop notably means a separational part. How do you deploy the stuff? How do you operate it end to end and I mean amount of Buffs when you're going to deploy this? It's just scary right. So it would be really good to see sections that identifies how do I trace when it Traverse different calculation, different domains when I replace seats by labels and so forth. Right, it's completely missing in the draft. So if you're saying the operational.

U

Aspects absolutely uh sure we can. We can look into it. Thank you update thanks.

E

uh You should put yourself on using the tool, but just state your name at the microphone. Please.

F

um To the point which Jeff was making I think there should be a separate operational draft yeah.

U

We can look into it. That's one thing: let's looking at that part covered okay, sure.

D

Hey um so you said that there is another drafting base for the uh pure bgp procedures for the for.

U

The signaling aspect to because we are extending to carry these new behaviors in the bgp in the bgp transport layer, like pgplu or in bgp IPv6. So we have put a earlier that was in this draft, but uh to have a future applicability as well as to a category Group by the best we have put in the those signaling aspects we have put in sector draft and the architecture and the procedures are still keptical in this draft. But.

D

Also for the option b uh section, because at the moment it's only covering the uh ldu part right, no.

U

No option b is for the services right. We can do next, stop self. On the interworking box, where our srv6 service, it can be mapped to a VPN label and the outgoing LSP and same on the reverse direction right. So it's using a DPM Behavior to achieve it right. So it's a next stop sell for the services not for the transport.

D

So you're saying there is: there's no need for extended procedures in the best draft for the option b.

U

We can look into it, but it's just because option b is already defined in certain aspects. This is more of using those procedures to create this, but the behavior is a new Behavior DPM. That's the reason we have put it out so that everybody knows we have to use a DPM Behavior. We have to push our labels that stack of labels when I receive a subjected. That's the reason we have put it out. Otherwise, from control plane, I still feel existing procedures should work. It's just some data plane and update to that. We.

D

Can discuss? Thank you thanks.

J

A

A

Next is a Sr policy group from lion.

R

Well: okay, okay, thank you hi, and this is Leah again.

Q

I'm talking about the other topic as our policy group next up, please foreign.

Q

Flows of the simulator have different requirements on the folding quality of the network, so different traffic is expected to be forwarded through different passes and use different network resources.

Q

Taking the left picture as an example, there are two completely isolated, VPN tenants within one and vaping 2. They are both multipoint to multi-pond excise and the whipping one has three different types of sources within two has two different types of sources: each sources has different quality requirements.

Q

First, from the picture you can see that all the traffic belongs to the same. Vpn is expected to be managed in a unified manner.

Q

So here we still the the traffic into one is a policy group, so the traffic belongs to the SR policy group who have different sources and the different destination addresses and the next different type of sources. The traffic under the VPN can be steered into different policies, which is based on the parent policy. The traffic has a specific source and destination address.

Q

Next, please foreign.

Q

This is the terminology which is defined here. First, the SR policy and the parent is a policy are defined in RFC 9256 already, and the New Concept of the as a policy group is newly proposed here and, generally speaking, it is an instantiation of a cyto apparent as a policies.

Q

This as a policies, have different destination and points and the same service for the module, and it represents a set of passes with different folding requirements and computed by different parents as a policies which have the same color but different destination and points.

Q

Also, the mapping relationship between the flow characteristics and the color value of the as a policy path should be established in the policy group, and it can get the flows with different SLA requirements to the as a policy with different colors.

Q

Q

This is the identification of the ISR policy group who an Israel policy group must be identified through a colored tribute.

Q

This color is an unsigned non-dural, 32-bit integer value, and it corresponds to the color of the building of the bgp root published by the endpoint, uh and this is third one. Second different stories, qualities use different color values.

Q

The next sentence is also uh talking about the mapping relationship between the flow characteristics and the color value the same with the previous three slides.

Q

So next, please.

Q

The relationship of the policy group, parent policy and the as our policy is shown as the pictures first in simple terms and as a policy group, contains one or more parents, as our policies which have different destinations on the point, and the color of the policy group should be seen with the parent as a policy but different with the SR policy.

Q

Thank you. Next, please.

Q

This slides detailed the process of the traffic steering using the SR policy group for for the egg rice nodes which published The btp Root. It will associate the b2p route with the color, extended Community attribute and the photo increase node.

Q

First, it will match an Sr policy group using the color, extended Community attribute in the BP route and the next it will match apparent as a policy under the previous policy group using the next hope in BCP root, and then it will match as a policy using the flow characteristics through the three steps. Finally, the flow is still into one specific as a policy.

Q

Q

This is an informational module of the Apple Logic.

Q

From this picture, you can see that there is one ISR policy group for pt1, which is with the color one, and it contains the two parents as a policy uh pp1 and pp2, and they have the same color one with the policy group pt1, but different endpoint, U1 and E2, and each parent as a policy, contains three threes corresponding to three different policies, which is with the color 100 to 2300.

Q

This picture shows the basic logical of the relationship.

Q

uh Okay uh next place, uh that's all, and this is the the real version of the draft, so welcome any question or comments. Thank you very much.

B

If you could go back to the slide, uh uh Bruno uh yeah, so one question uh Sr policy Group, which is a new uh new thing that has been introduced here. Does this belong on the head end, or is this something that's on the controller.

R

Q

Assuming that the SR policy group, who that's how any height on the point.

B

So it's at the head end. Okay, so I am not able to see uh what is the benefit that this group uh brings? uh It would be good if the draft could be updated to clarify what cannot be done or achieved with what we have today uh before.

R

B

So therefore, we know why we need this new construct.

W

B

W

Also, the cause of this draft I would like you to answer the question so, firstly, I think the here the uh policy group will not introduce any new uh Hider or new change to the data plan and the the second one we use that, based on maybe a controller or some other network management system, so that that is logically uh module to organize the hierarchical services.

W

So we just talked talked about the hierarchical network slides. So when we use the uh a services policy to implement the hierarchical uh slicing, uh Zuca solution can be uh used at that application scenario. Foreign.

B

Er, so maybe uh some clarity, more uh more clarity in the draft.

W

um Yeah I think the important value is that it's a high up to organize just different uh uh policies uh for such as the same user or the same kind of service.

W

So if you can use those uh concept, then you can very easy to set up the hierarchical uh Services based on a services policy.

B

A very very last bit uh for taking the time, but we have all kinds of template and hierarchies in you know of all the vendors uh config models right. uh The question is here: why standardize it? uh You know you can do whatever you want in your controller or ahead and implementation.

B

uh If we are standardizing, it should bring some functional value, and that's not clear to me. uh Thank you. I'll end here now.

E

Okay, Boris.

X

Describe a very short question because I missed, we have two colors here: one color Fair Sr policy group and second color for Sr policy inside this group. So how these two colors resolution will be done. It's not quite clear.

W

uh I think I added the same Library. We just use a one color so such as at the isopers group. We just use uh the same uh color uh for uh one parent uh policy, but within the ASAP parent. As a policy, the different Services may have a different color so that it's similar to the hierarchical cues.

X

D

E

Okay, we'll move on to the next presentation.

Y

Y

Can you hear me.

E

Yes, we can hear you go ahead.

Z

Oh okay, thanks good morning, everyone, this is William from China mobile I will present the draft networking Network resource programming with srv6 next slides. Please.

Z

uh They, uh the consent of network resource petition, is introduced in draft ITF test iitf Network slices as this script in section 6.1 of that chart. Nrp is a collection of resource in the underlying Network NLP consent. Consents of a subset of the buffer queuing scheduling, resources on each of the connected set of links in the underlay Network and RFC 8986 has defined a set of well-known srv6 and point behaviors, but those behaviors are not associated with the set of NRP of the links for slices or slice aggregate.

Z

So this document defines a new slv6 and point Behavior, which can be used to associate with a set of NRP, for example, the dedicated skills, resources or layer, 2, logical, sub interfaces. uh We record and Dot NRP next slide. Please.

Z

The uses of the end of the seed uh this end touch and now PC is mainly used to steer traffic forwarding through the associated NRP by using the end.chana PC to build a segment list. The srv6 policy have the capability to program, network resources and restricted strict test. Sla guarantees for one HP link, multiple and Dot Channel BC should be allocated, Each of which is associated with a subset of Link resources in such as dedicated queues, layer, 2, logical sub interfaces and so on.

Z

Let's see an example, as shown in the picture, one at the for the P1 node, the link resource from P1 to P1 has two and nrps one is gg100.q1 and another is g100.q2.

Z

Which are two dedicated cues on P1 physical interface, g100.

Z

Also, uh two and Dot NRP seat s are allocated to those two nrps.

Z

This means that for P1 note, the end.netic a column, one colon colon 11 is associated with an RP.

Z

G100.Q1 and indicates to forward traffic to neighbor P1, where this NRP and the enter Channel visit a column. One column, column 22 is associated associated with NRP g100.q2 and indicates to forward traffic to enable P1 where this NRP.

Z

V6 policy uses the end.net PC to construct its path. Such an srv6 policy can provide strict SLA guarantees to customers next slide. Please.

Z

This is the price processing of and started nappy Behavior. The end thought behavior is a variable variant of Android X Behavior defined in IFC 8986.

Z

Any state instance of earned.nrp behavior is associated with two sets. J1 and J2. G1 is one or more Elson. Adjacencies G2 is NRP of J1 when and receives a packet. That's that's changed to S and the S is a local and dotted nappy seed. The line is 15 of the enter text. Processing defined in FC 8986 is replaced by the following by the following, submits the package to the IPv6 module for transmission to the new destination, where a member of J1 using the NLP identified by J2.

Z

Okay next slide. Please.

Z

This is a use case of the end of the nappy behavior in the srv6 list line celero. uh In this use case, there are two customers with different list line requirements from P1 to P2.

Z

One is a list line with 1G benchwise, with strict as our guarantee and the other is this. This line with two G bandwidth restrict as our guarantee. So the controller will build two SRV 6 policies to meet the least line needs of those two customers.

Z

First, it calculates srv6 policy paths based on SLA, assuming that both paths are calculated as X1 X2 X3.

Z

Secondly, the controller cooperates with the network nodes to complete NRP reservation and the end.net PC allocation along the SRV 6 policy paths um also now take note P1 as an example. The two different tender piece, such as two dedicated cues, are partitioned from the network. Resources of the physical link, X1 and corresponding and Dot nappy seat is also assigned to each of those two and a piece.

Z

The results, as shown in the table, one, uh the seat, a column, one column, column 11, is associated to an RPG one, zero, zero, Dot q1 and the seat. The column column a column, one color 22 is associated with lrpg one zero, zero dot. Q2 next slide. Please please.

Z

Similarly, the NRP reservation at the end, odd and IPC allocation are completed on X1, X2 and X3 links.

Z

uh Finally, the controller uses the corresponding and Totten rpsc's on link X1, X2 and X3 to build the seed list of srv6 policy paths, as shown in the picture too. The pass for SRV 6 policy 1 is a colon 1, colon, colon, 11.

Z

and and a column, two column, color 11 and a column three column color 11., which satisfies the requirements of the customer one and the path of srv6 policy 2 satisfies the requirements of car customers to customers too.

Z

Oh okay, next slide.

Z

Next slide, please: okay, in this use case, the traffic from customer one will be forwarded to P2, while the NRP previously resolved for the per hoplink on the srv6 policy. One pass and the the pie providing customer one with and and head to end 1gbenchwise resource for list line services with strict SLA guarantee.

Z

Next slide. Please, okay! That's all for my presentation, any question or comments.

A

Thank you any any question of comment from the room just.

O

Obviously, I was wondering: how do you, how are you napping the uh it seems like there's a mapping between the uh NRP I guess when the when the controller is provisioning, the uh flow I guess to qos, because you mentioned queuing so.

G

O

Mapping that's happening as well as if you have, if you have that, let's say on the box, you probably have your standard queuing set up, but now there's a another layer of queuing. That's set up with the uh with this programming and I just how that works, because Ian are working today.

G

Z

Okay, that um I I try to answer your question so.

W

uh I would like to answer the question. I I think it, as you just mentioned, the NRP, maybe uh existing uh in the controller uh for the provisioning, uh as well as how to attach the NRP to the forwarding leader is a question, and uh it's very hard for controller to manage the dedicated resource in the forwarding leader so uh combine the NRP in controller uh modeling and the the and the NRP Behavior.

W

It will uh to set up some good solution. Very simple. uh You can use such as a service, 6 policy and as well. uh The dedicated resources in the uh forwarding leader can be attached. It will help operators to support the high quality uh list. The line, uh something like that.

G

W

G

Thank you. Maybe it sounds like. Would it be like a layer of.

O

uh Like a hierarchical qos, almost I guess, like you, have a layer of key OS per per NRP, similar.

G

To like hierarchical qos, thank you.

W

Thank you, yeah.

A

Thank you next present next on last presentation is a segment concouring procedures for Magical VPN service in Native, IPv6, Network.

Y

Okay, uh hello, everyone from China, Telecom and I will introduce our draft on behalf of the co-authors and next slide. Please.

Y

uh Yes, we proposed this draft to define a new segment. We call it endpoint and VPN to contain the VPN custom informations, and this segment can be used to distinguish traffic from different customers and it can unleash this segment of the VPN multi-group multicast Group address allocation can align with the unicast ipvpn address allocation and this the the implementation of the solution is similar to realtor and VPN, and it can also come compatible, always a beer and other Technologies and next slide. Please.

Y

uh Yes, uh one uh a customer wants to join the multicast group. uh The ecosp uh is connected to uh will generate an endpoint and VPN according to the VPN custom information and send the segment to Ingress PE and increase P. It will maintain a mapping table of endpoint and VPN, and the European custom informations and the generated endpoint and VPN will be inserted into the table and when uh CE sends a multicast packet to Ingress P, the Ingress P will encapsulate the package with a header.

Y

According to the endpoint NYPD mapping table and the destination address will be set to the endpoint I'm VPN. But then the packet will be sent to the the responding request piece and the behavior on P routers depends on the generation method of the multicast tree and finally, the egress P will decapsulate the package and transmit it to the corresponding C is a Nestle at least oh. Yes, this is the encoding of uh endpoint mopn and it will come first to the IP wave, 6 multicast address and the way defined uh an away bit uh over.

Y

It defines a highest speed in ff1 as the way bit, which means the VPN multicast bit and when the speed is set, it means the multicast group address is uh and a VPN segment. Otherwise it is a common multicast address and the network network prefix field will carry the customer's Rd value when the web it is Set uh addressed.

Y

The information carried in this field should be determined by the other base in ff1, and the group ID carries the information of customer group Nestle, please, oh yes, this is the generous generation procedure of uh endpoint type mypn.

Y

When an Ingress P generates the uh endpoint and VPN segment, it will firstly extract Rd and multicast Group address of the customer and set the value of vb21 and set the value of a net Network prefix to the customer's Rd and attend the Ingress. P will set the value of group ID field according to the customers multicast Group address. If the address is iPhone, 6 ipv4, the the value of group ID, will be set to the ipu for a multicast group address and if the customers multi-group address is an ipoa 6 address.

Y

The egress P will check the P bit in the address and if the p is equal to one, the group ID will be set to the group ID in the customers multi-group address and otherwise the value of group ID will be set to and 32-bit value that is hashed from the customers.

Y

Multicast Group address a NASA, please, oh, yes, this is a the behavior on the increase P when it received uh an happy way. 6 package waste, the destination address, D and the D is associated with an uh endpoint of mvpn segment on the egress PE. So the englishp will check the way bit in endpoint and VPN. If we beat is equal to one, it will look at the endpoint MP mopn mapping table according to the and and point and VPN value and find out the associated Rd and the related unfield table T.

Y

Then it will remove the outer ipa6 header with all its extension headers and set the packets Associated and flip table 2T. Finally, it will submit the package to the egress MVP lookup for transmission to the new multicast Downstream, and if the wave a bit is equal to zero, the Ingress P will set the is associated I've made table to Global fmib and submit the package to the egress MF me lookup for transmission to the new multicast Downstream and next slide.

Y

Please, oh yes, and since, since this is the first time for us to uh give the presentation of this draft Subway, uh we hope we can uh get some comments and or suggestions about it, and we will reverse this draft accordingly. Thank you.

A

Thank you one question: did you ask a scrot that the best baseball team up did you ask for slot at the best working group to present it.

Y

uh At this time we don't apply the third time, maybe.

A

It would be good to ask for to present for next meeting, because it's heavy on VPN on multiplication.

Y

uh Yes, uh maybe we will uh presentation it in next uh ITF meeting. Thank you.

J

Hi uh I'm Sasha Weinstein from riba uh I, had looked at the draft before the president sure before the presentation and send an email to the authors and the work group. It seems that the solution proposed in the draft only can work with Ingress replication as the provider tunneling technology for mvpn, because they provide the structure of the end dot. Nvpn Sid includes the route distinguisher of the multicast, where, if in the airspe rail distinguishers uh in menu, if not most cases are specific to each address P.

J

For instance, if you use type 1 route distinguishers, they would include the uh something like the router idea of the recipe is part of it and therefore, in order to work, this proposal would require the Ingress fee to send a dedicated packet uh to each address fee, where the specific mvpn service is instantiated.

J

At the very least, I think that this should be expressed if my understanding is correct. I think that, at the very least, this should be explicitly specified in the draft if I have missed something. I would really appreciate explanations.

AA

Yeah I I I think your uh actually for for a podcast scenario, the Rd of an artist value for all of the Eagles okay.

AA

Then the you know our job just uh described for for matter of the engineer, VPN for the multicast services and my customers, the marketplace audition must be the same for the market. Services, okay,.

J

The text is definitely not what the uh normal uh mvpn Behavior suggests and uh in any case, if you started from the unicast uh a VPN service that you wish to upgrade to multicast VPN, you don't change the route around around distinguishers. But in any case, if this is the Assumption of the draft, it should be stated explicitly uh because uh I maybe I have missed it. But I have not seen anything like that in the text normally in layer 3 in uh and that that's. Why?

J

I think that if you present is drafted at the best worker, it definitely should be presented because it includes the bgp parts. uh This the same question would be raised.

AA

The Rd can be set differently or in your uniquely so I think we saw the Express in our draft or in our next practitioner, expressed as the Rd value of so to be same for the all. The equality.

A

If you can have a short question, please.

O

I sure I did just a quick question. Does this uh draft? Does it follow like uh the mvpn procedures, RFC, 6513 and.

G

6514 uh using like Leaf ad to discover the endpoints.

O

Like the auto Discovery piece- or this is completely separate from any uh nvpn procedures, also I I do agree that this seems like it's.

G

More in line with like Ingress replication and uh not uh and not any other ptas. Thank you.

E

You can comment briefly.

AA

Hey John, uh I think the kind of solution for the foreign.

E

E

So thank you folks for all the presentations and for all the discussion, which is more important than the presentation in many regards. So thank you very much for your time. We'll see you on the mailing list.