Internet Engineering Task Force Interim Meetings, 18 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-IDR-20211018-1400

Description

IDR meeting session at IETF
2021/10/18 1400

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

A

Hey good morning.

B

I hope you heard me: did you.

C

Yes, I did hear you: okay,.

B

Great good morning.

C

B

Right so shiva, I see that you're online. Could you please uh confirm that your audio is working.

B

And just for your information, so uh our two speakers from juniper uh their full indian names are not the names that they go by. So if you look at the scroll down, you'll see vegata avula. That is shifted.

B

It is bouncing on and offline, that's minto they're. The speakers for the junipers lives. Okay, no message directly.

C

We're only missing robert is back not.

B

Yeah robert just rejoined robert. Could you please test your audio.

C

Fanta, would you like to test? Oh shiva, would you like to test your audio? Please.

D

uh Yes, so hey uh are you able to hear me good morning, sir.

C

Yes, I am able to hear you thank you for testing your audio robert. Could you at least say hi how you doing this morning. We need to make sure your audio works.

C

Rapper just bounced offline okay! Well, since.

E

C

We're having our moments of uh joy for this morning, okay,.

B

C

Robert, could you say hi this morning.

C

Just try to get into my queue and say hi.

B

Robert is saying in his private chat that his audio is denied.

C

C

I suggested that he swap browsers, I think so. I don't see anything where I'm denying him.

C

Azum, would you like to say hi this morning before we start so you're ready.

C

C

Hi folks we're going.

F

To start in just a.

C

C

B

While we're trying to get the rest of our speakers going, if you also want to test your microphone, make sure that things are working, fine, that's! That was a good time.

C

Could you increase your mic.

B

If you're using a headset, it sounds like it's coming from your open microphone rather than headset.

G

So I will mute the audio.

B

C

Jeff, I believe the introduction is yours, so I think we've got asian we've. The only one we're waiting for is robert.

B

C

F

B

Presentation so we may reorder, if that's the case,.

H

B

And uh shiva confirms that he's the presenter of the two.

C

Okay, so we can.

B

C

With that go ahead,.

B

Okay, so good morning, everyone good afternoon good evening wherever you are on the planet, uh so this is the idr interim for bgp, auto configuration and the scope of this session is two things. First is working through. You know auto configuration as a discussion topic specifically towards the proposed protocol extensions to implement the design team document.

B

We also will have a presentation at the end of the session covering the vpnrf functionality that djun has been talking about on idr.

B

So for the auto configuration design, stuff we'll be reviewing uh the scope of the problem and the auto configuration protocol requirements next slide. Please.

B

So this is from our design team document that cleared working group adoption and the in target environment is for auto configuration is bgp as used for underlay routing protocols in data center networks. So one of the discussion points we'll come back to as we work through the proposals. Is you know? How does this actually serve that environment?

B

We, however other scenarios may be considered as part of our analysis, but work on those environments may be deferred to other efforts. So part of the discussion points as you're working through your presentation. Please focus on how do you actually address either the targeted environment or potentially, future environments? Next slide? Please.

B

So this is a reminder from the auto conf considerations document the required state that we decided as part of the discussion through the design team, and the working group list was that the auto configuration protocol is primarily there to let an implementation know what the php session transport state is going to be, and the state that we're going to be learning that's necessary for the protocol to be able to function. Just for discovering you know bhp session endpoints is you know the obviously the uh this is for bgp.

B

uh We did discuss that the easiest way to avoid repeated connections to a bgp session that is not going to change its properties.

B

You know, on a regular basis, is to exchange a php session protocol state version number. This is just a hint that the configuration may have changed and if you got told no, you can't connect on round one. Maybe round two will work and clearly the rest of the stuff is mostly towards getting a bgp session to come up at the tcp layer. So this includes the ip addresses know.

B

Whatever address families we're trying to work through transport security, you know parameters so as an example of that uh using a key chain or using md5 using ao. Is there a key chain id that you should be agreeing upon?

B

Those things are necessary to get your session your tcp to even come up, and very similarly, if you're using gtsm, you need to know and agree on that ahead of time. Otherwise your tcp may not even connect.

B

One of the discussion points in the document is that bfd, strict mode should be implemented. This avoids implementations from bringing up bhp sessions halfway and having them die if bfd is not appropriately provisioned the rest of the state, the design team discussed was to be discovered, know from bgp itself.

B

So once bgp transport sessions connected- and we start the bgp state machine, the b2b open is going to supply the rest of the information for a client that is looking to use auto configuration to decide if this session is acceptable or not, this information included the as numbers the bhp identifier supported daffy saffies.

B

We did discuss and this should have been deleted. I apologize uh device role was a basically optional information that maybe exchanged either capabilities, or you know some future information to decide. If you want the session to connect or not- and the discussion point basically is that this information should not be duplicated in the auto configuration protocol itself to avoid no mismatch of information and potentially confusing operations next slide, please.

B

So the discussion points we'd like to ask each of the presenters to work through as you're giving your presentation. uh So these are some of the points and some of these things have been discussed prior interims.

B

You know what network layer is your auto configuration protocol running on, so is it running l2 l3, l3, unicast, l3 multicast, uh you know at a higher layer. You know. As an example, robert's presentation looks like it's targeted effectively towards layer 7, where bgp itself is the uh distribution protocol.

B

What's the state model for your protocol, does it require no some sort of session, so example would be like uh xiaohu's draft, which is not being presented today. I did actually require bring up a two-way session, for you know the mechanism to work. uh Some of these mechanisms are basically uh without session. Some of them are basically shouted out the dark, and you know you get to hear what the state is.

B

So, in those circumstances it's effectively sessionless and the information is cached, and you know the caching discipline is one of the discussion points and certainly once you've actually discovered the information from the protocol and what are the trigger points with the bgb finite state machine, uh and how does this actually interact with things so this impacts things like? How often do you retry? uh What is the expected retrying disciplines for things for the connectory triad, timers.

B

Those sorts of matters next slide.

B

Actually this may be last slide.

E

C

Did you intend to have something else.

B

Nope this may have been the last slide. Sorry that I forgot, if I had to slide past this one so again, these are the points we're hoping to have touched upon as part of your presentations.

B

So the next piece is, you know for us to move on to our uh presenters. I believe robert is first in the queue that from our agenda robert, you said you think you fixed your bike. Could you test please.

I

Hello, can you hear me.

B

Victory: robert wonderful rapper.

I

Okay, good it was, it was rum's fault yeah. The meat echo was pretty much locked to be disabled by a micro microphone. Okay. So today um the topic of auto discovery came back and I thought I bring back the the one of the ideas which we have been working on for many many years actually started in 2004 and and and it's not actually focused on on data center. It is focused on when and later we have added the ixp um to the mix as well.

I

So a bit of history, as I mentioned it started, 2004 uh original version which I presented in vienna ietf, was actually decoupled. The flooding in igps to build the bgp sessions between bgp speakers interested bjp speakers.

I

It was called auto mesh originally so after this, um the feedback was to actually and it was actually in one big draft. So after this, um the feedback from the idr and also um ospf and isas working groups at that time was let's decouple this to three different documents and and try to put it through the process. So I did splitted this to um ospf and isis and drafts and then left the bgp part um in idr.

I

However, after discussing this more with some of the colleagues, we concluded that it may be much leaner idea to contain it together in bgp instead of using igps for flooding, because you know, use of igps has pros and cons, and if you are just talking about setting up bgp sessions, maybe it's good to keep it together and and the first um issue first um year of the draft which used the bgp all-inclusive um method was um proposed in 2005, with pedro rex and and chandra and kayla as well.

I

So that was the the history behind it so in overview. Basically, the idea is pretty simple: why do we need to continue establishing um bgp sessions by hand and robert.

B

If I could interrupt you for a second yeah, thank you. uh You know the slides were not following you. So uh are we currently at the correct slide for your discussion.

I

uh Yes, currently in the fifth slide right yeah exactly thank you. Oh.

C

Because I was swapping my local version.

I

Oh okay, sorry um so, basically the question was: why do we need to keep establishing ibgp sessions um by hand uh if we want to do the vgp full mesh?

I

um Of course it was not targeted originally for ebgp sessions in general for any vgp session, because for establishing um tier 1, tier 2 or even threes bgp sessions ebgp sessions. The bgp session is the least worried that the biggest um headache and biggest work is in the policy configuration.

I

So we we never thought that automating of just bringing up bgp across different uh parties is a good idea, especially of different parties with different policies.

I

But then um we spoke with um um john mitchell and warren um and um they have the idea called um warren's draft called idr, socialite or however socialite, and that was kind of extension of route server to establish in, in the case of the open, peering directly bgp sessions ebgp sessions between ixp participants.

I

So we thought there is so much overlap between both ideas using establishing ibgp in wans or mans, and establishing peering with the ixp.

E

I

And and that and that time actually ixps uh started to seriously grow for the right reasons, as we know, uh so we thought about: let's combine the work together and and join the join the drafts so from um which was the year uh from 2014 uh pretty much uh the the drafts were joined next slide. Please.

I

So we are not really proposing to remove route reflectors, so this is not to be replacing route reflectors. It is just another tool in the toolbox to allow operators to simplify provisioning of bgp rings and- and it could be so that some of them may actually use automatic peering for some savvies and still around protection for the others.

I

um So so there's very various use cases for bgp today, as we all know, um and they may be needs to to have the full mesh for some saffies, as opposed to always going through the always go to the right reflector.

I

I

Couple of points: why do we need rr? So what are the main use cases for rrs? I mean this is I I think I have already presented some of this, so this is boring. I apologize, but I just wanted to refresh everyone's understanding of this work so pretty much. There are four reasons for route reflectors. One is the of course configuration simplification, um the other one is information reduction and then a third one.

I

It's optimization of number of tcp sessions to be handled by each bgp speaker and the fourth one is pretty much uh along the lines of implementation, details of generating updates and and basically how we build the update message and how do we replicate the update message to bgp peers, so this proposal addresses number one um and now, let's discuss number two through four, so next slide information reduction.

I

Yes, so let's observe that in number of address families, there is no information reduction already on the route reflectors, because if you use different rd per verb, let's say in lcvpn or l2vpn, then you're pretty much propagating all the paths uh everywhere, and maybe this is this is good and this is actually good. Not maybe so this is good um design and and this there is no reduction um there.

I

There is some reduction, for example, when you are ipe isp and have let's say hundreds of different ebgp external peering points and you may be getting even full table from all of them. So in this case, indeed, you may you may end up into getting hundred puffs if you do the uh full mesh which is not uh desired. So in this those cases, you are much better off to get at least two paths, maybe three puffs using either odd taps or diverse path methods.

I

But in many other networks you know getting even couple of paths is no harm and and simplifies uh operations as well as uh provides ready paths for uh fast connectivity, restoration.

I

um Next one, please um reduction of number tcp sessions still comes up sometimes, but you know I always bring the example of of a little web server where it can handle thousands of tcp sessions concurrently.

I

So today the same with our routers on the rps or res a number of tcp sessions which can be built, it's not really a problem, um it's more of the chattiness of bgp and the processing of what's come coming over the tcp sessions, rather than uh just the tcp sessions alone. So the reduction of tcp sessions here is not really a big, significant factor for keeping our hours in place um next, one um efficient update generation.

I

So in this proposal, as you can, you can see, you can still on ibgp side, um put every ib gpp here to the same update group or peer group. So essentially you still generate update once and then replicate it to all the peers. Just like you would do on the rr. You can do the same exact code path on the ps or asbrs.

I

So with that, there is not much difference if you're using rtc, for example, then indeed you may actually end up with some post generation filtering on on a per pure basis, but even that has been solved because we had to solve it for vp and before route reflectors, so the same code can be used if you're doing the full mesh from the pe itself.

I

um Next one please so now there is next one um simple illustration about the idea. So the entire idea is that you will use route reflector. As you know it today without much changes with a new savvy and that new sapi will be used to distribute configuration information from the interested parties which want to peer together and it's done on a per afi safety basis.

I

So you don't have to do blind, auto mesh for all sapies. You can do it pretty much as where needed and as needed. um The rr here is pretty much a database. You we treat um a route reflector here as a data database holder. Of course one can say: oh, but there are so many other databases, and you can, you can say sure. Yes, but but rr comes kind of for free here, so we don't really have to worry about deploying some new protocol or some new tool.

I

I see kwar has a raised hand go ahead, gabriel. If you have any questions.

H

Speaking as a co-author, you explained very well the use of rr in auto discovery. However, I just wanted to uh confirm it that even without an rr, this proposal will hold true.

I

Well, yes, but the rrs here are used to keep the the information about bgp sessions. So I'm not sure, of course it can work without it. You can exchange those directly, but you would have to build the full mesh by hand ahead of time.

H

Yup, that was my point if the full mesh is already established and you are adding new address families, this should work seamlessly.

I

Yes, indeed, indeed exactly I I let me finish couple of more slides and then we go to the question. Sorry linda. I want to just keep keep going so next slide. Please.

I

Okay, so so, basically, the concept is to to define new um safy and um the the the sapi format is group id with the router id to make it actually unique within the network, um and you can do um full mesh or even the scope meshes creation um so automatically you can do, let's say uh full mesh within the confederation if you have converts in your network and still use normal um peering between confederation border routers.

I

um So we left that flexibility in place just because there is no cost to it and allows you to build arbitrary, arbitrary topologies within your network, especially in the cases where, sometimes tomorrow, someone may invent a new selfie which can be uh which may require some partitioning or or layers. So that's why this kind of group id is in place next, one please.

I

This is just a format of the um pure discovery attribute, so basically, within the new safy I described we defined the new attribute uh without, um uh and that attribute will be pretty much um available in that nusafi uh for propagating configuration information now, based on the history of the last couple of interims and and meetings in itf, um they may be additional fields required from the work which jeff was leading uh for the requirements of auto discovery in the dc, which we may need to add here.

I

If we decided to to proceed with that work forward, so so that that that floor is open, and uh perhaps we can, we can discuss what needs to be added what what needs to be maybe removed the next slide, please.

I

um So here's a couple of bits which are left for um which are pretty defined to to automate uh further and provide more flexibility into the provisioning um next one.

I

And this is the api sappy descriptor, so so what I meant about adding additional information, so maybe here in that descriptor we may need to add to additional information. If we all agree, they make sense for one use case. um So so I I was kind of meant to to show that encoding um for additional accommodation.

I

I

Here are some more of the details of the operation of this so, for example, the case of changing router id on bgp speaker. um It will regenerate the bgp and lris uh with the new router id right, so pretty much.

I

It can be made before break uh essentially model, where, if you're really changing router id, which is pretty much disruptive event, no matter how you look at that, you can actually still make this discovery graceful, the same for um f flag, which is force, for example, if you have already uh established a session over for given safie um an id, uh you can force to recreate it based on the uh auto discovery information.

I

Another useful thing for um for this kind of um approach is not to establish anything from the perspective of this draft, but only use it to validate if your sessions are established, wherever it's needed, so the another use case for this rapids in the in the space of um monitoring and operability. Of course, one can argue you should do the management system for doing stuff like that, of course, but this is just kind of a side effect of having that discovery.

I

Information in one place discovered information about bgp surface in all bgb speakers, and you can use it there or even you can feed that information to your management system from those databases, because usually it will be at least two different rrs, acting as a database like for redundancy.

I

Next one, please yeah, that was the informational model which I described.

I

You could also apply um templates um to the provision, auto discovery mode sessions and likely. That would always be the case because for some security reasons or for some additional validation reasons in the ebgp case, you can add some additional um security exchange between your peers, for example, um but it's all optional right.

I

So so the draft it's um pretty much extendable and if the draft is not extended, the point is that you can still provide additional functionality required by local templating uh and and then during the establishment that template will be uh whether it's a session, template or pure template will be acted on before the session comes up and discussion.

I

um Let's move to slide 20.

I

So this one is actually um question: is bgp the right model to be contained, or should we go back to igbs so currently from whatever I talked to about this draft with um bgp's, closed and and contained solution seems to be the optimal one. um So I don't think that we should go into the igps for this. A main reason why igps are kind of harder? Is that more and more igps?

I

um Now you can see in lsr multiple hierarchies, not even two, but up to six or eight, um so you would have to leak all of those informations around into the all um all areas. So that's one problem with using igp's flooding for distributing that information.

I

So I think that's just for up to discussion. I brought it here because I had it in my notes, but currently you know we are keep thinking about continuing with bgp based approach um from each bgp speaker. Actually, there is 130 bytes of the size of the message which is sent to the rr, so it's kind of tiny. If you look at the bgp overall vehicle next one, please.

I

So basically, another question is: if you already have to provision session to rr, is this really auto? Well, so today I look at the rr for this particular discovery uh thing, uh even assuming you are not already peering with rr for other reasons, for other savvies is just like you configure ntp server in your box or dns server or dhcp address, syslog, etc. So, basically, I don't see adding another configuration line um to to your router config to automate something which otherwise takes some.

I

You know tens or hundreds of lines it it's a it's a costly um offering. So that's that's about it next one, please. I think it will be the last one.

I

um um Someone suggested actually to also extend it um with the uh adding the peers name, and I think this is very good idea, because today you know we have some extensions in igp's to to allow you to carry the router's name into the lsps in isis. Let's say with bgp. It may be also pretty useful to not only show your peers by ip addresses, but also by names so easily. This kind of approach can be accommodated with simple extension to the um signaling and last one is pretty much. Thank you and linda.

I

Please go ahead with the question and anyone else if required,.

J

This question this reminds me of that google drive we have like sq1 recovery is along a similar concept, but it's much smaller scope like um so. Do you envision to be kind of st edge discovery to be a small portion of this, because I see there's a big bigger like more auto configuration versus sd1 discovery is only to discover the edge node some of the the port properties, so that the the rr has the database to manage the authentication and distribution of the the peers.

J

I

When we wrote this, um sd1 was still in the infancy or maybe not even there, right.

E

I

So this one is aiming pretty much on the on the one ipgp and now route servers.

I

However, uh if you find um a use case to discover your sd1 um endpoints and you find a common or so to say, global um database um acting as the rr, let's say some rr in the cloud, um I don't see any problem using this um for discovering uh piers with the sd1 as well, and in fact um it can, it doesn't even require, I guess, any extension, because you you, you can actually use the the one extension which we added for ixps, because you will be having ebgp session. I guess so.

I

It may work out of the box if you, if you have a route reflector or some database, acting as a route reflector available for uh sending information to the peers.

J

Yes, so in the sd1 edge discovery we had a we proposed a new selfie to describe. This is actually the the information about the edge information. So my my question is really in your vision like this selfie. Do you just envision one or can be more than one.

I

For no so so the safety I define is just a container to allow exchanging information about uh uh my own. Suffice right. So I'm not sure if the sap you are referring to is the one which can be fit into this um bigger uh vehicle or is alternative to the bigger vehicle. But I think it's the is the former.

J

Okay, yeah, okay, thank you. We can work out later offline.

I

A

Yeah I have uh some questions. um Robert like this is a good draft. um Obviously you are using uh route reflector for the ipgp case for auto discovery and route server. But let me start with my first question uh kind of so the use case.

A

It's uh mainly for the ixps, like that's my understanding that this is the kind of the target audience would be for the ixp use case, and here you are trying to simplify using the bgp, not the kind of using the igp, but the the requirement we defined earlier, the kind of in a design team which was kind of for the data center and where we have defined the requirements.

A

My question is to the kind of to you and the chairs uh so shoe, jeep and kyogre. uh Should we kind of try to also define the similar requirements for the ixp use case, especially for the ipgp and ebgp, and yours is kind of a talks a little more on the kind of encoding and the implementation approach.

A

But, like I have the kind of use case and the requirement sets, should we define part of this kind of approach so then kind of it follows? Then, naturally, the implementation method.

I

um Okay, I take a stop and then jeff can actually um speak as well.

I

So so, basically, um you are um right that um this is not targeting the the dc environment, so the draft was the requirements we had about. This draft was to have the bgp sessions between end points to come up. That's it! um What needs to be exchanged with that um to make it happen, um was pretty much uh uh as minimal as possible, yet offering some additional flexibility into the provisioning aspect of things.

I

um Now, if and and it's actually, the original uh work was for ibgp for for one and then later we came with the um ixp extensions just to allow easier peering between the ixp parties. um So I I don't have any.

I

um You know nothing against um writing requirements for one um if they are going to be substantially different than for dc, but I think what jeff was originally planning with the requirements was kind of trying to keep it uh common, and so we may actually leverage that work already and maybe spell out that okay, that requirement it's only for one and that is only for dc. I'm not sure how how japan and suen and k will want to want to handle that kind of um requirement document.

I

But from my perspective, this work is pretty much aimed at one and ixp and maybe sd1 as linda added later.

C

You just said uh so I made sure I heard it right robert. You said it's for ixps and then data centers. Would you please just repeat what you were targeting this at.

I

No, no, so this is for ixp and for one and and not for data centers. I never intended this to be used in data center environment. I'm not sure. Maybe it would work, but we haven't done any discussions and thoughts about if it's optimal design for data center.

A

So that's my question is basically uh since it is not kind of a meant for data center and kind of a it is for the van, and I cannot see that linda's point and, as you kind of discuss like even for his due and ibtp cases, also it could be um possible, like he is doing as a one of the sapi to be discovered as part of this uh kind of auto discovered. But all I'm kind of trying to say that's like a. We should have a separate uh kind of requirements.

A

Dock or use cases like a data center um in for the ixp cases, so that it's kind of clear that so what we are kind of trying to achieve, and if this is the only way or like if there is kind of other approach as well.

H

Yeah this is cave. I am going to speak as a working group member. um I I personally haven't seen working at idr or attending an idea for every proposal. We bring up a requirements document.

H

The second point I would make is whatever we did as a requirement documents I feel was mostly tailored towards data centers. If you look at a lot of those requirements, it may not hold true, particularly for ibgp sessions.

H

So that being said, I would say maybe robert in the subsequent presentations. We may add the use cases and start with that. Thank you.

C

So care and cossack cossack asked me this question before about the data center versus the uh dts, as jeff mentioned in an earlier review of the bgp auto configuration, we started with the data center, because people felt that was the most critical at first kassick.

C

If you and robert are really building towards something else, it might behoove you to get your heads together and look at the requirements and see what you think is common or different and at least uh write up a short note and send it to the chairs and if you feel it's an internet draft to send it out to the draft it's worthy to discuss. We're, probably not we're probably going to go to these interim formats rather than another design team, so provided something useful to see so that we can review it classic.

C

I hope that answers your question.

A

Yes, uh sure exactly so that, thank you uh that that answered my questions and I kind of we can work with robert to kind of pass the use cases or the requirements we try to clarify um means. uh I'm a fine either way to be part of this or could be kind of separate, but like a kind of bring it to the group, and maybe we can discuss like it- may not be the extensive requirements like data center, but like a yes, this exam, this exactly answers my questions.

A

Thank you. Okay,.

B

And I can finally jump in here um so robert. This partially echoes comments uh you know made by some of the other prior speakers. uh This is just sort of summarizing some of the things that uh that was apparent as part of the design discussions that we had. uh You know during the design teamwork and how it sort of fits into things now.

B

So the thing that's a slightly awkward fit as you're sort of getting to is that you do still need to bootstrap the bgp session itself in order for you to use this discovery mechanism for other bgb sessions.

B

So to some extent you know you're sort of recursively going back to some of the problem we're trying to solve in. You know the proposal that some of the other mechanisms might be able to deal with for getting that piece bootstrapped.

B

But that said, the things that are useful is discussion. Points from this proposal, two big things now the first one is that the actual state that we need for bringing up bgp sessions, including ibgp.

B

You know that's still the same as what we had been discussing as part of the auto discovery requirements, and you know the changes necessary to go into this proposal. You know to get the same information present is not that big so that that's not the stalling point.

B

The other thing, I think that's actually a useful discussion point about mechanisms like this. This is effectively providing. You know you sort of started with the idea of no route reflector, but really what you're discussing is a discovery, rendezvous point for places that want to do.

B

You can reach my session and you learn it from a centralized database, as you put it so that aspect is interesting and if we look at the sort of three use cases that we're looking at for php discovery in general, you know the first one for data center purposes is effectively hot by hop.

B

You know, having some sort of you know. Provisioned mechanism like this no via the management port is a possibility. Certainly it sort of fits loosely into some of the ideas that I think randy is going to be talking about from hbspf.

B

If we're looking at something that is like discovering things in ixp now, certainly you could run point-to-point discovery. Mechanisms like we're gonna be discussing uh in the other presentations, but uh certainly the amount of traffic starts to increase significantly, whereas a mechanism like this reduces the amount of discovery traffic.

B

And if you talk about the third case, you seem to be uh targeting uh for like ebgp, that's something that either mechanism could be used for the discussion points for how do you actually tie in your policy for your ebgp become a little bit more interesting.

B

The discovery protocol requirements are leaving things like that out of scope, whereas you know something like this could actually provide that configuration templates as part of the information that's exchanged in the protocol.

I

Yes, jeff, I pretty much agree with all what you said. uh Maybe additional comment which I didn't say during the presentation uh was that um the adding the rendezvous point, as you nicely called it, um has an additional kind of property of um ability to do the policing from you know central locations on top of what is happening in your network. If you widely allow any to any flooding you're losing that um policy uh control, maybe it's good.

I

Maybe it's bad right, there's, maybe not one size which fits all, but I just wanted to make an observation like this um and clearly discovering that rendezvous point uh or discovering you know the rr can be optimized and you know I for me it wasn't a big deal to add a configuration line specifying an ip address, maybe even any cast ip address or two ap addresses.

I

However, if we can, if we need- and we want to automate that step and especially leveraging some other tools which we can have- I mean by all means- why not.

H

And speaking as a working group member here, I think um this is where we should take a poll from working group um to say: hey: do we want a bgp auto discovery to happen within an as uh for an ibcp connections? And if so, um do we really want the solution to depend on rendezvous point or not or more?

H

If we want more, like rob robert suggested there were proposals of leaking the auto discovery, information into igp's, and maybe we can resurrect that if that is not what working group or the operators are looking for, then we could go with the roundabout point to begin with or rrs and and then extend it eventually, but that would be a good feedback to get from working group. Thank you.

B

Okay and the interest of time yeah we're already over time for this session.

A

Okay, can I please ask one more questions like yeah, um so robert, like my second point, was like we can discuss offline, I had few more but like, as jeff mentioned, like still, it needs some bootstrapping and not only just the twin appear. Definitely it's optimal solutions. You can control the policy as you kind of mentioned, and especially uh we have seen that test during use cases.

A

So all I'm saying that's not only just the doubt needs to know that route reflector, but it kind of needs to have the route reflector also to be configured to exchange that informations like who are the other clients and etc.

A

So that requires some sort of a minimal configurations even to kind of exchange under this new sap to all the kind of a different uh peers attributes to be discovered right and when we kind of send the distributions that has to be kind of configured in the error, so that is still there, and I see that uh the ebgp case is uh yes, it is kind of covered, but like a not well extended cover the maybe the route server part.

A

uh So maybe it would be good like if we separate it out like a kind of a as cable was mentioning. I think I like that approach like a eb ibgp, with kind of within the same as and having that rr as a central point to kind of exchange the route. So it's a minimal bootstrapping, even in the error and then ebgp with the route server. What are the configurations, kind of needed and etc? We have to explore. Thank you.

I

Yes, I mean uh one last comment on that: what you just said, yes, and and and by all means one additional data point- is that the way we originally thought about um this work was the case where you have a lot of um service to deal with.

I

If you have only one or two copies, maybe this entire discussion is smooth, but if you have 20 copies and growing, because your network uses more services which are bgp based, then maybe it makes sense to even provision such an you know discovery around the bullpoint, rr and automate subsequent sapi's uh establishment.

A

C

Okay, thank you. We've gone a long time over we're gonna have to swap over to the other presentations. Jeff was right. A few minutes ago, I thought we were coming to a closure. I'm gonna bring up um randy's presentation.

C

So we'll go go to that. Next again, I apologize. I thought we were coming to a good conclusion and I have a favor robert. Send me the last thing you sent via email. If you would so, I can uh make sure to get it in the notes. Okay,.

C

F

Grab randy here um as the previous presentation, this one was not designed with a direct target for idr. um It's from the uh link state working group um and uh the next slide. Please it's three drafts, because that was the structure over there and the primary goal here was discovering layer, 3, topology and keeping it alive for bgp spf, but at least it's in the data center.

F

Okay, so bgp spf is designed for data centers. So this was designed for a peer discovery, but also not just bgp but in general, dealing with a multi-tenancy.

F

Data center topology, so you will see some things which are designed for a much larger scale, data exchange than maybe is necessary for the idr application slide. Please the say you want to find your neighbors.

F

You want to learn their layer, 3 point-to-point addresses and then you want to configure bgp spf slide. Please and main bass draft. Is the lsv rl 3dl draft slide. Please, of course she was learning why I wanted to run my own slides um so what's happening?

F

Is you have devices running bgp, spf and they're trying to do bgp over tcp, but they need to find each other so down at layer two, we exchange ethernet pdus and discover the point-to-point links and exchange those ptus to describe the layer three addresses and then we can do link checking and we can exchange a fee safely's next slide. Please.

F

um This is not a routing call protocol. It's just discovering the layer three addresses on point to point once now, I'm lying it's slightly more than that, because maybe you want to see behind them to loop backs, but that's about it now next slide. Please we get into the it's designed to carry a lot more data.

F

There are ethernet frames, the pdu that's up top their ethernet frames. They are gathered to form an l3dlpdu.

F

The l3du l3dlpdu has the pdu type payload length normal things. It has a signature so that the data can be checked for authenticity and integrity.

F

Next slide, please it's layer, 2 transport and it can hold a ridiculous amount of data. As I said, it's probably not necessary for the idr application for the data center that egpspf lives in where you could have multi-tenancy. You could have one server that has, you know 500 tenants with each with their own ip address, so this is meant to scale for that next slide. Please!

F

Okay, so they're big pdus for your information, your god, is very kind to today transport director early review of this. We had a couple cycles. That was very helpful, so that stuff, that I just showed you, even though it's probably a little dunky for our application here- um does probably hold up technically next slide. Please, why didn't we do it at later? Three, when this runs there are always no later three.

F

The object is to learn the layer three. So it's a cheap tcp like protocol with reordering re-transmission acknowledgement along the sessions etc. So, but it's pretty lean next slide, please!

F

Okay, it's fully stateful has a session per peer. He has grateful. Research and state may be resumed. Okay, so um you can see the influence of uh bgp. No, no, you can change it's fine.

F

The influence of bgp, heavily okay, there's an open which has a nonce there's, something we call the length level endpoint identifier, which may be the math.

F

It may be something else that in different environments, they're different things you may be interested in the attributes and I'll do a little bit more about them later, but there's essentially a list of attributes and they can be arbitrary things.

F

If you want to describe your role in the club or describe what you can do there, it goes, we did not have the hubris to think we knew the specific set of attributes that would be mandatory to implement, and then we get into the keying stuff for the authentication and pdus have serial numbers next, please that's the open. We now exchange encapsulations, so um here would be account and then a list of encapsulations that I'm handing my peer and again the serial number for that will restart nonsense.

F

Next slide, please.

F

So in a for instance, this is an ipv4.

F

Encapsulation attribute- and it has flags that say, for instance, I just want to draw your attention to this. Oh, this is what I'm giving you is a loopback address, because um bgp purity is often violent backs, so we needed to denote that slide. Please, okay, so there it is meant to support bgpf in a closed style data center.

F

So sue brought up the problem that of multicast storms. We don't think they're very likely to happen in that environment.

F

Okay, there's much more detail in the draft that you can go to, um but I don't want to bore you to death with packet porn. It's just a way for peers to discover each other's addresses next slide. Please!

F

Now we, oh yes! By the way we do have two implementations, um one in python 3, which is actually an older version of the protocol and much simpler. um It wasn't designed for a million in calculations. It could probably only handle a couple hundred and you might take a look at that old draft um to scale this back just more suit. What I think idr needs- um and we also have one in golang um so next slide. Please.

F

So we wanted to have some security instead of painting it on afterwards. It's kind of designed in next slide, please so the open pdu as I showed before, exchanges a key, and we have the type of it and its length and the key itself, and then the open is signed that next slide.

F

Please, there are two main flavors: okay, the key in the open pbu is the public key of an asymmetric keith pair, the sender signs with the private the device sending the open can use the same key or different key for different lengths or different flavor points, etc makes no difference next slide. Please.

F

There are two general approaches: trust on first use like you do when you ssh it says hey. This is the key of the server. You want to trust it. If you're foolish, you say yes, if you're not foolish, you go to some external authority and you say: hmm does that key fingerprint match what's in the external authority and that's what we mean here at the latter as pki based okay, but next slide, please, but so trust on first use.

F

The sender generates it's believed without question, which is what we meant by trust on by first use. I once abusingly call that marriage on first date, but it's far too common to ignore and all subsequent pdus can therefore be authenticated to come from the same attacker. If that gives you comfort so next slide, please.

F

Pki based is you first have to declare what your public key is and put it in the central database.

F

Okay and the central database signs it and therefore the receiver knows the central data gate, space's public key and can validate your public key. Next, don't worry! This is next slide. This is not x509.

F

It's x509 is way too complicated.

F

These are just a central authority signing over all the players, public keys, so that every device must know the public key of the central authority.

F

So when it receives your key on the open, it can look at that and it has been signed by the central authority. So therefore, you trust that it is not trust on first use slide. Please verification is the same in either case.

F

The receiver can't tell it's just whether you trusted it open.

F

Okay, you don't go to the trust anchor or do you make the leap of faith next slide, please the choice of which is left to the operator constructing the data center. It's just a matter of philosophy.

F

Okay, so next slide, please we're finally going to get to bgp, um but.

F

The protocol being described here is called the upper layer protocol because it's not necessarily specific to bgp, but pgp is the only upper layer. Protocol we've developed so far slide. Please, okay, it's meant to allow configuration of arbitrary protocols. Bgp is the only thing you need in spf next slide. Please.

F

There's a there's, an l3dl pdu that says what type of upper layer protocol which in our case is pgp the count of attributes and an attribute list. So again, another way of saying: hey, I'm a leaf, I'm a spine, I like chocolate, ice, cream, etc.

F

Next slide. Please.

F

It's again provide the minimal set for the open to succeed next slide, not to replace or get in conflict with the data exchanged by bgp open next slide, and the reason is, as is in the uh draft, the requirements draft is multiple sources of truth through a sure bit for pain. Next slide. Please!

F

So what attributes do we need to exchange? We need to change the as number we need to say which address I want to use for peering next slide. Please we need to exchange the authentication data for bgp. I don't mean the pdu signatures. I mean um the tcp md5, a o, et cetera, et cetera. Is there unfortunate are the bgp tcp can be authenticated?

F

Is that saying I've run my half an hour? I don't think so.

F

Soon am I okay, I'm nearing the end anyway.

F

C

You're fine, my my bad go on no.

F

I'm almost at the end, yes, there's a pdu for ipv6. Sorry, I always get in trouble for this um again. Let's go a little further into the attributes. Slide, please!

F

Okay! So again, there's an attribute count. A list of the attributes, an attribute has the length and the value big surprise. This I've realized these pdus are pretty boring. This is a feature not a bug.

F

Next slide, please, the base protocol allowed mark to look back, so we have to the end of the packs next slide. Please and that's pretty much the whole show next slide. Please, of course I lied we'd like to hack it but to better fit idr. I think if you got serious about doing this at layer two, as I said, I don't think you need the full being able to carry. You know two to the 50 packets, um so I don't think the hundreds of addresses and encapsulations are needed and next slide. Please now I am.

E

F

The end so jeff.

B

Randy, thank you. um So a couple of comments, the things that aren't quite uh completely in line with the auto config design team considerations. Thankfully those are just attributes, so I don't think that's a big deal.

B

The question I do have, though, which you probably have experience from from uh lsvr, is how does this interact with the state machine? You know when tcp is capable coming up, because obviously you're exchanging information about uh layer, three end points before layer. Three itself may actually come up, uh so we have to wait for ip addresses to get configured duplicate, address, detection to finish arp to actually do its thing and then bgp can finally do its job.

B

How does this typically behave? You know once you actually use this mechanism for like lsvr.

H

Randy, I can take it.

F

Go for it care. I don't think this is, um and you're diving down an unnecessary rat hole go for it. Okay,.

H

Yep um speaking as a uh uh as a co-author, um not as a working group chair, so this would be, uh but this would be uh this would happen even before the state machine goes in. You know you would establish um the layer three session, um or at least my bad.

H

You would establish l3dl session first, as the link comes up as part of l3dl session establishment, you would exchange what bgp parameters you want to exchange on a single hop link, which is for the data centers, and once that happens, you would then feed it into a database that is very analogous to a config database inside bgp. That says here are the neighborhood based parameters and name a relationship and numerous number that you need to start establishing a session with, and that is when the bgp state machine located yeah.

H

I hope that clarifies and while I have a mic, I wanted to say that randy did talk about this, but we've got three implementations of three different flavors and three different uh code bases or languages where this extension and protocol is written into. So we've got a multiple implementations of this, and some of that will get open source. Pretty soon, thanks.

F

And this is based on some old presentations and um it doesn't go into something that is actually in the protocol, which is what happens when the bgp parameters changes. What happens when there's an established session etc?

F

And those information are actually exchanged and there are um rules for how they're digested.

B

Right and the motivation.

F

For the question.

E

B

Is you know, basically, if bgp is, you know, attempting to hit tcp hard and can't now run up if you're using the default stuff from 4271?

B

You start hitting internal session back off timers and probably the motivation for asking each of the proposals. How do you intersect with things is along the lines of if you, as an example, have a discovery protocol that's running at the ip layer? You know that ip's, probably working and there's a good chance that, if something's sending a discovery packet, it's ready to accept an incoming php session. Whereas if it's uh not, you know, you may end up hitting some of the back off timers and as a side effect.

B

That means when you plug your wire in uh how fast does bgp itself come up so that your fabric can actually be online.

H

Yeah, so um that's a very good question and I think the part of that answer, as you know very well, will reside into implementation. Details and part of the answer would be as part of standards body work. Now, if you recall sue, had a draft in this about a I want to say about somewhere around 2005 2006, where she had suggested.

H

How do you do exponential peer back off uh depending on how how and when the state machine goes down in l3dl, we have solved that very much at an l3dl level to say hey: when does the information get pulled back or says when this the information get re-announced as long as that doesn't flap that is treated like a config change, uh very much saying hey? How many times did you unconfigure a neighbor or configured a enabler?

H

And after that, as the session flaps, you would have an exponential backup, timer that would hit in and then that would go ahead and do the necessary uh back offs from the session reestablishment point of view, yeah.

F

I think we're getting overly complex here, bgp can case of failure, can go, look and say: are there other addresses? Do I want to back off, etc?

F

This protocol merely provides you the list of people willing to talk bgp to you and what flavors they want to talk your choice at the bgp11, so you can fail with one of your peers addresses and go for a different one, but that's not what we're trying to solve here. We're just trying to find you the list of peers discovery.

F

Is the key word I think, for this meeting.

B

So I I agree with your assessment there I this as presented handles discovery perfectly fine. One of the discussion points that's been raised is how quickly do things establish once you have discovered appear? I will take your answer as not currently discussed in this proposal.

B

C

I'll um then, after you, I have one discussion point because I wrote with jeff's health and other people's help. The fism for the 75 70 for bgp right now go ahead.

H

Yes, thanks speaking as a working group member and a working group chair uh jeff, I think that's a that's that's. The last point that you made does deserve a a set of text, at least in the solutions where it says: hey. How do you handle that um and what is an impact with fsm, even when there are no changes that are needed? I think a description would be helpful at the minimum.

B

Right and then the motivation for the the question having dealt with uh misconnectivity issues and you know existing bhp implementations. You know this is to randy's point. Bgp already knows what to do for these things. Unfortunately, part of what pgp actually does in the field for these things is the you know, existence of some sort of connectivity issue where it's configured it thinks it's there tries to connect and fails. You know the the back off. Timers can get in the way of fast pure, bring up and forth something that might be like a exchange point.

B

Router might be. You know, evgp up here to an asbr for internet purposes. No, those timers may be okay, but if you're trying to actually get things working for a fabric, your bring up and failure times might be more important, as you have technicians, basically moving cables around your your uh your racks.

B

That's that's the motivation to have these things discussed.

F

B

E

Just wanted to contribute.

F

More words to this discussion.

C

Okay, randy, I um did you have uh jeff, did you have any other? uh Excuse me randy. Did you have any other points you wanted to.

C

Make not on that particular point, but on anything else, and if is that in the chat saying.

F

No, this is impolite to the next speaker.

C

Yes, okay, I will stop here. Let me go on to the next one.

C

We'll start with that.

C

By by the way, folks, given we've allowed these discussions, the first discussion to go along, we will probably go 10 minutes long. That's probably the chairs problem and I'll. Take that as I should have pulled the rip cord on robert sooner uh go ahead shiva with this. We you will have a full 20 minutes to uh 11 40.

C

uh asian. You will start uh about 11 45 and we may go as long as 12 15.. This session will stay open to 12 30.. Thank you.

D

Thanks, so uh are you guys able to hear me like I just wanted to come before starting hello.

C

D

Yeah, okay, yeah uh next slide, so the this is a uh proposal that we want uh that came out after the autocorn concentrations. Draft has been brought out by the ietf area area.

D

I dr team, and the scope of this particular auto discovery protocol is to is limited to the cloud data center networks, and the first thing that we wanted to achieve through this auto discovery uh protocol is to reduce the amount of configuration on the in the devices used in data center, and this is primarily scope for the layer, 3 single hop connections and in line with the autoconf considerations.

D

Draft we are trying to the the protocol is trying to bring propagate the minimal transport information required for the bgp to bring the initial tcp connection up uh next site. Please.

D

Yes, uh so the service advertisement protocol, it is based on a udp multicast protocol, and it will support, for it will have support for both the ipv4 and ipv6 uh service discovery.

D

The messages are based on tlb format and the protocol. How the working the internal working is that there is a initial advertisement with all the required service, bgp endpoint information advertised with an uh its validity, uh its lifetime validity, and it is required for the service advertisement protocol to basically refresh all its state before the before its timer expires. The validation validity time expires.

D

We wanted to keep this protocol as loosely coupled with bgp as possible in order to avoid uh constant, complete, constant interaction with uh bgp protocol running on the devices next, like this yeah, so the protocol packets, uh the messages that we are going to be using in uh are of con are of two types. One is the service advertisement based message and the the other one is the bgp advertisement message. So these both messages are would be included in a protocol pdu, which consists of header containing the version length of the message and identify this.

D

This particular identifier make sure that we know which router we are communicating with which router the local device is communicating with and ensures that.

D

D

Ensures that basically, we can always determine the device that this particular uh pd was sent from.

D

uh Yes, next slide, please, yes, uh the service advertisement base message is a base message for this particular protocol, which consists of the uh mandatory parameters that are required to send, along with all the other messages that we send in this particular protocol.

D

This this contains tlvs primarily contains the tlvs that that are the lifetime of this particular information, and it is, uh it is definitely driven by the sender because it lets the receiver know that this particular information is valid only for a given amount of lifetime and the other one is the config sequence number. This uh helps the receiver know if any state any state with respect to this particular transport endpoints has changed by the time this particular message has been sent and the other one to promo to provide security for this particular packets.

D

We had included the authentication tlv as well, and this particular authentication tlv consists of the verification information that is required to basically send the packets. uh I mean the hash values uh calculated with the configured authentication mechanism on both on the sender and the receiver.

D

Next sorry, please.

D

Yes, uh now the pdu that is concerned with the bgp auto discovery mechanism, it again as uh mentioned earlier, it would only propagate all the minimal transport information that is required for the tcp connections to be established and uh bgp can take it from there to negotiate all the parameters that are you done as currently in through the bgp open messages the tlvs that are propagated in this particular measure service advertisement messages are the local address. This is primarily the peering end point the transport endpoint.

D

The sender wants to establish a connection with, and the other one is the ttl value. This is a tcp parameter and then the security authentication.

D

This is not the hash value that we use in the service base service advertisement based message, but more about the uh authentication options that the sender and receivers bgp sessions should be using to establish the bgp connection.

D

uh This could be either the tcp, ao or md5, or could well be the uh keychain mechanism as well, so that- uh and we need to include uh a unique id uh that that is already synchronized along on both the devices, and this could be used by the bgp protocol to bring up the bgp tcp sessions and uh ensure that the security of the security of the connection is still existing and now the link address.

D

So this link address is primarily for a case where we might want to uh establish a connection with the loopback address. But since the connectivity is not existing to the loopback address, we would be sending a link address on that particular link. We could use so the receiver could use to reach the the sender- and this this can be either of the v4 or v6, and uh the link local address could be a v4 and v6 as well, and the last one is the transport preference.

D

uh This again is uh just a recommendation from the sender uh to the receiver, about which particular uh address family that the receiver should prioritize in establishing a bgp connection. So this basically denotes uh whether this receiver should prioritize v4 or v6. uh Pairing addresses uh transport endpoint to bring up the bgp connection and uh yeah next slide.

D

uh One important consideration that we wanted to go through was what should bgp do on the expiration of the transport information received over this protocol.

D

It is important to consider that the protocol, this particular protocol exists to bring up the pgp connection initially and as we want to keep it as loosely coupled as loosely coupled with the bgp in regards to the flapping or the termination of bgp session. So uh two possible approaches that.

D

We are proposing is there could be one uh there? An operator configured interval for the auto discovery protocol where once the the transport information expires, the uh and the state is if it is not not refreshed. After this particular operator configured interval, we should bring the bgp session down uh and the other end is the other possible recommendation. Is the sender itself which is not uh willing to keep the connection up with this particular neighbor could uh terminate the bgp connection and for uh and for this particular approach.

D

We think that, uh right now, all the uh notification mechanisms that we uh use uh are usually uh make the remote and to retry the uh bgp connection again. So for this case, uh we would like to propose an another sub code for the c's notification code. uh That would let the receiver know that this particular connection should not be brought up, should not be retried again and let the auto discovery stay protocol.

D

Take care of what the new transport information that the the receiver should use to bring the bgp connection back up uh next slide.

D

uh Change in- oh sorry for the typo uh say suppose there is a change in transport information.

D

uh The receiver would know that this is from the same devices earlier from the identifier that is put in the header of the service advertisement protocol and with the appearing address uh the local address tlv, which show which lets us know that this is the peering address appearing endpoint. We could determine the bgp on the receiver and determine that there is a change in transport information that needs the receiver to flap the bgp connection and bring up the tcp connection again with the uh neo tcp parameters as propagated by the sender.

D

These parameters could be authentication which, when changed, would uh require the bgp to bring up the connection again with the new parameters uh required.

D

uh And yeah the conflict sequence number is the uh one particular number uh the tlv, and these are in the uh base message that is used for uh that should be used for a uh to.

D

Let the receiver know that there is a change in the transport information that the bgp will be using to bring the connection up. Thank you, yeah.

C

So shiva, let's go through a couple, simple questions.

C

uh uh And cossack, I see your uh hand in in the queue. So tell me: what's the information, what's your target, are you targeting the data center.

D

Oh sorry, so yeah we are targeting the data center environment and the state is, would be basically cached by the service advertisement protocol on both the receiver and the sender. Okay,.

C

And since you're targeting the data center, can you compare and contrast since you've seen randy's presentation, the difference between your presentation and the state, not the mech that you're carrying in the state that the uh l3 uh that the present previous presentation is given to you.

D

C

D

Yeah, so the uh the one important thing is uh the propagating of the uh afi safety, along with the pairing address to let the remote endpoint know, which particular afi and routes will be uh exchanged over the session and the other one was the bgp uh related parameters that was that were propagated, such as the uh as number in that particular message.

C

So, though, those could be attributes that get passed in the other protocol is. Is that what I understand from you just your last comment.

D

uh Yes, that's right.

C

Yes, they could be okay,.

D

C

We essentially have state as jeff is like to say: the state past is the same now we're talking about the mechanisms is that is that correct? Okay, then I will let uh care did.

E

C

A sheriff's comment, or are you doing a working group.

H

Comment uh what working group co-author comment? Okay,.

C

If it's a co-author, are you co-author on this draft or on which draft are you referring to care? I think.

H

And I just wanted to quickly say that the office offices are also carried in, and here.

C

That was my understanding as well. So as far as I can see, these two proposals are carrying the same state information. Do I understand that correctly care or randy.

H

That is correct.

C

Okay, so now we're talking about mechanisms for passing, I just want to make that that we're we've got robert's proposal is over here outside of the data center. These two proposals are the same. The state they're carrying is the same. What we're now looking at is, what do we think about the mechanism for carrying cossack? Did you have a specific question for the author.

A

Yes sure I have one specific question uh just for this: can you go ahead? Okay,.

C

A

C

Just give me a minute, then: did you have some response on the on that I needed to follow up to care on the on the state information.

D

C

Okay, thank you then kasich. Please go ahead with your question.

A

Okay, this should be quick uh sure. I've been cut like so I'm just trying to understand like the two parts, so initially sa advertisement and then bgp advertisement, and you mentioned that it is used as udp multicast based protocol for sending the advertisement like. My question is like how do we kind of initial bootstrap or configure like how do you know that who are the kind of multicast peers and who who sent this message kind of? Who is the sender and who is the receiver? How do we handle that.

D

uh The sender is basically denoted by the uh id information that we pass along the service advertisement, packets and the uh based on the interface on which we receive this particular messages. We could. uh The receiver could determine, uh or basically the sender, being the sender that is sending the information base. Yeah. Sorry.

A

So don't we need to configure who are the receiver for uh kind of initial configurations that needed? Where that the udp multicast will.

D

Go so in in the data center environment that we are targeting its uh it would be uh connecting to the appearing endpoints on all the interfaces. uh Okay, it has yeah.

C

Are you saying, are you sending to a multicast group.

D

C

Okay, so you're, assuming that the layer 3 multicast group, will reach all of these uh other players and that uh the data centers uh have enabled that group to be sent. That's that's your.

D

Assumption uh that's right. Yeah.

C

Okay, thank you. I'm I'm just trying to be clear.

A

I think that's.

C

K

I'm sorry I mean I like to add it on right. So when this protocol comes up, it will register with that particular multicast group right.

E

K

Then that, and that will enable the devices right that will receive this by this packets right. So the kind of configuration we are envisioning is right. It's a it's! A pair interface configuration, so you can so you can kind of template configuration that kind of break on the pre devices right in a predefined manner, so that all these uh all these interfaces, uh the the protocol- will start sending the.

A

But also kind of I see that there might be a lot of multicast message. Exchange would be going on right, like because each pr might be in a data center having a peer-to-peer connection, and it depends on who is the sender this.

K

Is a link? Sorry, this is a link level, information right and it's also a predefined configuration that user continued on, and it's also the implementation wise. There will be a smartness built in the implementation that will put it on the spec itself right so.

E

K

E

K

Enough to figure out when to send aggressive when to send that's lower down the steady state. Typically, it's a lower down the timer in the in. In the initial bootstrap side, it will be probably a little aggressive.

C

Okay, so thank you for this case of being a bit smarter, as you noticed when I sent a note to randy about multicast storms, I'm going to ask you: have you implemented this? What sort of load does this multi? Does the l3 multicast do? How do you know that you're, not you know, blasting everything.

K

It's the smarter reasons I.

C

K

Might mean to say that it will probably not enough. Second, it is on the scope of the interface right. The assumption I have is right uh with the per interface level. In the order of seconds uh it will not be the multicast.

C

I think my question was unclear. um Cossack, uh I think you're done with the q. Is that understand that you finished I'm gonna, let that go to randy. um Go ahead. Randy, ask a question.

F

So, at a high level, this and l3dl are quite similar. You can screw with the uh packet formats, etc, etc. This is doing l 3, udp multicast, for discovery, as opposed to a layer 2. in player 2.

F

We do have the ability to decide, um from the center point of view, the flavors of mac used to either pierce switches, intermediate switches, etc. We don't see them too much in the data center, but it's um we got pushed in and specifically went into that because the lldp people are very concerned about that area and it seems reasonable. So you have to be able to transit, media converters, switches, etc.

F

um Even in the data center, um the we can in either of this or else video, you can start tuning back offs and packing and all those things um the question is really is whether you want to trust l3, multicast, udp or l2, and that's just, I think, will eventually come down to a preference.

C

And I will go with randy that that's uh at a at a high level. I think that's what I would guess as well.

C

My question to you, shiva and minto is: have you implemented this? Have you looked at this problem because now we're down to same information as randy, clearly put it l2 or l3 transmission?

C

Tell me: how have you implemented it? What problems have you seen.

K

So so one one one thing before.

C

K

Into the implementation right so yeah, so we have seen other protocols right, osp of uh ospf and ldp and other protocol using the similar mechanism right. It's there's some the multicast packet right. It's we. We are kind of using the similar lesson.

E

K

There, on the second one regarding the implementation, we we we have, the we don't yet fully implemented it, but the base protocol we tried it out, so we will going to implement it on.

E

We have a smaller.

K

Prototype, that's uh that's! The initial bring there's some appreciation.

C

Okay, I'd be interested in that second uh ospf and isis use specific group addresses which have been carved out by many people. So I was trying to dig in to see, but yours could be another one. Any other questions folks before we go to the next.

C

Presentation final comment: shiva or or minto.

C

Okay, well we're going to be a few only a few minutes late. Then I'm going to bring we're going to switch for away from the auto configuration topic. Thank you very much for randy uh for catching us up on time and for shiva, and the chairs will try to do better about keeping people to time. Next, we will be a few minutes over a june. Let me pull up your slides.

G

C

I can hear you just fine go ahead just and I'll.

E

Run slides, okay,.

G

So uh here we we want to uh uh do some update and discuss on the vpn prolific orf solution, so this doctor just replaced the previous rdr soft yeah motivation of this practitioner.

G

Yeah, I just said, describe the update and the previous idea of the solution, and we want to reach consensus and proper the solutions and afford the updated solutions. Okay, next.

G

Yeah we have printed the guitar.

G

Intermediate and we, I think the ideal experts have consensus and problems uh for resolution.

G

We have discussed on the main list and also we have discussed with clear and susan of an offline discussion. So based on the comment from this discussion, we have made the updates okay next.

G

So the the main content for the updates is way under the optional tlv field. Within the previous rdof encoding uh country, uh two optional q are defined in document. The first is the source. Peter way this here, you used to indicate the source pe of the excessive vpn prefix.

G

The second is the target tier way. It is to use to indicate the target at associated with the excess vpn prefix.

G

G

Yeah here I just uh give the example for the application of the source ptla from this this graph.

G

We can see that if we in the intro is unique, rd scenario- that is uh all the all the rd in different pda is the same for for vpn1.

G

So if the psa p3 is sent out of the excess vpn and it will overflow, the vp vrf on p2.

G

Based on the previous version, if the p2 sends only the rtof message that includes only the rt information, for example- rd1 there, all the vpn, vpn prefix framework, pur and p and p3 will be filtered on ir. So the communication between the p2 and the p1 and between p2 and p3 will all be broken. So this. So we to to fix this issue, we think it is necessary to end the source information of the overflowed pe overflow p information.

G

So um if the p2 sends the vpn previous rf4 with the rdiva and ps3 info, so the r will filter the vpn prefix only from the p3, so the p, the communication between p1 and p2 will be continued. So we think this is the reasonable solution.

G

Okay, next slide.

G

So this is the application of the root target tloa.

G

So in we also discussed the scenario for intros multi rt scenarios, so that is to say, if the excessive vpn prefix associated with several rts, for example, rt1 rt2 from the p3 uh and uh such excessive vpn vpn.

G

Overflow, only the vpn one on p1 uh and so in previous solution. The p1 cannot send out the rdr of message, because the vpn tool also want to search and p1 can only send out the art of message. Only one all of the vpn is all of our floater.

G

G

Updated the solution, so when one p1 detector, only one of these vpn is overflowed, it can send out a vpn prefix with rd set rdc and also associated the uh overflowed the the rt root target of the overflow vpn, for example the rt1.

G

So in this situation the r can filter such of excessive vpn on behalf of the pur. Okay, next slide.

G

So the summary of the update is, we think the additional information can give more flex for flexibility for the device, for example the p and r to finally control the excessive vpn load and the communication disruption among pe pes are real number controlled and our additional information can be added later, if necessary.

G

G

Yeah, we think such updates can address the comment from from the from robot doctor has mentioned earlier, that we should, under the art information for the field hexa. So we analyze the scenario as I want to use the rd and one to use the salty, and I want to use the rt information. So andean is information.

G

Unnecessary on demand um can kill the final control of the excessive vpn medium prefix, okay, so that's all we. We think it is the right time to adopt the update draft if there is no more comment.

G

Okay, thank you.

C

C

Any comments, I'll take one more question. I realize we've had a long interim, any more comments or thoughts on this proposal.

C

Okay, we'll give you a little bit of time to comment and then we'll try an adoption, call and see if everything looks fine, probably the beginning later this week, so the authors can get some feedback prior to the itf draft uh quota.

C

Anything else uh for this discussion.

C

I want to thank asian for being very quick on his presentation and for randy and shiva for being very uh snappy with their presentations uh today.

C

Okay, if that's it jeff any final comments or care.

H

I am good thank you so much.

B

I think my only other comment is uh alvaro sort of reminded us. We do actually have an lodp uh proposal, that's out as well, and that does have some deployment. uh But that said that, not completely speaking for ac, but I'm participating on the draft. uh The conversation that's been trying to get moved forward across.

B

All of the proposals has been, let's make sure the important pieces of the core states all present and we're all steadily converging that direction and, as was noted earlier in the discussion, we'll probably end up having a lot of our preferences for this chosen. Based on you know what transport mechanism we want and it's even possible that the right answer might be to carry the same state in more than one mechanism, depending on what your deployment considerations are.

B

Beyond that, I have no other comments.

C

The conclusion we'd like to hear more about that. uh We may offer ac a uh one more virtual interim on this if to get his protocol. I scheduled these interims uh on his vacation time. So we'll see what we can do, but I I think, like jeff, we are converging on the same state as being carried in the protocols, preference between l2 and l3 and we'll talk about acs. Probably in another interim. Thank you all, and we see you at itf, 112.

C