Internet Engineering Task Force Interim Meetings, 28 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: BESS WG Interim Meeting, 2020-04-28

Description

BESS WG Interim Meeting, 2020-04-28

A

Just make it fill the screen.

B

A

A

I just make this fill out the screen. That's all just pull it maximize.

A

B

Is it bigger now.

A

I think this is good. Okay, you maximize the width now maximize the height as well.

B

Yeah but I have a very large screen, unfortunately,.

A

It is better if you pull it up.

A

B

So here is our agenda not too packed, but we may have a more long discussion for the latest draft based on the exchange we had on the list for so for the igmp mldr proxy draft. So we kept this draft at the end to keep the maximum amount of time for for the discussion.

B

Working up statues, no new rfc published since the last ietf, we still have two documents in the rfc editor queue mainly due to some dependent documents that are, uh I think dci evpn is still waiting for the kernel on caps uh to be closed and evpn. Prefix advertisement is uh waiting for the inter-subnet forwarding uh to also be our to also be closed.

C

B

For this intercept net forwarding document, uh we are still pending some updates from uh from the offers on this one.

B

We still have documents under isgp review and for especially for the nsh bgp control, plane document. I think adrian, you still have to provide some replies.

B

On the comments coming from the isg.

B

D

Asking me um and using my name: what are you asking about.

B

Oh on the nsh bgp control plane, there was a couple of comments coming from visg and we haven't seen anything.

E

I see a name already in working group status in cube. Is there someone wants to some comment.

E

I see italo busy has written a name in working group status that there is some question.

B

We can go ahead: okay, yeah, let's continue.

B

Okay, a couple of documents uh in shepherd review, uh especially the apple costs load balancing. So I have provided my review.

B

The main issue with draft is that it relies on some of the link bandwidth community, and this draft is still expired for the moment, so I reached out via the offers, and they will try to see how to to revive the link bandwidth documents to uh to accommodate the changes required by the unequal class in draft.

B

The virtual internet segment still requires a new region.

B

Msd msdp sa interoperation- I think montgomery, so you are done with the review on this one.

E

Yeah I I have completed the review. I just need to submit the write-up and most probably I'll do it today, tomorrow, okay,.

B

um I also provided my my review, but I haven't seen any replied yet from from the offers.

B

Okay, we still have a couple of documents in uh the working group: let's call queue. um The good thing is that we are, the queue has uh reduced from uh from the last uh from the last status.

B

So it's a it's a good thing, but we still have couple of documents to our to pros to proceed and we will start right after this recitef.

B

B

uh Some updates we got uh on the working group document, so the cast flow df election need to close the xp proxy draft first first df recovery. We need an update from our from the offers on this one and data center.

B

I think adrian this one is also on your side. Could you try to give me an update on the data center gateway.

D

uh Yes, I so this this one had been bouncing backwards and forwards between me and you um trying to um resolve a final question, and uh um probably the best uh approach to this is that if we can uh carve out ten minutes between us to actually talk and um and get conclusion on that last point.

B

Okay: okay: let's do this.

D

I'll pin this okay.

B

B

Okay, um evp and vpws fxc have nothing special to mention regarding the young models uh discussing with um via the editors. The main uh issue with the document is that we, it seems that there is no implementation yet uh on this of this young model, and even there is no uh at least we are not aware of any prototype, so the question is: do we want to move forward the document publish them as rfcs without having implementation.

B

Probably it may be too risky. There are a lot of interdependencies uh between the models, at least in my opinion. I think it may be better to wait at least to get some feedback from people prototyping and so on.

B

This may help to ensure that what we are provide currently providing you know in this draft is our correct and can really be, can really be implemented so yeah. If people uh agree on that, we would like to uh to hold on on this draft uh until there are some implementation of prototypes.

B

F

B

People are aware of any prototype, feel free to share.

G

So this is manchu here um with. There is at least from our side, at least here from the cnn side we do have. We don't have a complete implementation, but we do have some versions of the implementations for l2vpn as well as for evpn. I I think you. What you are writing is that there is a lot of interdependencies between the l2 vpn and evpn and network instance, and all other stuff.

G

We we do need to sort those relationship out uh and and but we I think what does need to happen that we need to. You know we need to put the document out. People are maybe not comfortable implementing something that is in the draft status, so I think we we need to make a progress and and bring it to the rfc status, so we can so that more vendors would uh would do the implementation.

G

That's my take on that. I think.

B

G

B

You you see also the the other side that if we publish uh as rfc and we discover that um the model is broken in some way, we will have to publish a new rfc tour to correct it. This has happened already with a with couple of young models, but my point is: if we can try to avoid this, uh that will also be better, but I I am, I understand also your point.

B

Maybe what we can do is we can take it to our to the to see now how we can proceed.

G

You suggest well, it is not in the broken status as as of now I mean it is that there are some losing that we need to tie it up and- and I think one of the aspects of that is to provide an appendix that- shows uh an example on how you would configure an l2, vpn or an evpn.

G

You know what would you support as an example, and that would make it a lot more clearer as to how this model can be implemented and also it would make it a little more clearer. If there are any loose ends, then we said: okay yeah. We need to tie these things up so that exercise we do need to go through um it. It just yeah it's just uh taking longer to get to it.

G

Yeah well, patrice is online, hey patrice. What do you think he's he's leading the evpn aspects of it.

H

Yeah, I think we need now to prove that the pudding is working, so I would agree with you that we need to have maybe um explaining how that's gonna get programmed.

G

You sorry, I didn't get exactly what you were saying.

E

Should we put an example aspects.

G

H

Yeah example would be important right. We discussed about that menshub while back, and I think this is something that um that we need to just show, and so people understand how it works, and then people can provide comments if they are happy and then, if they are happy, then we can release.

G

And it will also help us identify any gaps right just.

E

Can we give a turn to people on the queue please? uh I see, jeff jeffrey has and italo busy in the queue.

E

Yeah, you can go ahead. Please.

B

We can't hear you.

E

Jeff you want to go next, please uh I see you, you have written name for yang models.

I

Yes, uh something everybody can hear me yep, thank you, um so I I have done no contributory work towards the l3 vpn model I got added to it was sort of ambushed into helping with the model a little bit, uh but the comment I do want to make on the yang models in general and part of why I got added to the l3 vpn model was that these things are built on top of uh services, that, in many cases that run on top of bgp, the bgp model itself was not in good shape.

I

Until roughly the last uh six to nine months, uh I've been working very heavily with the uh ritual authors on that draft. uh They try to make sure that the contents of the bgb model are clean and we've spent the last couple of sessions worth of editing working on some of the structural issues.

I

The last set of issues that I've identified for them that need to be dealt with are what I tend to call inner work issues. It's perfectly fine to create a model, that's standalone, but it doesn't. Do you a lot of good unless it actually works with the things that it needs to work with? So in the case of these vpn models, there is interactions with you know, bgp in terms of some of its operational configuration state, there's interactions with policy, which is a model, that's maintained by routing working group right now.

I

So my recommendation for this working group on these models is part of the exercise. You're talking about the appendices of trying to use the things trying to figure out what the config state looks like try to figure out what the operational state looks like. Can you actually get your work done? That's common for a vpn network and if you can't that's usually either because there's some structural or content issue in the model itself or potentially there's a missing component that should be supplied externally.

I

You know so like stefan- and I have spoken before about where the affy safety stuff is maintained and who owns that piece, that's still to be resolved, but now that the pgp model sort of stabilized.

I

I think that dancer could be happening very soon, but it does mean that uh for each of these models I suspect there'll be policy components and you need to go to routing working group to make sure that your issues are dealt with there and if there's issues with the bhp model, uh I and the other co-authors will happily take further feedback on that.

G

Can I respond to that.

G

So so I think that I I don't think we should have too much interdependencies between. uh I mean yes, the l2vpn and especially the evpn uses the pgp, but as far as the policies I wouldn't go too far into uh you know what all the policies that are related to the bgp be brought into or have created dependency within evpn for the policies bgp policy right as long as we just have the route targeting code exports and all that and uh the bgp session related stuff.

G

I think we should try not to have put too much interdependencies. Otherwise this will never get completed. There is an ldp and for pseudo wires and all that stuff right.

I

If I could have the follow up on that, uh there'll be a brief one.

E

I

Again jeffrey has, uh I agree that minimizing interpret dependencies is good. I agree that not trying to be completely feature complete for some vendors implementation policy is probably a right thing. The policy modules that are being written across etf are mostly trying to provide necessary hooks so that vendor implementations can do their job again. My request is that, as everybody goes through their various models, so I'm going to pick on evpn.

I

As a specific example, evpn does interact with policy for things like dci and for things like uh you know, the evpn replacement for effectively l3 vpn.

I

If you cannot do standard operational behaviors in your model, even as a future extension, it means your model is not structured right. So worry about your structuring issues and figuring out what the requirements are. Everything falls from there.

G

Okay, so I thank you, this is himanshu again. I take your comments. I think we are trying to come up with a busy vpn with, because evpn has us lots and lots and lots of features if we we cannot keep up with uh with uh all all those or accommodate them, but you are right. We need to put structure in place. So if we want to extend later, uh there are right hooks available.

E

So comment on behalf of italo because he is not able to. I think we can't hear him so his comment is that we need to coordinate with opsa working group regarding l2 vpn, l3, pin yang model and l2 nm l3 nm yang models.

G

Okay, I would request to send exact comments on what aspects of uh we should look for in the other ops, a working group, or that would be helpful right yeah. So next I.

E

Think susan uh is in queue for yang model.

B

Yeah, very briefly, because.

J

Pre-Brief, if, once you answered jeff's question, I would also like you to describe if you anticipate versioning, how you're going to do the versioning to pick up the policy you cut out the first time see the net uh mod versioning discussions. Thank you.

J

B

Okay, let's finish the working group statues. uh We have couples of new working documents uh since the last itf, uh the last one um I think, matthew boulder. uh You did the poll on this one and there is a consensus to add up to the vietnam and has not really occurred yet, but.

B

We still three documents.

B

For which authors have required via the working group option, so we will see and proceed accordingly.

B

Let's start with our.

B

K

B

L

Stephan hi folks, this is gaurav davra um I'll, be covering the srv6 bgb services, thanks monkanma for adding me to the first slot meeting right after this. So let's get to it.

L

So, as we know, uh this document kind of covers the signaling for all the af l3 vpn, v4, v6, global and evpn next slide. Please.

L

So this kind of lists the draft progress. We first presented it idr in itf 98, and then we introduced the evpn in idr in ietf 101.

L

We presented the document in one of four in uh bess uh the entirety. um We also took the comments from the working group regarding the update packaging optimization and represented it at 105, and then we adopted the document just before 106.

L

So what is the update in this document? um Pretty much? The document um is the same. We have added some clarifications based on the comments which we have received and working closely with various vendors and authors. um We have um added the multiple signaling just to provide the flexibility for the same route. um We have added a mechanism of course which, which has been mentioned earlier about the transposition scheme, so that to update the more optimized packaging and the details of that has been added.

L

There are some examples which have been added for both evpn and for l3 vpn. um There was some ambiguity around the next hop handling and set reachability.

L

So there was a clarify clarification text which has been added for l3 services on how we handle the next hop um for both the next stop unchanged and next stop changed cases um and also the text about the outside reachability um clarification.

L

As the error handling uh we for this particular tlb, we have also clarified about how to handle if there is a if there is a formatting issue uh to treat it as a withdrawal, and that has been added in the document as well. In the error handling section.

L

There was uh based on the implementation and the comments which we have received working closely with some of the vendors on um on the evpn signaling part. We have added the clarifications for the route type 3 handling and also added the text regarding the um optimized packaging for and signaling as well, and then um this this was kind of missing from the document, the local bias method, which is um following the same um evpn based procedures.

L

But we have added the text on how the local bias is also handled for srv6, so that has been included in the.

L

Document um there are, there are a few editorial changes, and this is just purely to uh make sure there's a there is a improved document flow um and adding all the required changes based on the feedback and implementation uh learnings, which we have done um over the past past few years um and also working closely with with both um with multiple vendors. So we have reordered some section just to improve the document flow, and that is purely just the reordering and there is no any other specific changes.

L

um We have also added the tnv encoding, uh which is added before the services signaling section. Of course, we have updated the references for 55.49.

L

There are some redundant text, which was there for l3 services and for some evpn part, so we have. We have removed that from the common sections and moved it to the appropriate base.

L

L

Regarding the inr.

I

Early allocation.

M

L

We requested for the working group early allocations uh march 3rd just before this meeting yesterday, ac actually approved it. So thanks ac, for for that, we request for the formalization of these allocations code points, please so that you know this. This can be. This can be completed, and these are the suggested code points which were requested.

L

Now regarding the implementation and also the deployment, this document is widely uh deployed um and implemented from multiple vendors there's, some implementations, which are already in production, so we have or and shipping we have cisco, which have in multiple cisco platforms. It's it's implemented in its entirety. We have um huawei, uh which has also implemented it, and there are other vendors which we know of are already working on on the document, uh implementation and working closely with us. um There is also open source implementations in linux, kernel and also in fdio.

L

There are multiple deployment deployments for second routing services document in with softbank china, telecom, china, unicom and multiple other vendors. As you can see, and there was a multiple vendor interop, which was which was done at en entec.

L

uh There are more details. This document below has been implemented, updated to mention all the implementation details. So if somebody's interested, please, please feel free to look at that document.

L

Quite a few many, so I didn't mention everything over here um next steps, um since there are multiple implementations and deployments, and this document has been around we are requesting and preparing for the last call um request for this document around madrid 108.

A

L

There any reviews and comments about the document please feel free to reach out to us, and we will be happy to work with you.

L

B

Okay, do we have some people, uh I don't see.

E

B

So we can go to the next okay.

L

Come on drop off after this okay.

B

Thanks: okay, linda you're, the next speaker.

N

Okay, I sent you an updated slide. Did you have? Can you use that one instead.

C

C

K

I have downloaded, I added just one.

N

Just um um anyway, I can use this one, it's okay, so this um draft has been presented in last two ietfs, I think- and it's mainly to describe how do we use uh bgp for sd1 case. So this is, um this slide is basically showing them. The key items being discussed so many to encourage more people to read. It is not that complicated.

N

We follow the same format as ifc 8388 that one described how bdp used for evpn, and so here we just have three major part. One is the use cases and requirement, and the second part is the bgp through to show how different btp update messages are carried through the network and um third part, is the packet walkthrough.

N

um So I'm here encourage people to read it because we really want to um call from working group adoption next slide. Please.

N

Okay, so for sd1, some of the key characteristics of sd1, primarily sd1. We all know it's overlay network right, so basically augment the network. um The the underlying network can be many different kinds and can traverse multiple segments of a network belonging to different operators, and there could be multiple parallel paths over different underlays.

N

Second, one which is not very related to routing area, is about internet breakout, and today many corporations like um they have traffic. My company here will run all the traffic to santa clara office before we can go out to the internet because all the policies are enforced over there.

N

So in many of the sd1 deployments it is very highly desirable to distribute the policies to individual sites, so the internet breakout can happen right there to improve the performance, so the second one, the third one is some of the applications need to be boarded based on the application id instead of destination id. So those are the three key characteristics of the style network.

N

Next slide. Please.

N

Okay, um so um in sd1 there could be like many instances on they call segmentations um so for a particular edge node. They may need to support sd1 instance for a customer or client one or maybe need to create a support. Another instance for um a different client, it's very much like vpn vrf and the only difference is it's not vpn. It's really over the uh maybe untrusted network over episode tunnels.

N

So um um so because their similarity we advocate for using similar approach as vpns right vpn has the raw target to represent different route instances. We can use the similar extended community to represent different sd1 target id so that they can the.

M

N

Put the advertisement uh update into appropriate um running table and also that the sd1 instance id need to be carried by the payload. So um here we are advocating that um we can use similar approach um to carry the vpn as vpn id being carried by the nri.

M

N

Attributes we can use similar approach like um savvy 128 and route distinguisher to discrete distinguish routes. Eks different clients may use their own. Private addresses may collide with each other. So that's how we can achieve separating different sd1 instances belonging to different clients.

N

Next page, please.

N

Another key part is sd1: network can be deployed in very large scale in in a way that, geographically in many different locations and for each location, each of the devices, the edge nodes may be only interested in very, very small number of uh instances like if, if I have a sd1 um device deployed in a small uh shopping mall, he probably only interested in one or two instances, um but the sdra network itself may consist of um hundreds of instances.

N

So it is very important that um the propagation of the update has to be constrained. So um bgp has a really good um a property to constrain the route propagation. um This is ifc 4684 to constrain the the btp update. So if you are cpu one, for example, you only have maybe one I see one instance interested. You can just tell your corresponding raw reflector, hey, I'm only interested in the green instance, and then cp2 is only interest in green instance and versus cpe 10 is interested in blue.

N

There could be one cp interest in both instances, then the update will be sent both updates will be sent to them. So by constraining them. You can reduce great number of control messages floating in the network, of course, for smaller scale deployment.

N

It is also possible to manually set up the policy on where you want to distribute, so that's just menu, static method.

N

Next slide, please.

N

um Here, I'm just walking through how we use bgp to propagate the properties of the sd1 edge and in this example,.

E

uh Who is not speaking, can you please mute, uh I think gyan. Can you please mute.

N

Sure, okay, so so this um scenario basically um for attached routes, multiple routes, uh we can use one ipsec tunnel, regardless of which network it comes from um so with this is very simple you just uh as a traditional manila, savvy one ipe and to say hey. That here are the prefixes, and here are the some of the tunnel attributes. Of course you have to be able to indicate what kind of ipsec properties you support as like cpu2.

N

While he announced the property, he has to say what kind of algorithm his support, welcome encryption, his support and what can public key? He support sent to the rod, reflector and the raw reflector were based on the interested group propagated to cpe3 and cpe to cpu1. So that's a very simple case of using bgp to advocate uh propagate the the sd1 attached routes.

N

N

So, in this case, it's about supporting different topologies and the one topology one a case of sd1 is like see here we have um a red round right: the vlan, 25 and prefix 22.1.1, slash 24., so this round is only to be distributed to cp3, not to cp2 in other routes. The blue route is only 2 cpu 1.. To achieve this purpose, you can the cp2 the origin of the announcement basically um put two separate bgp messages to the to the route.

N

Reflector one is to indicate the blue tunnel, and this blue tunnel is only to be propagated to cp1. Another one is the red tunnel that one is only to be distributed to cpu3. So by doing this, you practically create a different topology for the sd1, because sd1 can be over very different geographic locations. Controlling the topology. Can it's currently actually a big challenge. Bgp is great in in creating that make it possible next slide. Please.

N

So um this one is um actually. This is where I made a mistake here. um This is fine grand um um tunnels, meaning for every prefix. um They have they need to have separate tunnels. Then we need to uh three separate messages for three of the prefixes, so basically, in the first update, we'll only have the first client route, 10.1 and then second message uh we'll have the vlan 15. The third message is the prefix 12.1. So I'm sorry this one, I made a mistake. I said, update the slide.

N

Hopefully you'll upload that one, so this just showing that if you um for this particular deployment, you want different tunnels for different prefixes, and then you can use bgp this kind of btp to to achieve that. Next, one.

N

Okay, so so the for the application based segmentation in sd1 um bgp is great to achieve that. So the use case is really, I think many of the retail space using sd1 their payroll. The payment uh traffic can only go to the payment gateway versus other traffic can be going to any other nodes, so it is very strictly enforced.

N

The payment goes to the payment gateway by using bgp. We can achieve this kind of topology next slide.

N

Please, okay, so uh this just walks through using the bgp, basically for the red route, and you send uh update to the rod, reflector and the raw reflector will send a that into the payment gateway for the red and then for the others. The second update will be distributed to all other nodes. So that's how we use btp to achieve the application based segmentation, topology, okay, next one, please.

N

um This is just some other optimization you can achieve, because to create a mesh peer-to-peer ipsec tunnel can be troublesome for some deployment, so, instead of creating everything is based on client based. Creating those um ipsec tunnels for each client route is possible to treat ipsec tunnel as the transport pipe, so that the ipsec tunnel is um is treated exactly same as a pipe between two nodes. The traffic can be transported either over ipsec tunnel or over the vpn mpos. This is assuming for the cpe node themselves.

N

They actually have different type of elderly network attached and this one okay next slide. Please.

N

Okay, sorry for that, okay, so this just analyze the pros and cons of this approach. The pro is reducing number of ibsec tunnels in the network. The the trouble is each node has to be able to terminate the tunnel and then transmit forward to the next step. Next slide, please!

N

So that's the end! Okay! So here we are calling for uh working group adoption, um because we think this draft is very helpful for the industry. For the other organizations like math at metro, internet forum bbf, they all have sd1 project to show to them that hey the bgp is very well suited to scale sd1. I think it will be very good document for other organizations for the industry.

N

Okay, that's it.

E

Okay, questions.

E

So we can move to next and while stephen is pulling the next slide guys who have not signed the blue sheet, please uh write it in the ether pad. I have. I have sent the link again on the chat.

O

Can you hear me yeah yeah, I'm here, can you hear me okay, great yeah, good evening, everyone? My name is I'm here to present network and vpn services, performance monitoring, young data model jobs. The name we listed here are also this job and.

O

O

Yeah uh just a little bit background. What is this draft about? Actually, this job that I define a young data model that can provide end-to-end and network performance and monitoring?

O

In addition, it can also can provide a vpn service performance monitoring, so foundation for this worker is a performance management methodology that already be proposed for the ethernet network, rpe network and mpls network. We can use this performance amendment methodology to uh connect the performance data, to build the data source and about how these performance data can be aggregated and exposed to the upper layer. This is something we really want to address in this job. Next.

O

So what is current status of this job? This job is not a new job. We already present for twice actually the first, we present in uh best working world actually in ietf 103, and we got a lot of support for this job and it actually be putting the candidate for working with establishing.

O

Also we in the previous ietf meeting in singapore, we presented this chapter in this working goal: try to make sure yes, uh there's no overlapping with, so that he is performing the mainland ready to walk and uh updated. uh Since uh the last version we actually uh added two new author, uh mohammed from orange and oscar from telefonica as a two new concert and a baseball input.

O

Actually, we added vpn summary statics at the network level and we so in this model, not only we model the parameter for the performance metric, but also we model how the performance measure are measured and connected.

O

So we add the reference time and the measurement interval and to use this as a reference time uh to do the performance, data aggregation and, in addition, actually, we replace the average performance data, such as delay, value or gd value with the percentile value, because we think the percentile performance data values can reflect the worst behavior of nano performance and also we make a according change for the young data model code. Yeah.

O

Next, uh next page uh yeah, so what what is the use cases? I I think the typical use case is a real-time vpn service and monitoring. We as a customer or the operator. They don't care. What kind of performance measurement method you are using in the underlying network. Do you care about it? uh What uh they're more care about it? Well, what is end to end nano performance or vpn service performance?

O

Suppose you establish the interconnection between several vpn sites, you care about what is the latency or packet loss, or what is the bandwidth between two vpn side when you inject the traffic from one weapon side to another which inside so we actually can measure turning the performance measurement data using existing perform the memory methodology and we can actually use leverages uh managing planet animation mechanism such as young push or some other magazine to export these performance management data and to the magic planet to the upper layer.

O

The upper layer can do the aggregation and aggregate these performance measurement data to provide end-to-end performance name and results, though also they can leverage it like a path, computation method to calculate these performance. Amendment data such as entry and latency and packet.

M

O

And with these performance main data, they can optimize the network and build the closed-loop network management, so these are key use cases. Next,.

O

So to provide the network perform end-to-end nano performance uh monitoring. Actually, we also need to establish the relationship between the the service, topology and online. This will show example how these relationships can be, and so we can uh connect the the basic uh performance measurement data in the underlying network and with this uh relationship between each other, and we can actually aggregate the data and to provide end-to-end and nano performance monitoring.

O

O

This is a model strategy we propose actually uh so uh compared with the previous version. We had a few new parameters. uh Actually, this new parameter actually in red circle actually uh follows the timing away proposal uh like a vp, vpn, summary statics.

O

We put it at the network level so that, basically, this is a model uh design. Actually, it's augmented from the authorized nanotuber that has already published as and in addition, we add some of uh other terminals to like reference time and measurement interval reference time actually show when the points later start to to measure the measurement interval to show how often how frequently the proportion data can be measured. So this can be served as a reference uh time to to help you to to provide provide the end-to-end payment data.

O

So, in addition, actually we replace the average value averaging performance. Metrics such as.

D

O

Delay and jitter with the percentile value, because, uh based on the discussion we think uh uh personalized value, can we well reflect the worst uh cases with the network performance, so we use percent high values. uh That's a the change when we made compared with the previous version. Next.

O

So uh so we we actually get the performance data. Actually you need to export this data to the up layer. So either you can use the young push, uh manipulating animation mechanism to subscribe, the performance data you are interesting and, and then the device nano device can uh to publish the data.

G

O

uh Continuously, uh in addition, actually we can uh uh allow the uh the cooling based maximum. You can define the customized rpc. You can actually query the performance data, you are interested, and so we can allow both both way to reach out this urban name and data.

O

Next, so for the next step, we think that this job has been around for a while we actually already presented for four times. Actually, we simply uh talking with our colors. We think that this job in good shape for working with adoption.

O

That's all thank you.

E

I don't see anyone in queue, so we can go to the next.

B

No, I I still have uh stefanikowski speaking as a child still have one question probably martin can um can also can also help in this.

B

So your document is defining a lot of performance matrix and I'm still wondering if you could uh leverage on uh on some existing work uh that is defining such performance metric, because your performance metrics are not uh tied specifically to vpns.

B

I think it could be applicable to uh to many performance measurement use case.

B

That's why I'm still wondering if it's a good thing to have this performance, which at least some of these performance metrics define in this draft or if someone else in another working group, should define this performance metric that you could potentially potentially reuse, because I don't.

P

Think that's really a nice working group job.

B

To define modelling of performance measurements the applicability to vpn? Yes, it applies to best, but the performance matrix itself, except if it's something which is really specific to a vpn.

B

Yeah I just want to to have over working opener in itf, trying to redefine something that you currently have.

O

uh Chris uh stefano answer your question: I think, for this job that we we actually don't define any new uh performance metric. We just reuse the performance measure that the uh you know the uh proposal in maybe existing working group actually using the performance magical methodology. Here we focus on the performance, metric reporting monitoring, actually uh how these uh these performance data can be uh exposed to to the upper layer. This is our focus, so I'm not sure we actually define any new performance metric.

O

uh I agree actually.

M

Maybe we need to find any.

O

New performance, they should be different. They should be discussing some relevant working like rppm or some mpl, but, as I mentioned in the background slides actually, we we don't have to define any new performance metric actually for a vpn related parameter. We in the latest version we added a vpn summary statics. This is something related to the vpn, so.

B

Are you currently reusing some young models coming from ippm.

O

uh We we leveraged their maintenance methodology, they proposed uh this can be used yeah, but it's not a matter.

B

Of only methodology methodology is okay, but I'm also talking about uh all the yang leaves and containers that you can use. That may be reusable for other use cases.

O

The performance metric- actually this is some data we can use in young to to model that actually young model just just a tool. Actually they focus on the you know, performance monitoring how how to you know export this kind of matter to the top layer. So I I think, I'm not sure that's our focus to define any new performance magic. You know I already clever in the background's life. You know this. He presented in previous meeting. You know about this. You know.

E

So I see there is a question from uh we talk. Get please come to the mic.

O

L

What is the question.

O

In the chat window.

P

Sorry I was speaking to me: can you hear me guys yeah.

O

Yeah all right.

P

uh So yeah, along the same same lines. I I wanted to ask with regards to these, so I guess you're proposing to to sort of uh um sort of extend the sort of topology young model, with the ability to sort of take some some some measurements or maybe define some kpis for for some of the components there- and I was thinking well. The name of the draft says vpn sort of performance, statistics and and yeah these.

M

P

Like general type of statistics related to through you know, which then can.

O

Be around this chapter actually yeah yeah. We went about the generic performance name and monitoring uh model. Actually this not only can be applied applicable to airstream, but also can be applicable to l2 vpn. Actually, this this is a you know. Just a you know, it's a common building blocker that can be. You know, applied to many vpn service models.

P

Right so you're sort of like proposing.

O

P

Sort of like a generic extension to or sort of like a set of, uh maybe kpis or values that could be measured with with some some kpis set in there because I'm thinking of like for for l3 vpn service, I mean you, could you can have you know? One type of service can have a different. You know sls or kpis from from different type of service, and and I'm just wondering how would you sort of generalize.

P

Or extend these, you know models so that you could sort of marry up what is going on in sorry, say: uh ultra vpn service model with the uh expected sort of uh performance characteristics of that service. Once instantiated I.

O

I think the design principle is we can use error. Sorry, vpn purpose measure as a basis and try to make it extensible to cover some other cases like l2 vpn. So you can see actually this uh the the api way proposed actually not.

G

O

Can be applied to the ip uh network but also can be applied to the mpl's network, so we will try to generalize this, but the basis actually is, you know, use air through vpn performance metric. Actually, this is a not a new material proposal. Actually we just leveraged the existing performance measure. We can do the aggregation to to expose to the management and so because, in other layers, they care about the end-to-end performance, metric or or or tunnel level. Metrics.

B

Okay, so sorry, but we are, we are out of time for for this discussion. So please continue on the list. We have to move forward.

O

O

E

E

Again, can you hear.

E

B

Hello, can you hear us.

E

Maybe even pull up my slide. Meanwhile, he when he comes up.

B

Okay, let's move to the next.

B

E

Yeah, so we can go to the first slide next, so this slide, this draft was presented again in ietf 106 and, as I had mentioned during 106 that we already had working group last call done for this, and it was pass working group last call when juarez came up with comment, that there is a field in route type 8, which says sequence number, but draft doesn't say anything about what to do with the sequence number.

E

And after that we had a couple of meetings across vendor and authors, and there was a lot of discussion during iit f106 on the halls, and we had some of the discussion going on with different vendors over email as well. Next slide.

E

So one of the main challenge which we faced with this draft was there were two set of implementation out in the field and one of with sequence, number and one was without sequence number. So now all the discussions were happening that how to make sure or which direction this draft should go and how each vendor can interrupt without any problem. So there were multiple options were discussed across different vendors.

E

So one of the option which I I had presented during last ietf was removing sequence, number 4 byte from the route type 8, and the impact of this change would have been now, since we are saying that there are already implementation who have sequence number included so route reflector has to have to make sure that it can understand both length and it can reflect both.

E

Now there are some implementation where individual ps they do session flap in case they don't understand the routes, so there were chances that even all the p's has to understand both of the length, which was, with sequence number and without second number, the second options which were under discussion where moving this 4 by 2 reserve field. Because every author and almost everyone in the working group, they do agree that there is no real use case for sequence number in route type 8.

E

So there is no point: keeping a 4 byte field, as a sequence number, which has no use so alternate option was moving it as a result field and always make it zero. And now the impact will be for the vendors, who don't have these sequence number included already in nlri? It has to be included.

E

Third option, which came during recent discussion in mailing list, was having complete new code point, so we keep row type eight as is, and slowly deprecate it and get new code point which will have route defined without sequence number and slowly. We migrate to the new code point.

E

But with this option challenges where we were while we were having discussion internally and with some other vendors that if we go this path, it is, it is little complex that we will have to support both of them initially and then slowly maybe have some conflicts knob to make sure that it moves from one of the implementation to other implementation. So a new complexity getting added for vendor as well as operators.

E

E

So, after evaluating all these three options and the impact, it is for sure that, whichever solution we pick, everyone has to do some kind of modification to their current implementation, and there are, we had already checked with couple of vendors, and each of them have some variation of implementation already.

E

So we are, we are proposing that maybe the one of the way to go about it is making this 4 byte as a result field, and it will not be part of key and sender- will always send it as a 0 and receiver is going to ignore this. If we go this route next slide.

E

What are the possible changes for each each of the vendor and this list? There are two things that this list may not be the complete list. It is only based on our discussions. We, I did try to reach out through our mailing list, plus nanak list, to see that which all other vendors have implementation of route type, seven and 8. So only these are the vendors where I could get positive response and again the expected change which I have written.

E

It is very high level change, because every vendor might have different kind of design and their change may be depending on what design they have internally, so for cisco. So right, right now, cisco implementation is without sequence number, and if we go this, if we accept this change so now, cisco has to change its implementation, where it will send and reflect type 8 with 4 byte of reserve field, and this 4 byte of result field will not be part of key anymore.

E

For juniper juniper already does send sequence number high level. I don't see any change, but internally it may be changed from key to non-key for nokia, based on our last discussion during itf, 106 and couple of meetings, they did implement that they will send by default. They will send without sequence number and they can accept both both of the format, which is, with sequence number and without sequence number.

E

So as of today, their implementation will work fine, but maybe they may want to go the route where they change this. uh They add four bit: bytes of reserve field and arista has already implementation where they actually have both implementation and they control it using cli knob where they can have, they can originate with sequence, number without sequence number and they can reflect both of them even for them as of today.

E

There may not be any change other than some internal uh change about moving from non-key to key to non-key and again these changes are completely from the high level. Each vendor can speak on their own behalf that how their changes are going to look like.

E

E

So I think that's all I had and if there are any questions, let me see in the queue so I see john, is in the cube john.

Q

um Thank you for uh for the update. um I just wanted to briefly say that that seems um completely fine to me um and uh it addresses substantially all of my concerns anyway. I'm good with that. Thank you.

E

When I see you in the queue.

F

My um hello, can you.

M

F

So uh change I just like to um request the current type to be reserved resolved, because I mean reserve in a sense is still show up in the draft because it has always been in the draft and then because of that, the implementation, as you said, based working on the draft to in order to provide interrupt procedures. So people two or three years down the road. They need to understand their implementation, which has been implemented based on the type nni type, with the sequence number so to be clearly documented in the draft.

Q

Can I um add a comment? This is john again, yeah sure that I I think, based on your on your presentation, that's what you were saying is that the draft would continue to show the field there and it would just uh label it as uh reserved, rather than sequence, number right. Yes,.

E

So it will change to reserve plus it will be not part of key anymore.

F

uh So may I comment on that in the future way farther away from the future. You know we can all move to the new format. This is a new format, which means the sequence number is not part of key, but you cannot erase what has been done today. Sequence number is part of key, so that's some subtle difference here, so you need to put. We need to provide a procedure with the implementation, with the sequence number as a part of key. Yes in the future. That's the past, on sequence.

F

Number cannot be part of the key, but today, based on the draft, there is some implementation. Has the sequence number as a route key? Essentially, we will have the same route type today with the sequence number as a key and some implementation without the sequence number, so the same route. Now you have a two route key. We need to deal with this situation in the first of a way. Future. Yes, sequence number can be removed with not be part of key once everybody is upgraded.

R

So um may I comment yeah sure early so.

R

We moved this field to the reserve, so the draft, uh the new version of the giraffe, is intended to say. The field is reserved so when the field is reserved and we're going to be saying that the sender needs to set it to the zero and the receiver to ignore it.

R

If it is reserved and then we um have it uh does it make sense to have it as part of the key. If the field is reserved.

F

um In the future, when it's reserved, that's uh not a part of key, I agree that that's the ultimate goal. We are on the same page, that's the goal. We need to go with that. Yes, so in.

R

The in the short term for your implementation that you put it as part of the key okay you're setting it as zero right I mean the fields are zero. Currently, because it's not being used, are you setting it to a different value? Yeah.

F

So ari this is, uh I hear what you said. Please hear me out this: I'm not trying to make it difficult because we are all facing the reality right. So uh this is uh evpn is a very popular technology now so, even though people come to the best managers to express what they think or what they have done, not every vendor speak up right. Every vendor's implemented that it's because evpn is improving by more than four vendors right. So so I'm just afraid.

F

If, as a vendor, we don't know what they do, they will follow um just a practically. They may follow what has been written in the draft, so that is the.

R

The whole yeah I mean for these changes, and um you know all the exchanges over the mailing lists take into account what has been implemented, what the situation is and to come up with a reasonable solution that uh that.

R

Satisfies most of the requirement, and if we took the uh you know, based on the current situation of the vendor implementation and in my email that I sent last night, I said we can hold the vendors again to see where we are okay, we have uh one vendors that has implemented it with the uh with this field, with the existing format view vendor and one vendor, and that is your vendor.

R

My vendor implemented it without and a couple of you know, few vendors uh have implemented the video both and then the other vendors, which I know they. Basically they haven't implemented it. So, based on this situation, we took you know um in terms of the uh changes I saw. Okay, uh we're gonna, cisco, is gonna, bite the bullet and we're to change our uh implementation to remove the field uh for the.

R

uh For the sake of that, we have the least uh amount of the changes to the other vendors and for the sake of having the lease uh having the easiest solution.

R

So based on that, we want to just simply capture it as a reserve field and say that this is not part of the rocky and if it is, if the fields are zero, it doesn't matter to be part of the round key or not. It doesn't makes that much of the difference and we can pull it and see if there is any uh vendors that uh if there is any vendors out there, that uh is setting it to the non-zero field or uh not to the or to a non-constant field.

E

Ac in queue.

F

So may I actually have to I guess I.

S

Guess I don't see this ac limbo from cisco? I guess I don't see how internally using it a key is a problem on bless. Somebody implements advertises multiple instances with different sequence numbers and doesn't want the later one to update the former one. It seems like you know. People said the sequence numbers didn't didn't, have really any uh functional value, so it doesn't seem like the internal usage of a key would make any difference to me.

F

Yeah, I agree on that. If there is.

S

Much to do about nothing, that's a moot point. You know you don't have to change anything.

R

And that's my point because it is a constant value as long as it is constant value, it doesn't matter yeah.

F

I agree with that. If every as a vendor, which I mean the vendor, has not speak up, they have always a constant to make it then that's not a problem. I do agree with that. So as long as that's the truth, then no problem, yes and.

R

So that was my point and I'm saying that, based on that, we can go with the text that we talked about is going to regulate it as a reserve. Okay, uh we're going to make it reserve it's going to be set to zero in this thunder. uh Receiver ignores it and if they send their accessory that as a in a constant, it doesn't matter in terms of the rod key and it's gonna get ignored by the receiver.

E

Anyway, I think we'll take one last comment from jacob. Then we'll have to take it list. We also have jeff as.

B

I think in the queue.

A

um It's it's ignored on receipt when you ignore it, you're not going to use it as a key. Are you because if you use it as a key you're, not ignoring it, and so that's the first point. Second thing is: if in future it indeed does get used, then we can redefine what we're going to use it for and whether or not it will be used as a key but you're ignoring it, and if you put in it, if you put it easily as a key you're, not ignoring it.

E

uh I I don't see jeff's name but yeah stephen. You said.

B

E

B

It in the chat, jeff.

C

Asked did you want to say something briefly.

I

Sorry I didn't post it globally, just the teacher, um I I think the main point they take from when uh is that I agree with everybody as long as everybody's setting zero, then there's basically zero interop issue. uh I believe when's indirect point is that when we craft our text talking about this field being reserved, it's probably we're throwing in a sentence. Maybe two that says you know this needs to be zero, because some implement early implementations use this as part of the key and it's for interrupt purposes.

I

I think, if that's done, I think all of our concerns are addressed. I'm.

R

Sorry jeff, can you please repeat it.

I

I believe part of wen's point is that, since some implications treat this as the key as long as all implementations are sending zero, we agree that we are all set.

I

It is probably worth putting into the next version of the draft one, maybe two sentences that explain that we want it to be zero because some early implementations treated this is a key field and that it may cause interrupt issues. If they do not. That's it.

R

F

Thank you, jeff, that's what I mean thanks if.

R

That's okay! That's perfect!.

E

Thanks everyone.

R

I think uh just uh one other thing uh do we have john uh on the call still, if john is on the call I'd like to ask him for the sake of other people uh that who are not on this call. uh John respond to the email which I sent last night, making sure that everybody is on the same page.

Q

uh I didn't catch everything you just said. I'm sorry.

R

John, uh some, not all people are on this phone so for the sake of the people who are not on the call, if you can respond to the email that they sent last night, and you know making sure that it is clear to everybody, the approach that we are taking.

Q

Sure I'll go and take a look for it all right. Thanks.

B

Okay, I don't think there are any other comments on this draft, so I don't know if again you are still with us or not.

E

B

That he is he's back.

B

E

Again, you are mute because he did the text saying that.

E

Okay, so last call jan, are you with us, so he did text me saying that. Can you hear me, jan, we can't hear you.

B

Okay, we we just have five minutes left, so if we come to, um if we can't hear you, uh we will probably close the meeting so he's dialing from phone. If we can give him a minute.

E

Okay, yeah yeah: you can go ahead, dial from phone.

E

C

B

Hello, jan, can you hear us.

E

Your voice is too loud new. Please come near mike.

M

That sound better.

B

M

How does that sound.

B

Oh okay: okay, let's try! uh Let's try this way. Unfortunately, you just have five.

M

Q

Anybody else hear the speaker, because I can't.

B

Hey jim, are you still with us.

B

I'm sorry, we can't hear you.

I

He is there he's just extremely quiet.

A

I can hear him very, very faint and I can not hear everywhere, get closer to the mic or uh or or move the wiggle. The connections originally.

Q

So much better, except you seem to have.

M

Open mics, how's.

Q

L

I see I see that.

Q

Yeah you gotta both mute the mic and turn off the uh the speak um on the device that you're not talking into yeah. Let me try.

M

M

Cal, can you hear it? Can you hear me.

B

Yeah, that's still.

M

Something hello is that better.

C

M

C

M

C

M

Looks like a slight.

J

P

M

Okay, I'm gonna go ahead and proceed; okay, okay, so so so! Basically in this draft, I.

N

Think what we're.

M

N

M

Being able to um I use rfc 5549.49, I'm encoding to advertise the ipv4 and lri.

M

Sorry, the echo is pretty bad.

B

So, do you have two speakers that you are currently.

B

M

Hello, hello, sorry!

M

So so, with this draft, I guess the proposal is, I guess, or the idea is really to be able to um advertise. The ipv4 enter right with the ipv6 next top, so being able to uh do that on the court on the edges primarily and using the software mesh framework in rfc. 5565 uh tunneling sticks over four.

M

um So with that, it's something similar to what we've done with um with six over four, but now now doing that over a um four over six software um and with that being able to um utilize the bgp transport as a as a as a ability to um advertise.

J

Both capabilities, so the four and six capability.

M

uh So you so we can eliminate the um you know possibly eliminate like four ipv4 appearing, so you can carry gold four and six hundred families over the one pier I mean that's kind of really the the main crux of it in terms of the um rfc 5565 like tunneling six over four, and that's what we've done today, uh but with um with v6 and I'm having a v6 core and um having uh four over six. I guess overlay um being able to um kind of.

M

I could do the same and advert and um um be able to uh advertise the same capabilities over the um over the sixth core.

M

M

So so with this, so with this uh I would with the uh four over six transport. uh What we're able to do is it's it's similar to what's done with um a six over four transport, but but now with um four over six you're. Actually, you have your your peering to the uh from the pe to the raw reflector.

M

It is uh you have your uh your saffies, so your type, sorry vpn v4, uh mvpn, um that the address families are over are now with um uh ipv5, so ipv4 over with an ipv6 next hop encoding for our rc 5549 encoding as far as gain uh the big gain is really on the edges, where, where you're able to use bgp of the transport and actually provide the same four and six capability over the over a single, pier, please go on to the next slide.

M

So this is this basically showing kind of it, so an issue that came up and it was like a um in a um in a presentation with uh indiana. I guess 2015 related to ixps address space depletion uh on on the uh exchange points. Where uh ipv4, um you know you know, address space was being depleted and an idea was to actually use that capability and advertise build four and six um capabilities over the peering session um so as to eliminate the four appearing.

M

So you could just really have one peter, so a single pier on the edge next slide.

M

So with that, so what that would look like is you would actually have a single pier would be a single v6p or so similar to how we do, let's say, with our p, to route reflector appear and where we stack all the saffies. We're now like we're now taking the um these v6 enter and v. Sorry, the v4 and lri and advertising that capability over the 6p as well. So so now, both four and six prefixes nlri are advertised and now you're, using that same v6 next hop for both four and six.

M

um What this does? Is it really? And it's really for enterprises and service providers, you're able to uh eliminate uh v4 peering at the edge, and that's that's really the the big gain with this draft and possible, like opex savings and managing your uh your v6 peering before appearing at the edge um next next slide.

M

So this is a typical uh v4 core and this is like six or six over four. So here you have all the address: families southies like uh v4, v6, v6 and they're. All uh the saffies are over a four pier.

M

um So this is a typical six to four uh software framework where you're tunneling these six five, six graphics of uh vpn, v6 and mvpn over a four or four uh next next slide.

M

Next slide, sorry that slides okay! So so in this slide, this is kind of existing as well. So this is uh takes with with ipv4 I I ipv6 islands over an ipv64, and here we actually have ipv6 nri with ipv4 next top, where you're doing you're using a bgplu for 6pe labeling, your v6 prefixes, with a v4 next top using that same rfc, 5549 encoding for the next top next slide.

M

Next slide, yes, so this sorry! So um so this is a v6 core. So now this is with the software mesh framework, with four over us over a six core with vpn and in this in this scenario, we're taking all the saffies and so on the pe to rr peering. All the saffies are carried so in here.

M

There's the gain here is um it's: it's still the same as going up six over a four core, but now it's four over six quart, so you you just are lit um at keeping all the same the same saffies, but now over a six next top. So you have all your ipv4 and v6 enter and over an ipv6 desktop.

M

um But then, when you look at the edges on the pc edges, customer that that's where really the major gain is with this raft and the opex savings impossible, you know management savings where you're able to eliminate your v4 peering by advertising. Your um your uh four capability over over that same six peers. So both four and six and lri are advertised over the peers and that's and that's really at the edges of the network where, where now you have that um address savings for v4 and everything can be completely v6, go to the next.

M

M

So this is actually the island scenario, so it's the same uh scenario that we have with 6p, but with four, so this is actually going, but with a soft wire, a mesh framework, four over six core, where your um your v4, um your v, your v4 and lri, is now it is now um lit, is uh bgplu, so it's uh labeled unicast over over six core tunneled with the um software mesh framework, um but in this case as well.

M

So that's that's it very similar to the six to four with six p, but now we're just going over of four over six core. So in this as well. Basically, the same savings is uh on the pc edge, where we can now really eliminate your for peering. um So this this use case is really for both. So this this one and the previous one uh with the service provider or an enterprise, whether you're doing 6pe or vpnv4, vpn v6 and the core, the quarter side doesn't change as much and it doesn't change.

M

Did you have the same number of safies of over a v6 pier with your p to r appearing, but really the big gain is actually at the edge? And that's where you know your bgp transport you're advertising the four capability over the uh six pier um with with the v6 next top for rc5549 and now and now you're able to really eliminate all of your.

P

M

Appearing so any any questions or.

E

B

With uh with the meeting, um so we don't know yet if we will see each other now in madrid, it will depend on the country, conditions and so on, but um in case there is no meeting in spain. We will organize another interim meeting thanks a lot and if you haven't signed the blue sheet on etherpad, please please do it.

B

B