Internet Engineering Task Force 109, 19 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF109-BESS-20201119-0900

Description

BESS meeting session at IETF109
2020/11/19 0900

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

A

A

B

Hey my commander, I think stefan's still.

B

A

A

Matthew, I think you have to start a stephen, has some issue with his mic.

B

Okay um right: well, you have to he's he's displaying us at the moment, so stefan, if you can, if you can move to the next slide when I need to so welcome to the best working group um here is the note. Well, um if you just uh look at that for a second, this is basically says anything that you say uh here is contribution to the itf.

B

B

Okay, so you're in miniteco, which is a great start. um If you would like to speak, please join the queue and the chairs will manage the queue, but wait for your name to be called and then I'll meet yourself. Please.

B

Okay, so um rfc 7432 bis, so this is an open action um that we've had for about a year now, um there's a presentation on it on the agenda at this ietf chairs have discussed this and we intend to publish just directly as a working group document if the working group has no objection to that. um Seeing as this is on our uh our work to-do list um to do this update to an existing rfc I'll just give a second. If anybody has any any concerns of that, please jump in the queue now.

B

See anyone in the queue so thank you. Stefan next slide. Please status update, so um rfc's published since the last itf haven't published any. um We have four documents in the rfc: editor's queue: evpn overlay, dci, vpn overlay, um epm, prefix advertisement, uh an shbgp control plane and the revision of rsc 5549.

B

There are quite a few drafts currently with martin or in iesg review.

B

So the cno flags draft in subnet forwarding optimized ir proxy arp and open discovery. um There are one procedure updates um the oem requirements framework for evpn and then the dc gateway draft as well.

B

Next slide, please, um a number of documents are currently in our queue for being reviewed by the the shepherds. So my commander's reviewing the irb multicast draft um awaiting comments. um Do you want to say anything about that.

A

Mankind yeah, so I have I have finished reading about uh most of this document and I'll be sending comments to authors soon and I'll come up with the write-up as well.

B

Okay, um the uh the unequal low balancing draft. um We need another short working group call for that: um the the evpn virtual ethernet segment document, the write-up is done. I mean there's some follow-up going on with between luke and the authors, um the vpn preference df. Stefan is following up on that and the igmpm ldp proxy.

B

Oh stefan sooner yes, we can hear you hi. Stefan.

B

Okay, no did you want to say something: okay, um the igmpm ldp proxy um we're expecting a new version of that to be submitted as soon as the gates are open.

B

Stefan do you want to take over it's gone again. Ongoing polls. um There was a um a poll for evpn lspp. um We had some comments from laura. I think it was regarding the iron section on that, um so this needs to. We think this needs to be updated um before we can close close the poll um and check with uh with lara as well for the the updated section.

B

We also need to need a poll on that to address the issue of implementation, so I don't think we had any replies about whether anybody had actually implemented this, so we're going to need to do an explicit implementation poll or an explicit poll to check if the working group is okay. Given our policy for only publishing standards track documents with implementation, um at least one implementation, um so we will, we will check. The working group is is okay with that um we have an ongoing working group last call on the ipvpn interworking draft.

B

Stefan next slide: please: okay, ready for last call srv6 services, uh so these are in our queue, we'll we we, we will likely start a working group last call for these shortly, um so it's v6 services, the e3n evpn aggregation label, the irb extended mobility draft, which has a couple of dependencies on other other documents that might hold it up next slide.

B

Our working group documents, so the um df election draft uh multicast uh deaf election draft, um so we've got a new update that is likely to be posted.

B

um We expect this to be ready for working group last call um for the next ietf, um and this is planned to be presented at this ietf um to get more comments on the draft. So you should should see that on the agenda, um the first df recovery draft there's no update to that um and we're following up with the authors.

C

Luke hi uh just for the fast df recovery. We did do an update sometime last spring and um I actually went and got some ina code points allocated. So uh maybe I can present that one at the next idea, or or even at least, if there's a lost column.

B

Great okay, thank you.

B

Next slide, stefan um so we haven't had any updates for this list of drafts.

B

B

Inside and we have some new working group documents that we've recently adopted, so the um the vpn martial and split horizon was adopted in october.

B

The bgps2n usage draft adopted in july and evpn srp 2mp, was adopted in november next slide.

B

um A couple of other documents that are probably ready for working group adoption um draft preset uh best evpn l2 gateway protocol and draft mohan tvs, weighted hrw.

B

Okay, so here is the agenda. I just realized. We didn't do an agenda bash um at the start, so any comments on the agenda.

B

While we're waiting for the first light to come up, so I think the first one up is luke andre.

A

It will be the gun.

D

Here, can you hear me yep? Okay, all right, so this draft um ipv4 nlri over an ipv6 next top, so this disk draft utilizes the rxc 5549 um ipv6 next stop encoding scheme. um So we have the authors, myself, manik mon mishra, with cisco jeff tensura with abstra, and we have a new new member to the draft from juniper that has recently joined lilly wang.

D

So um with this draft uh overall, we've made some good progress um as far as um some internal in intermediate, like interoperability, uh just uh support of the rfc 5549 next top encoding related to ebgp pairing sessions and really the goal of this draft is to test the interoperability as well as first determine whether it's supported the feature and functionality that everything's fully functional- um and you know with with some of the bigger vendors like like so so far in in the group of vendors that we have so far. uh We have cisco uh juniper.

D

We have arista as well as uh nokia and we're also trying to get away on board as well. So that would be like really the top five vendors that we're looking at doing the interoperability testing of this um next slide.

D

Thanks so um just an overview of this draft, so what what this draft does? Is it utilizes the um ipv4 next top topic, next type encoding, ipv4 uh nlri uh over and over an ipv6 next top here, um that's been used um very similar to what's been around, for you know decades where you have a v4 edge or v6 edge over a v4 core and your pedo are appearing in ibgb puri is uh where you're encoding your v4 v6 andori over over a v4 next hop.

D

So, similarly to that uh with with rfc 5549, we're kind of doing the doing the reverse, we're taking a v4 edge and we're encoding over over a v6 next top. So with that uh what this does, is it's utilizing that same peering? That we've that's been done?

D

You know for a long time, you know with it with a uh four edge, a six sorry, a six edge over four chord, now we're doing a four edge over a six core, but utilizing that same concept for your pc, peering, so you're, edge, peering and, and the reason behind that is.

D

It really allows us to eliminate all of our dual stacking that we have at the edge, and that's that's like the really the massive gain with this that we're able to treat the uh just as we you know, stack sapphies on our p to r appearing where you, where you have um your your uh vpn, v4, vpn, v6 and and many other safety's that are stacked in your p2r appearing. Similarly, what we're doing is we're actually using that v6p or that single pier to transport.

D

So now we're able to transport the v4 enter nlri over and over the v6 next hop, um thereby eliminating that fury um as far as this the savings it goes, you really from an ipv4 address, depletion perspective. You really uh that that's really a really huge major gain and, as far as address address planning as well for ipv4, um the other big gain is opex. Savings in terms of monitoring appears from an nms perspective, and that kind of yang perspective that now you have.

D

Basically, you cut down your peers in half, so you don't have all the dual stacking and edge peering we're not now you really are able to there's really across the board that just would apply to really anywhere whether it's a core data center, any type of infrastructure that you have wherever you have dual stack peering you can keep the concentration of dual stacking. If word exists, keep it. You know consolidated toward the edge at the customer edge, but on the peering points from the customer to the core that that can be purely v6.

D

Only so that's that's! Really. The big major game next slide.

D

D

Yeah there you go, that's good, that's good right there, so this is current, so this is a a depiction of a typical like ixp, peering nap, where, where you could have you know really, you know gain your really tremendous games where you have, let's say a massive ixp nap, where you have thousands of peering points where you wear gold stacked, and so you have separate v4 and v6 piers.

D

So here you can see you have you have uh you have separate peers um and you're carrying your v4 pure, is carrying your v4 and lri, and your v6 pure is carrying your v6 and lri next slide.

D

So what with this with this encoding scheme, what ends up happening is now instead of having two separate piers, you have a single pier, so it's a single v6, pier and you can see like at the top in red the uh next hop so you're carrying the um nlri, let's say 192.1. I want to do that. Slash 24.! The next top is a v6 next top, so you have that single v6 pier and it's carrying both the v4 and lri, as well as the v6 and lri.

D

um As far as um operational considerations, when that happens, um they should be should be minimal. The one thing that you know that does exist. You do have it's a single. This is you have a single physical interface, um so you would have because it said it's not dual stacked anymore. You would not have two separate bgp session, a b, sorry bfd sessions, so you would have a single bfd session. That should not be an issue I mean, as as it is a single physical.

D

You know, let's say a fiber, so if a fiber cut happened or a link went down, you'd lose both peers anyways, but it's it's. So I think, from that's perspective from the layer one there to perspective, uh whether you have two peers or one peers it does. It doesn't really matter from. From that perspective um from a, uh I guess, a learning curve or operations support perspective.

D

What does change is that now, instead of having two physical peers now you do have one peer. So with that peer, the configuration from a routing perspective, there's really there's really no change. The policy is applied at the address family layer. So your your your routing policy that exists separately, let's say uh on a separate, v4p or v6 pier now it's on it's on a v6 pier, but you still have your same separate v4 routing policy.

D

D

So this this depicts uh the typical core that that exists. You know from you know from you know, for many years I guess- and this is like go showing a v4 edge. Sorry, these a dual stacked edge going over v4 core uh peed are appearing. So what I was describing earlier, where you have a uh these, you have a v6 edge, so you're doing v6 nlri over a v4 next top, so you're doing a v4 next top encoding and in this case you're you're carrying um you, said you're carrying a v6 over v4 nlri orion.

D

This is global table routing you're, doing six pe, so bgp uh labeled, unicast 6pe. Next next slide.

D

So in this and this um sorry there you go so in this scenario, so this is a service provider core where you're, where you have um you, have your dual stacked at the core at the edge, but now you're you're doing this similar thing. This has existed. You know for decades as well that you're you're also doing like what I show in red there that you're doing uh you have v6 over a b4 next hop. So your p to r appearing that's a v4 peter. So this has existed for for years.

D

You know, and it's it's really common practice that you have. You have a v4, pier and you're, carrying your your v6 and lri over v4 next hop next slide.

D

So this this scenario is showing a global, a global table, routing scenario. So here you have, you could have in the core. It could be it's a six core, so it could be either ldp v6, srm, pls, v6 or srv6, and you know so with the software mesh framework. From that perspective, our c-2565, you have a you, have a um a a four and four edge over a six core, and here your your p e two rr appearing.

D

You have um you're running like four pe, so you have the ipv4, nlr and lri over an ipv6, next top, um so you're doing labeled bgp label to unicast 4p, similar to 6pe, but you're carrying your um you're, carrying your v4 late labeled unicast over a v6 next up here um and then, as you can see, on the on in the pc connection. Here, it's a single pier!

D

So here you have your uh your your your uh a fee. Two slash one is carrying your green one, slash one! So your v4, pure um affi, is basically stacked on top of your v6 transport, carrying both uh both address formats. Next slide.

D

So this is a service provider core perspective, where you have the vpn overlay, so similar, six, six core, so mpls like ldp, v6, srv6 or srm pls v6, and then you have um on on your pdr appearing. You have vpn v4 carried over v6 next top ipv6 next up when your p to r appearing, and then you hear your p e c e p airing- and this is where the where the major gain is that now we can eliminate all of our v6 or dual stack.

D

Peering save all that v6 their v4 address under space at the edge and completely eliminate that and just make the entire edge completely e6. Only so carrying both the uh the v4 address family over the um v6. Next stop.

B

Go and you have one minute, please: okay,.

D

Next slide, so, as I mentioned at the very very beginning, we have made some good progress, um the four vendors so far that we that have contacted uh been as we have cis we have monica mitchell with cisco uh and then uh with juniper.

D

We have um lily wang and then with nokia and aristo, we're I've contacted them, we're working on getting some getting some contact information for the interoperability testing, but we have made some really good headway. So far, um the three of the five vendors in total that we're looking at um they do support the ebgp pdc pairing with a single pier, and they do see the you know the major advantage in doing this, so um I think we're probably getting close to um um workgroup adoption. I think, but I want to get some feedback.

D

I guess from folks on on bez uh to see what everyone's thoughts are on this. So I'd like to open up for anyone has any questions or comments or anything related to this draft. Thank you.

B

Thanks god, I I I don't see anyone in the queue we're very tight on time. All right, one, I see go ahead.

E

Ac ac, lindem cisco. Can you hear me yes,.

F

E

Okay, uh it'd be good now that we've got the 55 49 bits to indicate uh compliance with that as well. In your testing.

D

Yes, definitely definitely so will, as part of the testing will definitely be testing that that the updated this you know with the next hop encoding. Yes, yep, we will incorporate that into the testing.

D

Okay, thank you, hd, any any comments or, like you know like with, with overall with the games or any any comments. Yes,.

B

Okay, no thanks. uh Thank you very much. Thank you. uh If you can uh folks can review the draft and send some comments to this that'll be good. Thank you. Thank you. Okay. So next is luke andre.

C

uh Yeah hi um so I'll be presenting a brief overview of the updates since uh version one.

C

um So the div tool between o1 and o2 shows uh quite a few uh fixes for consistency and uh just changes of an editorial nature, changes across references, etc.

C

um One of the major updates between o1 and o2 is a new section that was added to clarify the terminology between what a normalized vid is and service identifiers, so bpws service, identifiers and and sort of serves to disambiguate between the two terms.

C

After that yeah, so there was. um This draft also proposes uh to extend the evpn layer to attribute extended community uh by two new fields.

C

The the version two of this draft addresses um field alignment issues in the definition of the extension to that extended community, and uh also we updated the ina section to uh to actually request allocation of the two new uh fields.

C

C

Slide so in a second step, there's there's also a clarification. That's added in um in zero, two for the two fields, the mode uh bits and the vid normalization bits and on how the the two proposed fields uh operate.

C

um So a new uh a whole new section is added with uh so with more precise language for air conditions and usage of the the v flag, especially so, while the the v flag for uh for vid normalization is optional.

C

uh If this field is signaled, uh the new section details how, if and when this field is signaled and the mismatch is detected, uh that represents a serious error error in the data plane uh in divide encapsulations on the sending and receiving key.

C

So uh the section addresses how that mismatch needs to operate uh to prevent tunnel instantiation, not just raise an alarm the um the operational mode, so the m uh flags or fields, sorry, uh is maintained as optional and error notification. Only uh rationale for that field, uh so other next steps for this draft. uh It's it is an implemented draft. It does show good adoption, uh so we would like to see some more review and comments on it.

C

I've received one already on the v02 version, so there will be a small update, but eventually this draft is ready to move through the working group and his last call already.

C

And that is the short update.

B

Okay, thank you. Let's see anyone in the queue uh so next. uh Thank you so much.

A

So, hey guys we'll give a brief update about the power flow, dflx and drop, so we can go to the next slide.

A

So this is just a problem statement recap because it has been quite long. We spoke about this particular draft, so this graph defines a new df election mechanism and why exactly? It is needed. So right now we have a couple of deflection procedures. One is default df election procedure, which is defined in 7432, which is nothing but evi, esi and df election and the other df election mechanisms are when we use hrw algorithm to distribute df among multiple ps in the multiple scenario.

A

But we had. There are a couple of customers who wants to use evpn, multi homing and the whole multicast services on a single vlan. So if we have such scenario in that case always there is only one p who is going to be a dm? It means that the whole multicast traffic is going to get carried or get powered by your one of the pe.

A

So it even though we do say that it is operating in all active multi moving, but we are not utilizing the other link at all. So that is where this new mechanism comes and the picture where we are going to have proper flow df election. So stephen, we can go to the next slide.

A

So in this scheme, what is going to happen so by default, when we, when evpn service is configured, we are going to have a default df election which will set up their state that one of them will be the df and other guy is non-df, for example, in this, p1 is in the df state, and pe 2 is non df state. So reason why we have a default df election being done is for your broadcast and unknown unicast traffic and what happens that when we get a first join.

A

So let's consider the red join when which is for sg1.

A

So when join reaches to pe 2, we have ignp proxy procedures to synchronize this joint to p2, and at this point of time, for this particular flow, we are going to have a df election performed and this df will be providing a state for this particular flow. So in this case p1 becomes non df and pe 2 becomes df when the next join comes next join again will go over exact, same df election procedure and appropriate df.

A

Appropriate pe will take over as a df. So in this example, we have sg2 where p1 comes at df and p2 becomes non non-df.

A

The procedure which is being used is extension of hrw, so earlier, hrw was considering input as only evi and esi, and now we are, we have extended it to consider even source and grow, and that gives us a flexibility where each flow will be distributed among multi-home peer.

A

Next slide: okay, so this draft has been already implemented and it is deployed, and uh we would like to get more comment from working group and we plan to have uh last call before next ietf.

A

There is any question.

A

I think we can go to the next here, so ac, aware, bundling service interface. It was a new interface defined for evpn services and we did present this two years back in iitf, bangkok and the reason for presenting it back is. We are going to basically spend time and uh move forward with this drop in before next ietf, so I just wanted to kind of go over it and there have been some comments uh received from harvey and luke andre, which will be addressed in the next revision. So it is for this idea.

A

It is just we are going over the same slide deck to make sure that the whole working group is aware, and if there are any comments we can take them. So the requirement is very simple that there are certain deployments where we want to have multiple subnets within a single bridge domain and each subnet will be distinguished by the vlan in the bridge domain.

A

So 7432 defines three types of service interfaces and each each of those service interfaces are addressing different requirement, but none of them actually are going to provide a mechanism where we can have multiple subnet. In single bridge domain, so in vlan based service interfaces, we have one to one mapping between bridge domain and a subnet.

A

Our our evas in the vlan bundle service interfaces. We have each evpn instance do correspond to multiple vlans, but the bridge table is going to be single bridge table and when we do mac address lookup we will we might address. Lookup mac address is the key for the lookup and encapsulate packet will be remain encapsulated in the originating vlan id and vlan aware bundle service interface. It does provide a mechanism where multiple vlans can be con will be part of multiple bridge to a multiple bridge table.

A

So, basically, when we map any, when we look for any mac, plus we land or learn lookup will be based on mac plus vlan id and either these service interfaces are not going to provide a mechanism where your you have multiple subnets in same bridge table and they are pointing to a single irb or single dish image table here we can go to the next slide.

A

So in this example, we are talking about a bridge domain which is being shown by yellow color here, and there are three different subnets and they're they're part of a single uh irb interface. So in this case e1 and p2 they are multi-home appear and p3 is the remote pair.

A

So right right now what is going to happen that when p1 originates a macro, p3 needs to create an entry where the next hop could be either p1 or e2.

A

We need a way to identify that which, which subnet this mac belongs to so today, when, if we use any of the service interfaces which is defined in 7432, it is not going to carry any information which can provide information to p2, about which exactly subnet are vlan. This host h1 belongs to so when packet has to be sent out of p2 for host h1. Well, pu has no clue which vlan should be put on. This particular data belongs to the mac h1 mega h1 next slide.

A

So ac, where bundling service interface, is going to address this particular requirement and to address this requirement. What is going to happen that we are going to carry a circuit id our attachment circuit id along with the routes, whether it is macro or multicast routes, and the reason why this is applicable even for a multicast route, because when we are, we are syncing igmk joins.

A

We need to make sure that we do carry which ac this join has come from, so that when you are creating a following state for multicast in the smoking, appropriate ac can be picked, and this attachment circuit is going to be attachment. Circuit will be useful only for the multi-home tier and it must be ignored by the non-multi-home pair or any remote side.

A

A

So, with respect to control plane operations, when pe learns mac address it, it is going to it must attach a attachment circuit, extended community to the mac route and when it receives a igp join, it must attach attachment circuit to a multicast route, which is which is route type, seven and eight on the remote side handling.

A

When this mac route is being received by non-multi-homing peer, it must process macro, as it does today defined in 7432, but it is going to uh ignore the attachment circuit extended community, and if it is a multi-home tier, then it must get which ac, which we land. This this particular background belongs to and even with respect to multicast throughout again, it is only for the multiple pf and anywhere route. 7 is supposed to be processed by multi-home beer itself, and it is going to get appropriate in crs subnet.

A

Based on that circuit.

B

Manager can you can you wrap up, please, I think you're kind of out of time.

B

A

So there is no data plane uh change for non-multi-home peer it. It is going to be exactly same as 7432 yeah. We can go to the next slide.

A

So so, right now, uh when data is received, it does follow from the ce point of view. It does follow the same procedure as 7432, so only a new change with this will be when you are, we are receiving the data and we are going to forward now. The mac address mac address lookup is going to provide you, the port plus which vlan it has to go out on, so that appropriate wheel and tag can be pushed and multicast packets will be forwarded based on whatever multicast state overflow state has been built in next slide.

A

So there is already implementation with cisco and we are working across other vendors also, and we have from the last presentation. We have added nokia and juniper as well in this draft, and we will look for any other comments which working group may potentially have, and there will be a request for adoption call before next ietu.

A

B

Okay, there's one one comment from: uh could you uh make a comment? Please hello,.

G

Can you hear me yeah yeah? I went from juniper, so I have a two question about the ac bundle aware service. So one thing is how we deal with a broadcast traffic. If a ps3 sender, broadcast traffic does a p1p2 which is a multi-home, has a ac bundle interface?

G

Are they gonna? Do the yeah just uh maybe clarify in the draft? However? Yes, so it's still going to flood to the only medium based on the vegan right, not all the ac right.

A

G

Is that true? I would think that would be the case. It would be good to clarify in the draft secondary uh it mentioned on the remote p. Doesn't it does not need to pay attention to the new extended community?

G

But if you have uh inter-subnet traffic in the asymmetric irb case, what will be dividend it's gonna put on, so I think this uh scheme, the new service type introduced required. You have uh put vdn in the data packet once you have intercepted routing asymmetric irb.

G

It seems it does not know which video to put it on so please so maybe I'll respond.

A

That I have noted down the question and respond in the list because we are running out of time so.

B

Sure, okay, thank you.

B

B

B

Alrighty go ahead, hello.

H

C

Hello, hello, yeah. We can hear you.

I

Okay, all right, so this is a short presentation on the areas uh that we are uh addressing for uh rfc 7432, uh the uh area of improvements. It's been. This rfc has been around for almost 10 years as a result.

I

We've gained a lot of insight and experience into what are what are the areas that needs additional clarification, and there has been some errata on this draft and.

I

Almost all of them in the form of the clarification- and there have been also some other comments, with respect to the clarification and additional uh explanation that we are trying to incorporate into this uh draft into this bits, an extra slide. Please.

I

So the area of uh clarification improvements. You know, uh I've listed the uh main uh main areas in here: uh uh first errata that have been logged for these rfc and some of these uh some of the errata. It uh basically revolves around the roth label field, description across multiple evpn rounds and to basically clarify that the encoding is in the high order bit and some editorial fixes for the for that errata.

I

Then another area that needed clarification is the relationship between the mac, vrf bridge, table evi, bridge domain, vlan and vlan id. What are the relationship among them? So we added a section, along with the pe model diagram to to take care of this.

I

I

Another area is for the applicability of the layer to attribute extended community uh to the uh evpn service and to explicitly signal the control board, mtu size, primary and backup bits for a given ethernet segment, which we added a section to clarify this.

I

Then another section is on the uh priority handling of evpn robs and we have. uh uh We have three. Basically, we've categorized it into the three groups of the priority handling which I'll explain uh in the uh in uh later in these slides, and also clarification on the best path selection. When we uh advertise a mac ip route with a default gateway, extended community community and also.

I

I

Addition of the hobbies supporting the dcb allocated label for the esi and how we, as a result of that, how we handle multi-point to multi-point tunnel in evpn uh next slide. Please.

I

Next way, okay, so uh with respect to the relationship between mac verve bridge table evpn instance, british domain, vlan and vids, you know this uh pe model uh should help. uh It describes that the evpn instance gets instantiated uh with the corresponding mac verb on a pe, and the mac verb consists of one or more bridge tables and depend on the uh depending uh on the ethernet.

I

Ethernet interface mode, whether it is vlan based, vlan bundle or vlan aver bundle, you get either one bridge table or you get multiple bridge tables, then a vlan which is a bridge domain uh and expands.

I

You know across multiple uh pes that for that, given pe maps to a uh one of these uh to a one bridge table and uh that vlan can be associated with one or multiple vehicles, uh so uh this table, this uh figure and associated text tries to uh capture the relationship among them, and hopefully, uh uh you know, makes the relationship among these clear nexus. Why.

I

So the next slide is the text that goes with that pe model and uh uh I'm uh I'm not gonna, get into the detail of it, but uh it basically talks about if it is a vlan based mode. uh What would be the you know, the association between the evi and vlan uh and the british table and uh british domain uh what it should be and uh for vlan bundle and villeneuve bundle and so forth, so it make sure that, with respect to these different interface modes, it is uh these association and relationships are clear.

I

All right next slide.

I

Then we added a section on the l2 attribute x in the community, which this attribute is his extended community is already defined in our evp and vpws rfc, and it is being used there for, uh and it explains what the, uh how the uh primary and uh backup bids uh with respect to a single home, uh single uh uh uh uh uh single, active uh multi-homing, uh how the how these bits works and all that- and we extended that to here uh for the evpn service and uh we've also described how the flow label and control world can be signaled along with the mtu.

I

So we advertise this external community with uh along with chura swan, is imetra and then the other one is ether ad perivi route and uh in case of the imat route, uh we advertise it with the mtu control board and flow label fields and for the ether adipo api. We advertise it with the p and p bits, so we partition, basically different uh uh bits of this attribute- uh is convey uh with um with these two routes.

I

I

With respect to the control board, signaling 7432, basically doesn't you know it assumes that uh control ward? uh It is there if it is, we are doing uh deep packet inspection and if it is entropy label, then you don't use control board.

I

I

We've extended in here, and we say: okay, it can be signaled, and this table shows that what happens if there is a mismatch in the signaling of the control board and what happens when one pe signals it and the other pe doesn't acknowledge.

I

We make sure that we keep the backward compatibility with respect to the rfc 7432, so this table is there to make sure that is clear, uh nexus right. Okay,.

B

Alec you uh copy faster places.

I

Sure, uh evpn drought, priority handling, uh we divided the evpn drops into three groups for the priority handling.

I

uh The uh first group is, you know, uh of the lowest scale, with the highly convergence affecting uh routes and those are first priority, and then we have uh two other routes for the second priority: uh three rounds on the second priority and two other routes for the third priority. So uh this uh this is basically we prioritize the handling for better conversions uh nexus.

I

Right um best path, uh selection for default gateway is another clarification that is uh default, gate for irb interface, you advertise the mac and mac and ip address for an irb interface with the default gateway external community, and there can be you know, mishaps and misconfiguration, where you configure the same thing on a host, and we added the takes that if these species arises, how do we handle it and how do we take care of it?

I

And if there is such uh duplication, we need to basically uh give priority to the uh mac and ipa address on an irb interface as opposed to a host. So that section.

J

And you have to.

I

You have to conclude now I think I I'm up to the last slide. Next slide is the last one, uh so uh a few, a few other additional things, we're gonna, do it for the rev zero one and then finally slide. Let's go to the next one.

I

uh Next step we're going to publish this after this itf meeting, we want to uh solicit input and basically there is no uh rush for the working group last call in here. We want to make sure that all the stuff that we added here are fully baked and give everybody a lot of chance to read it. So we expect several itfs for doing this.

I

B

Any questions gee thanks thanks, okay donald's up next, please.

K

And there I'll uh see if I can feel under my time, uh donald east lake with uh future way- and uh this is an update on the status of the uh vpn vip draft next slide.

K

So uh basically provide never go, am layer, as described in the framework draft next slide.

K

So this is a diagram out of the framework graph, so you can see the different levels of oam uh service network, which is between pes, which is what this draft is mostly concerned with, and the transport and the link away on the various links that connect the boxes next slide.

K

Just talking briefly about the other layers, the link oam quest that whatever the link technology is, for example, ethernet, a popular link technology you can use 802.3.57 whose name is operations, administration, maintenance, oem transport depends on transport, you can use uh bfd and our icmp facebook panels.

K

Next slide and the service is essentially mostly end-to-end. uh The uh pes uh are, I need to be aware of it and use the connectivity fault management which is defined in ieee typically, so the peas must support the maintenance, intermediate point functions and they should support the endpoint functions you can do between cds or from the ce to pe next slide.

K

As I say, this draft of talking about is primarily on the network level oam. The next slide.

K

So it uses bfd, as you can just mode proactive fault detection.

K

um The current draft covers mpls and vxlan for unicast bomb traffic using multi-point to point and pump graphic using point-to-multipoint, so it does not consider packet loss or delay measurement and does not curve cover multi-point to multi-point next slide.

K

So the bfd discriminators are distributed using the bfd discriminator attribute, which is defined in the mvpn fast failover draft and those are attributed with the appropriate routes, depending on which type of traffic and so forth, you're. Looking at that's a fairly simple attribute, uh which basically provides the vfd discriminator and has some flags which are currently not no files are currently defined. For that attribute next slide.

K

So a lot of the text in the current raft and the diagrams related to specifying encapsulations, as used in these different cases as listed here um and it's but there's like some additional information, may need to be provided there concerning the kind of granularity you want to do the oam at since it's defined to be operable at different levels of granularity next slide and in the framework graph. The framework graph it talks about the regularity.

K

So specifically, changes from the previous version has a various initial specification of the routes in which you want to use this vfd discriminator attribute and how to handle withdrawals of those routes. As you know, as far as the bfd sessions go and the like, I added a reference to the draft mursky mpls p2mp bfd, which provides information on cases where the using the head notification without polling mode for the point of multi-point.

K

There are several different modes for point to multi-point uh and defined in the multiple tail uh documents and uh vfd multiple tail, and uh we it's current draft yeah that I'm talking about specifies that you would use uh some version which includes head notification.

K

uh So there's only one mode that doesn't in the three other modes that do include head notification, and this draft is now referenced, provides additional information on one of those modes. There were various ip addresses specified for the encapsulation. Those have been adjusted based on iesg feedback on other drafts, in the hopes to avoid future iesg problems, and there are miscellaneous editorial improvements.

K

K

So uh feature edition is possible uh information covering ppv vpn uh irb.

K

uh I think it may be useful to have an appendix that actually shows traceability from the requirements that are in the framework draft to the provisions that are in this draft to show that those requirements are are covered and one could conceivably add some information on other encapsulations next slide.

K

So I'm basically looking for requests uh requesting uh comments and suggestions, and I hope to uh progress this uh draft uh to a point where it could be uh working with last call then not too far into the future.

K

That's the presentation.

B

B

Ready so I do not hear you.

B

There seem to be two people in the queue. Yes, he just needs to unreach himself.

L

Okay, uh there's jeffrey from juniper one need comment. Instead of seeing him, maybe just go.

D

L

uh I need comments uh juniper from uh jeffrey, prince juniper, so.

J

L

Of saying mp2p um just uh just say: ingress replication, because, okay, you certainly have p2p for ingress replication.

K

uh Okay, well, it uses the phrase ingress replication, uh also in the draft, but mp2p is slightly shorter for slides. Maybe I don't.

B

Know: okay, any other comments. Okay,.

H

You hear me yes, yeah um yeah, um about the fallback team, for uh is it the intent to advertise the vfd discriminator with every single uh mac ip route in the broadcast main or only.

K

One one, as I say, I believe this draft does need some more work concerning the granularity of oam testing you're going to do so. This is the network layer which is between pes and you could just want to.

K

I don't think you want to test between pes if there's no routes between them, uh but as long as there's one you might want to just test one path. That would be the worst granularity.

K

If you want to, I believe, according to the framework draft you, you should be able to test several stages of granularity, including one which is much finer, but if you're doing more uh fine-grained testing, then you need uh to be able to distinguish the vfds for those different sessions that are testing those uh different fine-grained uh paths.

K

So, if you have any suggestions on um improvements for the draft along those lines, uh they'll be welcome.

H

Yeah I'll send some comments. uh The other request uh is to also include um ip multicast and the uh you know the advertisement of the discriminator, also with spmc ad routes for evpn.

K

uh Okay, I think perhaps you post some comments like that to the list would be ideal, so there everybody could see them and.

H

K

Thank you. Thank you.

B

Thanks uh next stop is linda.

M

Hey: okay, go ahead.

F

Oh, can people hear me okay, um so um this is um um we want to show that how the bgp is used to control the sd-wan. um The the purpose of this draft is to um demonstrate to other organizations.

F

For example, mef has two sd1 related projects and they do have bgp how to use bgp to control sd1, um but I think that bgp um is better for ietf to have the draft showing how we use them and so just give them a guideline. So the the draft itself is pretty simple straightforward.

F

um We have described the services and requirements and we listed several scenarios. Those scenarios are from sd1 project in math and then we show how bgp are used to for each of those scenarios, and then we show the traffic walkthrough. So this was adopted in july to the working group draft. We still would like to hear more feedbacks and comments next slide. Please.

F

So the the major changes. um um Basically, we reflect the um uh the latest um change in the tunnel in cap um 20 version 20, and we addressed the suggestion from the best amount list to use recursive lookup, the recursive lookup is described in the section 8 of the tunnel in cap, um and so here I'll just show some example. How do we use that next slide please?

F

So this is from the old version: the zero zero version showing that for the pgp update to reflect the attributes, especially for the ipsec attributes. um You have client routes and you have detailed attributes that episec related subjects which is described in a secure evpn. Next slide, please.

F

So this just to show. um If we use a recursive lookup, there will be two updates. The first update will have the client routes and with the next next hop to the loopback address and we use we tag the client route with the encapsulation extended community with the tunnel type, which can be episode or can be some existing tunnel supported and we use the color extended community and then the second update is to describe detailed attributes.

F

So an advantage of this kind of recursive lookup is to separate the ipsec property distribution from the client routes, because ipsec assay attributes have rekind process which need to be updated periodically.

F

So when separating them, you can reduce the package size of the bgp update next slide. Please.

F

This is also from the previous version in the st1 project. In math, they talk about different topologies. Some traffic can go through like blue topology. Some traffic can only go through the red topology, and, with this update, you can reflect that route different topologies. They call it segmentation sd1 segmentations next one please.

F

um This is just another illustration of using recursive look um recursive lookup, so for the blue topology, we have two updates. The first update is the client routes with the extended community specified as a tunnel type and then there's a color to specify the the attributes and then which is associated by the second update.

F

Similarly, for the red topology, we'll also have two updates next slide. Please.

F

So um here is the for the hybrid sd1, uh meaning that the underlay network can be mixed of different um um different underlay networks. uh You could have underlay being the internet provided by different isps and you could have underlay being the l3vpn so similarly using a recursive loop lookup, the first update is very simple: um we have the client routes we um actually we need a new um tunnel type.

F

We call it sd1, hybrid and then associate with the color and, in the second update, um we'll have a very detailed uh description attributes for these hybrid tunnels. So, very importantly, that for the like for sd1 for the ipsec, for example, ipsec is, I say, security association is always pairwise.

F

That means from cpu1 to cp2 that same port provided by isb2 like 170.0.0.1.

F

um Two different ipsecs are two different destinations so um because of the attributes can be a large amount of data, some of the ipsec security sas associations could be pre-configured.

F

So in this hybrid tunnel we could include a pre-configured ipsec assay identifiers, so you don't have to attach those attributes, and you can also include um hybrid underlay tunnels for like, for example, if the client route 10.1.1x can be contributed or can be carried by both elsewhere vpn and the internet, and just a side note, there's a draft in idr to describe a more um like optimized encoding for sd1 um hybrid. We call it sd1 nri and which will be discussed tomorrow at idr session next slide. Please.

N

You have less than two minutes to conclude.

F

Okay, now I just skipped this one. This was discussed last time. This is about the scoping of propagation um okay. So maybe I'll just stop here. um Next one is like encoding right. It's like very detailed. I hope people can read the document instead of me talking through this any questions. Any.

F

Suggestions, no, no questions no end here, because the the follow-up slides are two details to be discussed here. I don't think I have time for that.

B

Okay, yeah thank you linda, so if and if folks can review the draft and post comments to the list. Thank you.

B

So next is okay.

H

All right, this draft, it's about a pbb edp and I said, based cmac flash. uh This is the list of my authors.

H

um This is working group uh draft documentary and the idea is that it's um you know it's ready for uh last call and uh we should. uh We should make sure that we we get there. The you know the word time. uh Agenda short refreshed some history and some conclusions at the end. uh Next slide, please.

H

So what this is about is uh isaac based sigma flash for pbv evpn. um So in pvpn uh we still learn a c-max in the uh in the data plane right and they are subject to aging timers.

H

So whenever you have uh multi-homing- uh and you have physical or logical failures, you need to uh to send some cmac flash notifications so that the remote uh ps can actually flash the max and relearn again so rfc 7623, the pv vpn defines some cmac flash mechanisms, but um only for a single active multi-home ethernet segments, but not for other use cases like virtual ethernet segments or uh when you know the multi-homing is uh managed by the uh the ces like in in the case in the dragon, where you have a g80 32-axis networks or an active standby to the wires.

H

uh You know uh manageable from the ce. So what this draft introduces is a a generic ic based sigma flash that works with uh virtual ethernet segments, regular ethernet segments, and it uses what we call bmac ic updates with incremental sequence numbers. This is nothing else, but um a round type, two, with a b mac and d is it uh for which we want to flash the max encoded in the ethernet tag id field, and this is a backwards compatible with rfc 7623.

H

I should have say six, seven, six, two three and not 742 next slide, please.

H

So uh we started with this draft in 2016. uh It was developed over the uh the next few years. We had multiple revisions and, in the meantime, it was implemented and deployed in large pvp vpn networks.

H

Back in 2019, uh we had a discussion in the working group because there was an alternate icid based uh c-mac flash procedure in the virtual ethernet segment draft, but uh the the outcome of the discussions um was that we would uh standardize the cmak flash procedure in this document and remove the the procedure in the virtual ethernet segment draft and as a result of that, we adopted this document in october. 2019 next slide.

H

Please so what is new in this revision? So some terminology uh uh added a new section for just for terminology, uh some type of fixing and a general review uh with minor clarifications uh just to make it ready for last call next slide. Please.

H

So we believe it's ready for working group, let's call and it should progress as soon as possible.

H

So if you have any comments, welcome.

H

All right, if not.

H

All right, so the next one is about uh multicast source redundancy in evpn networks, so this is the uh I think it's the uh second or third time that we present this draft. uh This is the list of uh mike authors. uh Next slide.

H

So we'll we'll do a very short refresh since we presented this drop already in the past uh uh I'll focus on what we are adding in revision02 and we'll end up with some conclusions. Next slide, please.

H

So the role of this document is to define a solution for multicast redundancy in evpn networks uh and avoid any uh packet duplication that may happen as a result of that redundancy.

H

So it addresses the redundancy for multi-home sources, redundant, single home sources and also redundant multi-home sources, and it works for uh sources within the same broadcast domain or a different broadcast domain or a mix of both.

H

So we want to to cover all the all the potential cases, and uh so the packet duplication may happen, because the assumption here is that redundant sources are sourcing traffic for the same flow for the same multicast flow, and we define here a new concept, which is the single flow group, and this refers to a multicast group which represents traffic that contains only a single flow right and the multiple multiple sources may be transmitting the same sft and as a result when, when you have like in this diagram, you have a receiver 21 that is requesting to join.

H

uh You know star, comma g1 group. We don't want to have duplicate uh packets on on this receiver, so we need a way to avoid that next slide. Please.

H

So the draft defines uh two redundant solutions: uh the warm standby solution ws or the hot standby solution hs.

H

So the first one uh is interesting because uh it only requires the uh the um that you upgrade the upstream keys that are connected to the redundant sources, but not the rest is completely transparent to the downstream keys.

H

uh What this requires is is pretty much the uh upgrade and configuration of the upstream keys. So in this example uh that would be p1 and p2. You need to to configure uh the um you know what the sfg is and uh and where those uh you know, redundant sources for the sfg accessed, then, once you do that we signal the location of the the sources, the redundant sources. We use spmc80 routes, any vpn for that, and we include the eflection extended community and the special flag in the multicast uh flags.

H

So with with this deflection excellent community, uh we we run a what we call an sf election or a single forwarded election between the uh the upstream pes connected to the same sources, and uh so between them. They will select uh only one single forwarder.

H

So with that, as a result of this election, the upstream piece they will uh program some rpf checks right for the um the sfg so that the non-sf keys they will discard any receipt packets on on the local ac for the sfg and the sf. uh Pes will accept those, but only from one local ac.

H

So after that, basically um we receive. You know the sfg flow on the single forwarder pe, and I will forward that and the receivers will get a single copy of the sfg. So next slide. Please.

H

There was a need also for uh another solution that is hot standby and um the reason why we needed this is because we want to have a faster convergence.

H

The drawback of this solution, though, is it requires all the the ps to be upgraded, so not only the the upstream ps but also the downstream pes, but um other than that. uh Basically, the procedure is uh it's described here, so we need to configure the sfg and uh and the bds, uh the you know, the redundant sources are going to be attached to we.

H

We introduced some uh control plane extensions, so because, on the downstream piece we need to detect uh or um determine uh whether an you know a multicast flow is coming from a given source or another. We are.

H

We are including esi labels to to make that uh this tension, so those csi labels are um signaled in spmcad routes and uh and the other extension is that the a es esi routes, they must be uh domain wide block labels, because we need to make sure that the same esi label is used from the the two piece here for the same source. Right and uh and those esa labels are different on a per redundant source basis as well.

H

So that's that's why they must be pcb allocated labels so, uh based on that, we advertise those labels also on the aed per es routes, and we program rpf checks on the downstream keys so that we up on receiving uh you know the duplicate uh flows from the two sources: the tunnels, three keys. They they actually discard the packets coming from one source and they forward only the ones for the primary source for fall, detection and the change in the programming of the rpf check.

H

uh We rely on the uh advertisement and withdrawal the of the 80 routes, but uh bfd is possible too. So next slide. Please.

H

So what did we do? In revision02, some general uh cleanup uh with a type of fixing? uh We also improved the terminology section we added an optional use of bfd with the reference to the evp and bfd draft that was presented earlier.

H

So uh that's why I request it to the authors, or I will actually formally request to the authors of the vst draft to to include the uh the signaling of the vfd discriminator, along with the spmc aed routes, which is needed in this draft, and we also added some security considerations to the document next slide. Please.

H

So what we are requesting is working group adoption. We believe you know with uh we've worked quite a bit on this draft. We've presented it a couple of times and it's uh it's. You know it's ready for working group.

B

Adoption, thank you. Okay. Okay, so I have a couple of minutes for for any comments or questions.

B

I don't see anyone you know in the queue. Thank you. Thank you.

B

All right next is sammy hi. Can you hear me yes loud and clear? Thank you.

J

Okay, good good yeah, this draft uh is, uh as the name is showing here, is about elan services.

J

uh So it's the old, elan technology that we are all aware of, but uh I think here it's uh talking about. How can we can we provide uh the elan service uh in an optimized way benefiting from the new segment routing transport, so whatever segment routing transport is offering? How can we benefit from that to provide the overlay elan service uh uh in light of the new capability uh offered by segment routing?

J

So those are the list of answers uh that have contributed and co-authored the draft. So, as you see here uh so, let's move to the next slide, please so uh so the motivation here is: how can we provide the service, the elan service? uh That uh historically, of course started with uh uh sudhuar's?

J

If we are talking about zakur of the service provider network and we have started with vpls and zan later on, I came on evpn as well and has the history developed uh along to uh for the elan service and now uh with benefit of sr. How can we achieve some optimization for the offering so in general? The motivation here is more: uh how can we simplify uh control, plane and data plane and address as well?

J

Maybe some of the issues that historically was uh present uh with the sudoa technology or the vpls technology- that's widely deployed, uh even today, uh in service provider network. So uh if we, if we go back to the history of the sudo war, uh sudo sudowar historically provided a context that identified both the service and the endpoint and because the sudower had that context, that identifiable, endpoint and service it did suffer from scam scale issues. So here is an example.

J

If we are talking about 10k service deployed on 100 node, we are talking even with partial meshes uh between those service, not on all hundred node. I mean um we are talking about uh needing to signal more than hundred thousand sudower in control plane for those different services.

J

uh So, of course the skill was a concern uh that that that was that dpls was suffering from and as well sudwar in general, followed the layer 2 semantic which didn't have active, active redundancy and zeus. Semantic of not having active, active redundancy was primary motivation for evpn, for example, to come and offer the active, active redundancy and as well solves the skill problem by providing as a multi-point to point lsp for the evpn service.

J

Of course, when evpn provided that uh multi-point to point service, uh it removed the source information from the context for the evpn instance and that mandated that evpn has to advertise the mac address in control plane.

J

So what here we are proposing with that new idea of sr optimized elan is benefiting again from the segment routing is that we can really improve the scale by simply splitting the pseudo-art context, uh instead of having it only presented by one context or one label, as we as we have for the sudower is splits that and have uh the sudowar presented by the service label and another context to identify the source. So now, uh sudhuar can be sought.

J

As you know, one said using the segment routing terminology here to identify the service and another sid to identify the node.

J

uh That's gonna be sending uh the traffic uh associated with that layer two service, so so that split can allow us to scale and now, instead of needing hundreds of thousands of sudower context, the service can be presented by only ten thousand uh service instance context tray. uh We we still uh with uh with sr optimized here, maintains the pseudo-r semantic or the point-to-point semantic between two endpoint.

J

uh By presenting, as as mentioned here, uh the the sudo context with two sets in uh in the sit stack, which is the service sid and the sources and as well. What we are saying is that we can offer still the active, active redundancy by simply benefiting from the anycast set capability offered by segment routing today.

J

So how is that going to be achieved? We are going to see that in the next slides. So next slide. Please.

J

So here you know as if we go back to the motivation and the goal here, we are saying uh we wanna, uh of course, benefit from sr or segment routing, but at the same time uh we want to as well uh optimize the control plane uh or simplify the control plane. So what we are saying is that uh if you see here a a network with uh six nodes, as shown and uh and you know, ces attached, wizard zoos are multi-homed or single home uh to as a different peas on that network.

J

We are saying you know, the discovery can be greatly simplified by simply having each node advertise the services as a bit mask of all the services that are provisioned on a given node. So if you imagine uh you know some some nodes here are, for example, configured with uh uh thousand even of services.

J

uh Each node can advertise um a bit mask of all the service said ids, starting with the start services. I think here yeah. The assumption is that we are going to have a global uh service said block right. So so we are going to have an srgb uh for the services. uh But how are we advertising? The service sed? Will? Will simply be you know, a start service uh said plus a bit match uh where each bit, where each service in that block is set.

J

uh If the service is configured on that node- and this is how all nodes in the network can quickly discover uh what services are configured on its spear nodes right uh and that can help, of course to uh you know, discover the membership for ingress replication. For example, if you are going to be flooding uh layer, 2 packet or to build, you know point to multiply trees, for example, if that's needed as well. So the discovery uh of many many servers can happen using a single control plane route right.

J

That can be, of course, flooded using a bgp control plane to the rest of the network and, along with that bit mask we. I can advertise per note, uh especially for english replication. A pair node uh uh uh broadcast sid. So that said, is is a note set still, but that allow the node to receive broadcast traffic. So if the top said is that broadcast not said, then the node know that this traffic is meant to be broadcasted or meant to be flooded uh to the subs.

J

Okay. So, uh having said that, let's go to the next slide. Please.

J

So in here uh yeah we are describing. How can you achieve active, active redundancy uh with uh this new? uh Is this new idea uh here, as shown? So uh so we are talking about.

J

As mentioned again, uh the stack here in the stack uh we are going to have uh the service set and the source node said, uh presenting the suduar context right. So what we are proposing here is that for each ethernet segment, uh that's multi-home.

J

We are going to have an anycast set associated with it, so that anycast said uh you know, is going to be advertised or flooded into as a network uh by igp, but it's presenting our bgp for that matter, but it's presenting an ethernet segment.

J

So what that anycast said is going to be flooded to the network, then the nodes attached to the multi-home site can discover that they are configured with the same anycast sets that are that's associated with the easterner segment that can help them do their df election uh and at the same time, uh when we do data plane mac learning. Here uh we are going to be learning uh the mac, uh uh uh that's sourced from uh a packet coming from a multi-home site against any customer.

J

uh uh So so the mac learning yeah, maybe I should touch on that. A little bit is that the mac learning here for a given service is going to be associated with the source node set and that source node set could be.

J

You know unicast if it's it's, uh that traffic is coming from a single home site or could be uh uh sorry, it could be associated with a unicast note said, or could be an anycast note said if, as a packet was coming from a multi-home site, so the learning still can happen against the source, not said whether it's any cast or regular note said uh that you know, is associated with the node that receives the traffic from a single, so yeah. Having said that, let's go to the next slide.

B

Can you speed it up a bit please because we've got quite a few people in the queue as well, so.

J

Yeah, I I think you still have five minutes right yeah. I know okay, so for uh against the optimized services data plane mclearning here, uh as as mentioned, uh you know again, repetition on on the flooding. uh We are gonna, of course, the data plate mclearning. Everybody is aware that uh we do flood and learn here and we are learning again.

J

uh The source mac against the source sit right uh and everybody would learn that and that source that could be a note set if the traffic coming from single home or in any cash said if the traffic is coming from multi-home. uh So we can move to the next slide.

J

Okay, yeah one one key feature as well: uh uh talk about art suppression and how we can achieve our suppression with that idea right. So one uh approach here uh that can be deployed. Of course uh you we can learn about the ipad binding by gleaning arc.

J

uh However, uh you know the arp replies are typically unicast and ipmaq binding may not be learned, except only by the nodes that are involved with that unicast packet and here a proposal of flooding arc replies to allow the ipmc binding to be learned via all nodes as well uh to meant to to be able to provide arc suppression uh yeah. Let's move to the next slide.

J

uh Yeah, actually in here we are saying you know, mechanism that are required to provide overlay to provide overlay. Conversions are not needed here and that's honestly, a very key uh to this approach. So, as we said, we are simplifying a control, plane mechanism by advertising very, very limited number of routes uh to discover the services and and build uh uh to discover services are configured and learn about them in control plane uh with a much simplified control plane uh offering here, but as well uh in terms of convergence.

J

Given that the ethernet segment is uh presented by an anycast said in the underlay network, we can use overlay, uh sorry the underlay conversions to converge as overlay as well right. So there is no need really for any overlay conversions uh in here, because simply a anode can withdraw it's any cass said from the underlying network. Then it will stop receiving uh multi-home traffic uh or traffic. That's destined to its multi-room site- uh and we are saying here even for faster conversions.

J

Note- can direct traffic uh to another node associated with the multi-home site uh if it's on site, for example, field until uh the withdrawal has been propagated to the rest of the network.

J

uh So, let's move to the next slide, please uh yeah! We are saying, of course, because we are using anycast said we can do ecmp uh multi-passing. This could be ecmp or even ucmp right, because any cassette can be advertised with different weight, uh and if that happens, uh uh you know we can send traffic uh with different weight and as well uh to, of course, to the nodes attached to the multi-site or as well.

J

We could uh have active standby by having one node advertising. Then he has said it was a hard metric next slide. Please.

J

I think yes, this is the last slide, so so, just to recap quickly. Here we are now yeah yeah yeah, I'm concluding so uh uh just to recap quickly. Here we are saying: okay, hey! We are maintaining data plane, mac learning, with all the benefit of data plane, back learning with this approach uh to achieve, of course, uh uh fast convergence, and no you know data plane. Mclearning uh has been optimized greatly on hardware today, and many hardware can do mac learning at line speed, uh mac move.

J

uh You know, maintain conversational learning uh skill very well. uh We bring the benefit of active, active and multi passing through uh benefiting of srne cache, and you mentioned as well. Arch suppression, much simpler control plane. You know, imagine one route that can teach you about all the services seated with uh or configured on your box right or on your router, the leveraging of the segment routing and eliminating any need of overlay conversions.

J

So all the underlay convergence is needed, eliminating the need of any overlay conversions with that. Yes, I I am on time, 15 minutes.

J

I concluded so any question.

B

Okay, I think ali was first in the in the queue.

A

B

Earlier, do you have a question.

B

Hello, hello, can you hear me.

J

Yes, yes, we can now all right.

I

So uh there are quite a few uh claims that are inaccurate and uh the idea of these data plane, learning, uh mac learning in data plane and breaking the pseudo-wire context into a source field uh service id field and the destination which is a multicast field, has been done for over 17 years. First, in 2003 2004 there was a.

I

I wrote, a draft vpls multicast that describes how to do that and then, seven years later, uh in 2010 there was a vx and the native vx land draft talks about data plane learning and uh between the two we had pvb vpls, which does the same thing.

J

Sorry, what is the point? Sorry sorry, what is the point you know? Are we getting a history lesson.

I

I am getting to the point. I am getting to the point that there is nothing new here. Claims are being made in here which are inaccurate and there are issues all the issues that we have with the data plane. Learning it is ex still exists, except that you're not either you don't know about them or you you're, not mentioning them. Okay, so.

J

I

J

No yeah, you know I.

I

J

Not make statements, let's not make statements. What are the issues.

I

Sammy and I'm going to send the email on the working group.

J

Sure, yeah yeah, you are welcome, you know I I don't like subjective comment here and just it's.

I

Not a subjective comment: it has been around for 17 years. For god's sake,.

J

Actually, you know what that idea. You know I even with other vendors I worked for. I had. I have been even talking about it 20 years ago. So what is the point? I'm not getting it. The point is the same issue that we had with the data plane. How come you're, not the overlooking why you are thinking that data plane is evil and we shouldn't.

I

I

J

I

Go just over the issues: flooding issues; okay, when you talk about the all active.

J

Okay, let's, let's talk about flooding issue, why are you saying flooding in data plane is bad, but flooding in control. No.

I

No, I'm not even talking about it. You know why.

J

I

Are you saying that is bad and flooding and then respond once you understand my question.

I

N

I

C

N

Yeah, could you do it really quickly and continue on the list, because we have then three people that are still in the queue and still one slot today.

I

I'm just gonna sure I'm gonna actually elaborate on that in the mailing list, but.

J

I

Gonna mention there is a flooding issue as a result of the all active multi-homing uh where uh uh ce uh does the hatching to one pe and uh uh let's say to pe one and pe two doesn't receive, and then, when the remote sends a traffic to pe two that hasn't learned. The mac address the pe two that multi-home t is gonna flood.

J

One second, I know.

I

Actually, that's not correct. No, that's not correct.

J

That's not correct, why are you saying why are you assuming this is the case? You know you are you, I don't think you read the draft or even uh looked at the slide.

N

Yeah, I I I I'm really sorry guys, I'm really sorry! We are really out of time. So could you try to discuss uh on the list and uh stay calm? Okay, so.

I

So don't just want two other things. No, no.

N

I

B

Hello, I yeah, I think tom has a tom, was next very quick. Please hi.

O

Sammy, um I I have a one one particular question in the in the draft section 4.1 it mentions that extension, another draft. It seems to me that this is either you know something invested, that's reinventing evpn or is.

J

Better, just the draft has nothing to do with evpn.

O

Well, that's even more concerning, um but but also I mean this is the bgp enabled services working group? Would this draft not be better discussed in spring? At this point.

J

We can discuss the drafting spring, but the idea here is that this is an elan service uh and uh we didn't define yet the extension for bgp to support this. So this is uh why we are presenting here uh presenting the draft hearing best right. So.

O

But there's no bgp.

J

Discussion there is bgp uh angle of it that are going to be added to the draft shortly right. You know the part about distributing in control plane the set of land services associated with a given node.

O

Okay and very quickly, why why do something different to evpn.

J

Why we are okay? The main motivation here that we mentioned at the beginning of the of the uh presentation is that we are saying uh uh we want to have a much simpler control plane to set up uh scale better in terms of control plane in distributing the servers. Actually, if you are talking about uh evpn, uh uh if we are gonna, go evpn route and signal, for example, uh on a hundred no ten thousand servers whose mac entries you are talking about millions and millions of routes that you have to distribute.

J

So we are saying you know instead of that approach. Why can't we? uh You know if you talk about evpn and you have 10 000 servers. You are talking about distributing ten thousand ethernet.

O

J

O

About contributing.

J

N

The next slot we have to move to the next slot. Unfortunately,.

B

Okay over time next is uh so, please take any of your questions on this draft to the list.

N

L

um Okay, so I just want to see that this transcript is actually independent of are okay, um all right. So, oh I, my comment was about the semi strap, but now let me get down to my presentation, um this independent uh generic fragmentation.

L

um It's a it's a use case that uh that started with evpn mpos next slide.

L

Please so observations that, uh with even pm at evp mtos. We have this fragmentation issue in that, if you receive a packet from ce, that's too large today, the only way to get it through the underlay is to use ip encapsulation.

L

You put a you, impose your service label first and then you put the packet into ipv6 or ipv4 fragment it, send it across reassemble, de-capsulate, ip and then go on with mpos-based forwarding this works, but new mpos is not used for transport and there are cases where an operator may want to use npr's transport, and it also could incur large ipv6 overheads.

L

um So this fragmentation issue uh for when it comes to sudowr or vpos the uh there it was a solution, uh rfc 4623 using the control world, um but that is not applicable to evpn, because evpn. The two reasons: why is evpn either does not use control word or when it does use control word it's r0. It does not have the sequence number in it, the also the application we are.

L

L

This is unrelated, um so the second opportunity is that some ip fragmentation can actually be viewed as independent of ip. So as long as the context for that of identification in the fragmentation, header is available next slide.

L

Please so the proposal here is to provide independent fragmentation and other functions in a shim layer without requiring ip. So in this evpn mpos example, the after ingress p imposes the service labels. Then it will fragment the packet without ip encapsulation.

L

To do that, we use a generic programmation header and in that header there is a next header field and that will be set to mpos to indicate that after the gfh there is the mpls payload now compared to ipv6 fragmentation header. This gfh will have additional information about the the source.

L

Now the ingress pe prison gfh label, basically saying that next header is a gfs header. So then it will impose the transport label and then send the traffic.

L

Now the egress pe sees that label and knows that the gfh follows so it reassemble the packet and then hand enhance the package to mpos for further processing next slide, please so um the fragmentation header, the first one, is the ipv6 fragmentation, header and the next one is that this is generic fragmentation. Header, the red uh fields, are uh change the differences from the ipv6 ones. The first one uh uh is that four or zero base at the very first at the very beginning, um that is for ecmp issue.

L

um So there have been some discussions on the npos powers and best millionaires, and this ecmp issue was brought up by uh stuart, and so this is a solution for that ecmp issue. um This is past uh just same uh as the first four zero base in the uh sudower control world. um I want to say that it's not in the draft yet, but I'm here presented here because of discussion.

L

The identification field is variable um because there are cases uh we need to uh to embed the source information uh in this identification field, and when, when that is the case, then there is the flag bit s as a bit uh set to indicate that the identification fields itself includes the handx information, so the context from the outer head will not be used and because of that variable identification field, we need a header lens in the in this gfh next slide. Please.

L

This slide, I already talked about it, so we can get to the next one.

L

Next slide, please so coming back to the motivations um first, it solves the evp fragmentation issue without uh requiring ip transportation or incurring ip overheads.

L

In addition to fragmentation, the other functions uh provided by ip that can be uh supported at this uh independent frame level. uh Shimla uh layer as well esp is one example, and in fact this fragmentation or esp functions.

L

They can be applied to many layers, including npos beer or even ethernet, if I triple e so so desires, so it's truly layer, independent and when it comes to beer, the beer, encapsulation header has a protocol field that can specify that the next header is the gfh.

L

Next side, please, um okay, so we are basically uh seeking comments. uh There have been uh uh presentations and discussion in various working groups and uh about use case, and uh if this is a solution that we do want to work on, then then we we need to find the home right now is the or draft is for tsv working group, but it can be any group that we deem appropriate next slide. Please, oh actually, no more! So I'm done with the presentation.

B

Okay, we may got cut off, but first in here.

P

Stuart okay, so um you know thank you for improving the the draft a little bit. um I'm still worried about how you're going to present prevent reassembly lock up, because um basically, um you've got nothing to clear the uh to clear the resources.

P

If um subsequent packets fail to arrive to complete the packet- um and I do wonder whether you should have looked also at using the um pseudo wire header design, with just adding an identifier to it, but I'm still also worried about this design in I'm not quite sure what problem you're fixing, because if it's ipv6 you're running then pmtu discovery will will fix the problem it will automatically back down. For you.

L

um So let me answer the third question. First, uh there are cases you uh you cannot uh uh uh ask the uh uh the traffic source uh uh to uh to do fragmentation.

L

uh For example, you are a evp provider and your m2 is limited, and yet you are suppose supposed to provide for transparent services, and you cannot ask your customer to say that hey, you need to tone down your or your mtu um so that that's the use case, um the the I think, the and then that your first question is uh uh uh what what what was the first question again.

P

uh Reassembly lock up.

L

P

um You you've got all these sort of you've got stray fragments lying around in the uh egress pe.

L

um That's a generic problem. That's uh even if you are not using this one. Let's say you are using ipv6 encapsulation and you fragment uh using ipv6 or even in the pseudowire case. We, when you do have a fragmentation. Reassembly based on the sequence numbers um a egress pe could have many of those uh ones. uh It's the same problem.

P

Not in a pseudo-eye, because a sudower is a point-to-point solution, so the next packet must be for the pseudo wire and will release the lock up. So you will never have any more traffic going across your pseudo wire.

P

Again or it gets released.

L

Well, actually, here it's somewhat related to what sammy was saying. um Sammy was basically using the uh source sources to to introduce this uh pseudo-wire context into this evmp concept. So here is the same thing. um uh The uh the the the the context, either embedded in the identification field or in the outer header, will give you that that pseudo-wildlife context. So we can discuss that more, but I think it's it's the same thing um and then your second question or comment uh okay. What was that again.

P

I can't remember what it was now um the key ones were pmtud and which will happen. Naturally right it's just you don't have to do anything that automatically happens um and the lock-up problem.

L

Okay, yeah: we can continue our offline yeah.

B

E

Yeah, I have to admit, I only read this during the spirited discussion of the previous draft. uh From a procedural standpoint, you might have to split up the the signaling from the transport aspects. It might be better since there are different areas. That's just procedural and uh there's also some details in those bfb3 that need to be changed, but that's that can be done. I have one question like I said I didn't really. I only just scan read through this draft quickly.

E

I don't really understand where the fragmentation, the fragmentation, is being done in the ingress. P e right.

L

E

Okay, wouldn't it have the state already of those labels rather than having to signal them across the uh say, the vpn domain? I don't know I I I maybe a picture or something would be good in the draft because it you know it seemed like there was a lot of knowledge.

E

I couldn't visualize the problem in the in the quick looking at it quickly.

L

Okay, I'll add a picture, but a quick answer is that the labels, I assume you're, referring to the gf gfh labels.

J

Absolutely yes,.

L

Okay, the reason why they are needed is that uh mpos does not have a mean to a way to indicate what is the next header? What what follows, after the bottom of the label stack um so that the label uh gfh label will serve the purple saying that okay, the next header is a gfh header, and then, additionally, the label can optionally identify, say a which source which node sends in this package. uh In addition to the the gfh semantics- and that is, I.

E

L

I'll be like the ce right, the ce right, no, the pe I mean or the pe okay yeah, and that is actually very similar to uh to uh uh to the uh sources in sami's presentation. It has happened that the two presentations are somewhat uh related, even though I just realized that that that that point.

E

B

Okay, stuart did you want to make another.

P

Comment you know um so that I remember where the question was: you kind of alluded to it, but you haven't really answered it, which is I'm not sure why you need type information here. The way mpls works is that the payload type is implicit in the label itself.

P

So I'm struggling to understand why what the point of the next, the next header is other than to sneak in a uh an mpls type without further discussion.

L

uh You mean the next header value uh field in the achievement, header itself. Yeah, I mean everything.

P

Else, we've done we've done on label typing, so this is a a change to the mpls architecture.

L

um No, the the so the the the gfh label indicates that the gfh follows. But how do we know what follows after gfh?

L

So that's why we need the next header in the gfh itself, because it could be that uh uh after the gfh header, it's it's no longer in pos, it could be ip or it could be whatever anything else.

P

Well, how did you know that, to start with, I mean we've built everything else without needing that information.

P

So, presumably you were expecting this to be an ethernet frame or something else frame when you set the uh set the pseudo wire up and all you've done is to all you need to do is to provision this particular um pseudo wire, such that you expect to find a the fragmentation header there and it's probably simpler to always send the fragmentation header.

L

No, no, not necessarily when there when there is no need to do the fragmentation, then you don't need that uh gfh and in the evpn mpos case. uh uh Definitely after the gfh, it's a it's a mpls.

L

Another npr's label stack base. Basically is the service label, but there could be other uh use cases where after gfh is no longer in pure uh payload. So I.

P

Think this needs an a discussion in the mpls working group.

L

Definitely we uh we, uh I also have a presentation schedule for npr's working group and we.

J

L

We we do want to have more discussions in uh in the meaningless as well. We still have thank you. Thank you.

B

Okay, uh I think we probably should wrap it up now with 10 minutes over unless you have a 10 second comment: ac. Are you gone okay? So thanks very much everybody and uh see you next time.

L

Bye. Thank you. Bye.