Internet Engineering Task Force 104, 28 Mar 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF104-LSVR-20190328-0900

Description

LSVR meeting session at IETF104
2019/03/28 0900

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

A

B

Hello, everybody welcome to the LSB our working group session this morning, so we have about 90 minutes to go. We have a know, a reasonable agenda. Today we have a little bit of slack time, but you know it really depends upon. You know how the discussions actually go. You know during.

A

The sessions itself.

B

So to kick off weights first, only at miss ravier, so we have a jabber scrap victor is gonna. Take you know the honors. Unless there is somebody else in the audience willing to look at the jabber thing, so many volunteers, then the minutes is like another moment actually glare at your screen, any volunteers from idiots okay, so we have like Thank You Nabil. So if like two people to look in the minutes and Sony and Nabil, thank you for that.

B

So it will be an easier path if you would like to contribute, feel free to actually open it up and type in. You know and help typing up for the immediate service very appreciate. So the next thing is the note. Well, if you, if this is the first time you see the note well this week, not really sure you have been attending ITF a lot during the week either, so it probably been exploring you know product or much. So we generally says that you know whatever you say and do over here.

B

You know it's gonna be part of the contributions of IETF, but you know- and you know so, if you wanna know more about it, just read this thing so from the next steps perspective. So where are we from the LSB our deliverables? So we started about a year ago. We are now on a year into our timeframe here, and you know the initial game. The initial plan actually was to have, like you know, most of the drafts and all ready for submitting, as one words we're gonna discuss later on. You know where we are.

B

You know at this point in time from the drafts perspective you originally it we also were planned to actually have like another interim meeting. Now we didn't really do that because, just after the new year it was a little bit. You know tricky with everybody's agenda. Now what same time, we also need like working group, alcohol on the main draft and that actually required some work. So I think the interim actually was not really justified to do it at that point in time. So.

B

The agenda for today we actually have four main topics.

B

From what you will see so first we're gonna, be you know getting an update on where we are from the llv lsv perspective. So what actually changed in the latest draft and some other updates, then the second topic we're gonna be talking about here. It's like a use case of the LSU V technology. It's not really associated to what LS vr is exactly about, but because it is actually a technology using LS v and because Eloise actually adopted in this working group.

B

You know it's interesting to actually have some awareness of what actually is happening there. So that's gonna be like 15 minutes and I'm. Gonna know the planets to keep it to 15 minutes and not longer, then.

B

The next topic we're gonna be discussing is the synchronization with the I Triple E, so I'm gonna be mentioning it later on also in the working group here, so we have centrally as all towards my Triple E, regarding the allows UV technology and to let them know about it, and the I Triple E ashes has received that well and yes sends like a response back. um You know their perception of you know what actually is happening here then.

B

At the end, we are going to be discussing the latest updates about the lsv, our BGP SPF and K euro AC is gonna delivering the presentation. That is the agenda. Omar oh hi,.

C

I wanna just clarify that point. Where Paul is this speaking, those are two separate points. Sorry say again right there we're talking about the liaison mm-hmm.

D

C

Said the ASR? No, the pv2 proposal update Paul as the speaker. Those are two separate items were they're the same item so.

B

Looking at the so he's gonna be discussing from from looking at the slides is going to be discussing, you know the alias or response very short overview. What actually is- and he will also discussing what the L of the PV to technology is about correct, Paul, okay,.

B

So any further agenda bashing or we're all happy. Everybody smiling. You know amazing.

E

Yes, yeah: okay, but if you go back a slide, I just wanted to call out that the yang model work is underway. Some of us have been focusing on the implementation, obviously, and as part of that, we've been trying to define. So if there's anybody who's working, also independently we're happy to work with them: okay, yeah, because it's one of the deliverables.

B

And right now it's nope nope. You know in Orange state anymore, it's more like in the red state. Thank you this, where we are from respect of the milestones and undeliverable, so we have most of the work ready. The young is what you know Kay you actually mentioned, so it's actually in process of being created.

B

Now when we started the year ago, you know we're actually were not thinking about LSV as part of the LSB, our working group, but we in the meantime you know we did like a call for adoption and the work actually got adopted into this working group here. So we actually have this now as a working group document, because it is really you know a technology like that. Is you know key for link. You know, for our link state vector routing to behave in you.

F

B

In a correct way,.

B

So another thing: what happened since the last idea is: we did like a working group last call for bgp SPF technology, the bgp SPF draft. They actually run from the 3rd to the 17th of december, and a number of you know: good feedback actually were received from that one. And if you look into the working group list itself, that has been the key discussion items actually know during and on the working. You know on the working group email list itself, which is a little bit.

B

You know, which was good for the programs of this particular document and based upon all that feedback. A new document actually has been, you know, progressed and we actually are processing the lsv our drafts itself. From the Eloise perspective, there actually was a option called on and we actually go to the topless on 24th of December.

B

Another thing actually happened is during we actually were. We have been contributing in creating aliens all towards the I Triple E regarding the Lea set of Ethernet, because in essence we actually are fiddling with layer, 2 technology here and because you know from an historical standardization perspective that has been mainly you know, part of the I Triple E activities, so it was required, maybe requires the strong work.

B

You know it's like very actually a good thing to actually to let them know that we are working on this, and that was like no misunderstanding, so we shipped that one out on the 10th of January, the I Triple E, actually has received that and actually triggered them to reinvestigate what lldp actually is about and look into potentials, ways of extending it and creating like a next revision of the technology, taking into account some of the properties that technology like links that Victor actually know requires so the release, the liaison response is actually on the attribute, workgroup, page and I think very soon will also be on the ITF site itself.

B

G

So a cylinder waiting for a good time, I read that response and I was thinking. If we reach an impasse here, couldn't we just put a 20-byte header with a multicast address in it and and terminate the discussion if and and keep the protocol intact.

B

What do you say if you go to an impulse, we're not there yet so I know but I read it read. B I read the response, that's that's what the response was out of. You know there were like two elements to it, and one element is like you know. The name is confusing, so that is the easy thing to fix. The second element actually was like means, like you know this layer to technology, and maybe you know it would be more interesting to just extend lldp. You know into the next version.

A

G

And avoid that.

B

The industry actually has like two technologies and actually you know I think that's as.

G

I'm saying it might be easier just to get an eye. A local wire multicast address an IETF and put the twenty by Tanner in there.

C

Alaura thought is a quick comment. The formal creation did come in yesterday yesterday.

B

H

Just to respond to John Scudder to ACS comment, I sort of had the more negative reading of the the liaison that that AC did and and whether from that you conclude that you should like do a little process workaround by slapping on a multicast header. That's another question: I mean I I'm, not sure. If I had been the person who wrote that liaison, if you know adding a multicast header would make me feel like okay, that's fine, then no problem I mean it is a technical work around.

H

But it's not a workaround for a technical problem. So I'm not sure if that's really addresses it.

I

Randy Bush, arcus and iij, um just so everybody knows Paul and I collude with each other. We I don't pay attention to the liaison stuff. He has been very helpful in L, SOE and I've tried to help with LLB DPV too. So, let's not create unnecessary conflict. Here. Yes,.

H

Sorry, John scatter today add one more thing: um yeah. It would actually be a perfectly fine outcome for my point of view to have one as long as it solves everyone's problems, I mean that's kind of what the liaison said, and you know great as long as we can have it. Yes,.

B

I agree and actually part of the journey is that you know we have actually have you know koala volunteer to give an update on the way we are with the you know, with the l-ltp p2 proposal itself and understand timelines and some of the other aspects involved. So there's gonna be discussed about today. Also.

B

Cities are key, you know, like a very short, you know summary of what the you know the liaison was about, but it's gonna be in like impulse deck. Also, so I'm gonna be skipping it. You know for the moment here. You know in the sake of time, so that's it from the chance. No to kick it off here. Unless there is like any other comment, then we're gonna go to the first. You know slot. It talked about the updates about LS or e itself by Randy yeah.

I

I Randy Borgia, hi, Jane, orcas um I, know it's crowded in here. There's room down front. If you need it, that was a joke.

I

Okay, they given you some of the history. This is just going to be an update. You are expected to have been tracking the draft okay I just want to thank some of the people who are here. John gave a number of excellent reviews: Rob of course, Niraj Larry Krieger back at arcus flax layer to clue in to me regularly Paul condoms been very helpful and others. It's now, a significantly more mature draft.

I

I think, let's remember the goal here: okay, we're trying to do link layer, topology discovery and liveness for the control plane of LS vr. Okay, that's the goal just reminder an overview of the protocol. Okay, it's.

I

Conversation happening at layer two to push the discovery of these interfaces up to bgp SPF, who then builds the topology and the address: mapping, etcetera, okay, so you've read the draft of course, so I'm going to talk about what's new, the first thing is surprising and you'll get to hear from it.

I

Neeraja has extended it already, which, if you are an IETF traditionalist, you know that's actually a good sign when you get surprised by somebody extending your protocol and he's using it in efore evpn discovering, instead of endless arp snooping so and I needed this to get the cat pictures in okay. So what are the details?

I

The new version have clearly delineated a transport layer of frames that can be used to build very large PDUs and a state machine over that transport. So you can take Ethernet frames and build large lso EPD use. Okay, currently at 64 octet peatones is the limit that could be raised if anybody has made for more be good to say it now before we bake 64k in neeraja is already being very piggy, but I don't think you're gonna hit 64 K. Are you Niraj generated 64, K, okay, oops.

E

Dolorous, but they should be good enough to help support some of the configuration information as part of the discovery that would need to be carried yeah.

I

Yeah so um there's duplicate, frame, detection at the transport layer, duplicate PDU detection at the upper layer, there's retransmission on time, outs, etc. There's also a vendor extension PDU.

I

Okay, so you can add your flavor okay, there's the explicit ACK and error the act. If the e type and error code or nonzero it's an actual error, tells you what the air was, gives you a hint, etc.

I

I

Before we were looking at, do we merge hello and keep alive? Are they both necessary?

I

The current position of the authors is: yes, hello is multicast, so you can discover across layer, 2 device.

I

Okay and the hello has two types of frames. One is the one that will actually transit layer, 2 device. The other is not okay, but hellos. Multicast keep alive is unicast because it's actually keep alive on the link. Okay and you probably want very separate timers for them right. You want to discover your topology, maybe you're, willing to put up with multi second discovery delays, whereas keep alive you may want on the order of a second or less okay. Look at the lessons we learned in BFD, okay.

I

So if anybody would like to try to adjust my attitude on merging the two I'm more than willing to listen, okay.

I

Still open is, do we add a signature to each PDU. In other words, we could very easily have cryptographically verifiable authenticity and integrity checking.

I

We had data center operators who said they wanted it. When I asked what their threat model was, the line went dead right. So if anybody here wants to talk to me about the authenticity and integrity requirements they have I would love to hear it. Two-Thirds of the authors have some experience in doing this kind of thing. We know how we would probably add it, but the customer has to say they wanted.

I

I

In a shocking thing happened to me on the way to the meeting I was brought up. My mother always told me that Macs are unique in the universe. Well, it turns out they're, not as one of my friends says. Cisco and I Triple E have spent the last couple decades, making things complex so currently the identity of a link is the two Macs Larry Krieger has educated me that it probably needs to be two to max, and the Vita and ID I would gladly accept more education on that.

I

For instance, Russ has tried to tell me it's just one of the max and the VLAN ID, but I think that's more of a layer, 2 device and world's having links between layer, 3 devices.

I

Ok, but there's clearly a problem here, we'll go forward. So John asked first state machine, I'm, sorry John, the state machine is not in the current draft.

I

Rob wrote one in Python 3. Instead, it's about the same length as the spec, except it has more blank lines in the desc comments, so wanna denotational semantics. Instead I know how to do that. If you wanted ok and the good news, though it's a predictive piece of news, is that we're waiting for cares, ok to open source, it ok.

E

Cared with their darkest again, this will happen shortly right after IDF. Hopefully in this year,.

I

He's my boss I take his promises with a grain of salt, um but it is when you get to see it. It's the state machine, John you'll like it, okay. The draft of course needs review.

I

Okay prefer to get some volunteer reviewers without having to work in a group. Last call it in order to get your attention so folk with eye on it would be helpful and that's all I have, due to other constraints, I have to streak back to family problems in the States, so I'm gonna leave here. So please head for the mics. Now.

H

John Scudder, thank you I'm glad to know the the source is the documentation, always sort of a mixed message, but snark aside, I have a question. It's really a question about what you said about security.

H

You said this. The the users have to ask for it and I'm, not the user, so I'm not really here asking for it. But often what I hear in the IETF is. We do security unless the users tell us not to.

I

No I didn't say that I said: what's they have to tell me what their threat model is, so I can make sure the security beats that threat model. That's.

H

That's actually, as the words were coming out of my mouth I realized that I was making the common error of complete, conflating a crypto hash with security. That's sort of like saying oh I put TLS on it and that's the same as securing it so yeah. Shame.

I

H

I

Nonetheless, security you can use IPSec right nonetheless,.

H

I do hope that you know more people in the group of than just you and me are going to have this conversation, because I think it's important I would.

I

Gladly put it in I just want to make sure I'm putting the right stuff in Rob.

J

Austin Marcus co-authors, all joking aside, essentially, what we've gotten at this point as far as security is our threat model? Is that somebody told us we need to have security. We don't know what that means, what we need it, that's as far as it's gotten. You can't design from that. So that's why we're waiting for input I even.

I

Suggested some aspects of the threat model, in other words somebody walking in and plugging into your class or so and so forth, and nobody bid nobody rose to the bait, its.

C

C

If asked this I will forward, please make sure that you put in the in the document the assumptions about security. If, if we say we don't need it or we don't have it right now, we need to clearly specify why so, if we're, assuming that this, isn't it close to me no one's going to walk in and the worst thing that your happiness is, you said I actually walked physically into the thing. Please you'll talk about that. It was that way.

C

It's you know a way to justify the lack or the fact that we don't have it right now. I.

I

Think the sec cons does that.

I

I will be laughed out of every coffeehouse in prague. If I have a cyst pub me if I go for working group last call with the sec constant, is we don't do it? The.

C

Other thing that may be nice is if we go and request security Directorate review beforehand, so that we don't have, you know last-minute surprises, and maybe you know, maybe that all these justifications would.

I

K

Victor coercing hat off user on weekapaug I'll supply, some more information in the list, but probably one way to look at it, and I can I Conniff. I this statement is that no devices are trusted in a lot of fabrics. So the assumption is that you cannot trust anything that connects to you and that there has to be ways to secure that. That is in fact, a trusted device.

K

I'm, not sure that helps, but I can supply more texture and than if you like,.

I

Are you willing to do a you know, let's make believe your cloths? Are you willing to do a CA for your cloths and have every device have an identity? Oh.

K

It suggests that's highly likely that hat that's how it works. Often, yes, cool.

I

Yeah, we know how to do that.

I

Ladies and gentlemen,.

B

I

Maybe one question.

B

You can yeah just you know you lost, like you actually were mentioning that you were looking for volunteers for like reviewing the work correct. Although you know I'm gonna, ask the question on the list. Also, like you know, is it like anybody in the room here like no willing to sort of like stick up their hands and actually you know, provide a review of the latest LS or document Nabil Chung.

B

Okay, so I will ask the question on the list also, but already thank you. Thank.

L

You so John messenger and I would encourage you to liaise with I triply 802 dot one and use letting mechanisms defined in I Triple E, because we're the guys who know how to do letter.

B

Okay, thank you.

I

You're not yet.

M

Morning, Neeraj Malhotra arcus I am going to be talking about LSA based easy control plane for a VPN networks. So the main use case for this is an EVP. An IRB Network where today see Emacs and IPS are learnt on the PE interface on the PE access interface and advertised in an overlay, bgp evpn control, plane to the other piece to establish both routed and bridged, reach ability across the sea devices. So as it stands today, there isn't a dedicated PC control plane in any VPN network.

M

To do so so, as a result of that see, eMac learning is done based on traditional data, plane, mac learning, see, IP learning is done, based on our pen, Andy sniping and for scenarios where the sea might have prefixes behind it, but does not actually run a dedicated PC routing protocol. These prefixes are advertised from the PE device based on local policy configuration.

M

So as a result of this current learning method, the C Mac learning today following scenarios such as a host move or following convergence trick triggers, is very tightly coupled with how often the C's sending data traffic at that point. In time and the CIP learning at the same time is very tightly coupled or heavily dependent on receiving unsolicited art and nd packets from the C device and when the sea is multihomed to multiple pcs.

M

This learning is also subject to the fact, or each PE must also handle the fact that these data plane, ARP and nd packets, as well as the data traffic packets, can hash on any of the member links of the lag and can arrive at any of the PE devices.

M

So what is proposed in this draft is a PE C control, plane option such that PC Mac learning or the C Mac learning is fully decoupled from data traffic received from the sea. See.

M

Ip learning is fully decoupled from our Penn ND packets received from the sea and the goal of this being two to two essentially following convergence events and following hosts move events to have a very reliable and consistent convergence, behavior and, at the same time, significantly simplify some of the procedures that are currently in place to handle these convergence scenarios, especially when, when you have evpn all active multihoming in the picture.

M

So a quick overview. The control plane is essentially based on LSO e as the base protocol and on top of that defines procedures and tlvs for overlay, mat, learning for overlay, host, IP learning and overlay prefix learning it defines procedures and handling with respect to when you have a VPN, all active multihoming for the C devices and discusses the use cases that can benefit from this optional control plane.

M

So it's fairly straightforward in terms of the mechanics of it. It's mostly writing on top of LSO e each. So the P device establishes an LSO a session to the C device on the PA attachment circuit overlay, tlvs format, learning mac to IP, binding or other IP to Mac, binding learning and prefix learning is sent from the C device and learnt on the piece and advertised further in evpn control plane.

M

And then you have session liveliness maintained via LSO a keeper lives when the C is multi home to multiple P device, and it could be more than two devices.

M

It's just shown here with two devices: a separate LSO, a session is established to each of the multihoming E's, and this is really important because it now gives each PE the ability to learn its entire state directly from the sea without having to rely on the other PA devices, and this brings significant simplification to our multihoming to multihoming, simple implementations from handling perspective, because now you no longer have to sink the Mack tables across the P devices.

M

You no longer have to sink the our Tandy tables across the devices and the P devices no longer have to handle unsolicited arts coming from the C device, as opposed to. In the current scenario, an arp request would be sent from p2 to the C and the response could land at p1 which must handle this unsolicited response. In addition, because of because of that non-deterministic behavior as to which P's might learn the Mac or the Mac IPS.

M

Today we have procedures like evpn aliasing, to accomplish ecmp paths for mac forwarding and that that again becomes optional. Once you have natively learning the Macs and IPS on HP device, the other complexity is for IP ecmp.

M

Typically, today the implementations, sync, the Mac IP route to the other piece and then the other PE typically will really generate that Mac IP route as its own to accomplish IP ecmp because- and that's essentially, it kind of I mean there are some proposals for IP aliasing in place, but that's the current implementation in the absence of an IP aliasing procedure.

M

When a host moves today when a host moves, the only way to detect a host move is when you receive the first data packet from that host. If the host is silent for an extended period of time, you would continue to black hole traffic to the previous location of that Mac until the Mac ages, out at the old PE location of that Mac, and once the Mac age is out.

M

If the host is still silent, you would continue to flood the traffic on the overlay until until you've actually learned the Mac at the new location, so just to take a closer look and appreciate the actual complexity involved. Today. With respect to handling a host move, essentially, when you receive the first packet from the host that packet triggers the hosts move event in hardware and typically, it will be sent as a packet punch to the CPU or sent as a Mac move event to the CPU.

M

Once the software learns of that Mac move event doesn't necessarily guarantee that you would have also learned the IP bind IP to Mac binding at the new location of that host, because you may not have received a graduate result from the CEO at that point. So, based on that mismatch between a remote Mac IP entry in a local Mac entry, the PE will typically trigger an earth probe to the seal, and the probe reply could, because of the multihoming, could easily land at the other PE, which would then advertise which would then handle this unsolicited.

M

Our reply or nd response and trigger a Mac IP advertisement in BGP control plane, as well as sync that Mac and IP to the other PE, and that other PE device on receiving the sync entry to accomplish IPE cmp will typically again three originate that mac IP route.

M

As its own route to the other p, then the other piece received these mac IP advertisement, the old PE, where this mac was originally local, will trigger a probe again locally, the probe that will fail and typically aged out, and you would have convergence following the host move, as opposed to that with LSO e. It's fairly kind of simplified right, pretty much. The host moves establishes an LSO a session sends its tlvs, the TLB czar learnt and advertised in a VPN control plane received by the other piece, and you have convergence.

M

So another use case for this is remote mac. Ip routes learned via bgp evpn overlay control. Plane can also be preemptively, relayed to the local c e, essentially to establish preemptive ARP learning on the c, essentially like a ARP suppression mechanism for scenarios where the C II has prefixes behind it, but doesn't run a routing protocol on the PE, see interface today, advertisements all for those prefixes behind a C, II gateway are based on local policy configuration on the PA device.

M

So again, this one local configuration overhead can be replaced with sending these prefix overlay prefix tlvs il SOE from the C e to the P device.

M

So in summary, basically two main sort of goals that I would want to highlight for this is one essentially trying to achieve a very deterministic and reliable convergence behavior across all convergence triggers and host moves at the same time, significantly simplifying some of the procedures and implementation related to these to the respective handling, especially in case of an EVP and multihoming scenario. That's basically.

G

Ac Linda I think this is a really good location in it and it it it. It really makes things more active rather than passive. In the whole thing, the only problem with it is it brings these C e devices. You could never get rid of the old. You know the the passive way in the learning way of doing it, because it brings them into the e VPN and getting those devices updated with this and many even if it's open source with many times, that's gonna, be just administratively impossible. Yeah.

M

Sure so I mean one thing I would want to kind of highlight is that it is an optional PC control, clean and not a replacement for the current learning method, and it's totally intended to be to coexist with other C devices in the same network that may not be using this control plane. So it's basically, it can be used where the C device has support for it, but it's, but the goal is to have it in to work with other C devices that don't have support for it.

D

Robert Rochefoucauld Bloomberg, so I have a question just to clarify I care, less about muck learning. Okay, so I want to have l3 learning, which is soft so on this light. So is the goal here so use this kind of LSO e4 l3 prefix learning, as the only application in some cases can I use it. That way, you.

M

Should be able to write like I mean basically, so each all the TL visas are optional. Essentially you can. If, if the C is sending Mac and IP tlvs, you would learn, you would use them for mac learning or host IP learning, so the routing application again can be based on prefix routing or it can be host altering right like. If you have truly an overlay subnet stretch, then you need to have host routing. So essentially, then you would use the host routing PL, V's or the slicer read or / 128 tlvs as well.

M

Otherwise yeah you could simply use them. If you have the other use case of you know the C being the Gateway first stop gateway for prefixes behind it, and you want to advertise those prefixes with the C e as the gateway. Then you could use it essentially for just the prefix learning. Okay.

D

Dude having interaction in kubernetes communities or any other outside of you know, ITF with this kind of proposal are you proposing? Is there make it more real.

M

Not yet I mean nothing, nothing, no progress on that front, yet hi.

N

Paul Kong did I wonder if you have, or maybe could provide in in some future contribution a more kind of concise description of the requirements. They have a protocol to support your needs. You know what exactly is needed out of the protocol in terms of you know, maybe timeliness message, sizes responsible, various attributes like that because it strikes me what you did was you. You know you said here: we've got a tool: l SOE. How do I use it right and I'm wondering if we could take the reverse, look and try to analyze?

N

Well what other solutions might be there or could be there to optimize your requirements? Ya.

M

Know certainly very good point. Actually we should. We should take a closer look at sort of like what might be the timing requirements, for example, for keepalive messages and so forth.

F

Yeah short cash I have a question actually I, guess in service provider deployments C and P devices supported LDP. Have you studied the 4 with respect to the MAC addresses what can or cannot be achieved with the current standard? Dp.

F

Sorry with lldp, did you say a toe to toe on a b link layer, discovery, protocol, okay,.

M

So basically, so the main main reason for kind of picking LS OE to do or to achieve this was and a couple of attributes of LSO a one it being session and connection oriented and and being able to carry very large tlvs in it. I mean I I personally haven't taken a closer look, I mean maybe k you can comment. Perhaps it would be ethical yeah.

E

Kayuu patel arcus. I think the answer to your question lies in the fact that when you deploy a technology like EVP ends, neither art nor lldp comes into the play there. You do more of this kind of resolutions that near as you was talking about from the data path, learning and the data path. Learning is not deterministic, it has convergence impact and it adds lot of complexity to the software which hopefully neeraj try to articulate it pretty well up here and that sort of complexity can be easily replaced.

E

If you have a connection-oriented protocol, that does an implicit announcements and not a periodic refresh. That was the point.

M

I

Randy Bush I just want to apologize I'm, not leaving because of your presentation. All but I've got medical stuff back home and I have a flight that departs in two hours. No.

N

Worries take care of that yeah, okay, hi, I'm I'm paul, kangen I'm doing a couple things here, as mentioned just giving a summary of the liaison discussion as well as presenting a current status of an LD PDP version, two, so to speak proposal and I guess. One thing I want to point out is on that proposal. We're just you know, thats, just an example of how things we could do that match the current lldp requirements or our use cases as well as trying to address LS VRS use cases.

N

There's nothing set in stone here, it's very fluid, so I think things could be adapted as needed. Technically so just as a disclaimer I'm, not an individual here as we all are, but I need to show the fact that I'm just giving you my position or representation of the liaison there's an official one that goes on. That's not me, and so these links were kind of I. Think many of these links were already shown. As discussed.

N

There was a liaison sent from the IETF to the I Triple E, basically giving background about LSO, E and asking for comment, and there was a reply that was sent. So my personal summary kind of what the response from I Triple E was. Is that more aware of this work, I've been going coming here and reporting back and forth, and many people from my trickily come to the IETF as well. So we're aware of the work is going on.

N

The first thing that came up was potential concern about the confusion with a layer to a link state over Ethernet protocol that we've standardized called shortest path, bridging so short path, bridging is actually a topology management protocol is, is meant, you know using link state to manage it, and we didn't believe so. He is actually a linked state protocol.

N

It's in support of a link state protocol, so the naming was a little itself was a little confusing, so I think it's possibly very obvious, but that one of the main objectives of lso II was to provide, as as Randy mentioned, link layer, discovery and and as well as liveness. And so, as we all know, we have a very widely deployed popular link layer protocol.

N

It was also link layer, discovery protocol and it's also understood that the current definition of that protocol may not meet the needs of LS V R, and so we've been entertaining proposals to augment lldp for many use cases not just LS v r, but we had an intention to try to support those or some of those one of the particular use cases. Liveness requirement personally I didn't believe, is suitable for the lldp as it's done today, philosophically, because it's a as as Kara mentioned, is more or less a state refresh, not a highly.

N

You know, responsive kind of protocol that doesn't imply that that couldn't be couldn't be changed. To be more of that, we do, however, have other standardized layer. 2 protocols like connectivity, fault, management, CFM and others that that actually do support loudness and there, and there may be other ways in which a lot of this could be supported, so I think that was sort of also a consensus of the v8 or two group and then finally, of course, we want to collaborate and work on this as well.

N

So we welcome work in the I Triple E to do that care, yeah.

E

Sure, thanks Caleb Patel, arcus I'm did a bunch of requirements. We'd be happy to work with you on that. A lot of those requirements have are being covered as part of Anasuya proposal but, like I, said happy to collaborate. Thank.

N

You, okay, so again, I'm gonna, I'm gonna provide a background of what we're currently proposing to do to lldp. But and again it's it's very fluid. There's it's open that we haven't even started a project. Eight triple-e did agree to draft a project proposal and address the requirements to start such an amendment project.

N

So that's a in the early stages, and so a couple of us have already put forth something and there's a contribution that was made at I Triple E as well. That tried to compare how this proposed idea would would meet the requirements of LS VR that that was that Randy had put together in some previous contribution for the IETF, and then we discussed next steps where we did agree to to consider drafting a proposal, so it just as a quick summary side. I looked at the the requirements, I'll go ahead, no I'm.

C

Sorry go back to the last one just so that we understand a little bit of the I Triple E process. Okay, there's a proposal. So what happens? I mean we understand what proposals happen to the ITF? What happens? What happens to the great okay.

N

So the I took we may actually drafts what we call a par, which is a project authorization proposal that defines the scope and purpose, and you know of a project, and then we get approval through the higher layers of the I Triple E to actually run a project and that project, depending on how its defined would either amend an existing standard. So the proposal would be that we would take lldp and add some new chapters make changes whatever to address the new requirements or that project could create an entirely new protocol.

N

That's that hasn't been decided yet, but there's a project authorization that starts that working group, a work in a task group within NATO 2.12. So.

C

The discussion of whether that car is approved, it's going to be in March.

N

Well, in March, we agreed to jointly draft a proposal and submit it to the I Triple E. We haven't agreed on what the contents of that are. We just ought our working group to actually generate that project proposal, yeah yeah, no, so go ahead and clarify yeah.

F

So, just to elaborate a bit more on this. The first point I would like to make clear that a triple-a to--to is contribution, given same as a atf. Participation is in individual basis same as ITF. Anyone can come and contribute any part of this. This work, so the next step, one is happening. So this listen past plenary we have authorized forthcoming may enter him to specify the project specification.

F

The project authorization request, so the the diverting off the group who would be the host of the project, a 22.1, will be done and finalized in the main interim that can be discussions up to that point and in the interim we can have discussions on the weekly TSN course easy to request agenda item. We can discuss these topics in preparation for it for that meeting and the power text will be crafted at the main time face to face.

F

What happens afterwards is that this power is recirculated for the 802 plenary, which is in july, and if everything goes as planned, the other working groups of 802 review give commands. We update the power and hopefully the power gets approved by 802, and then it gets on the agenda of the next ITA standard association s con meeting. If everything goes fine, it gets approved.

F

We have an official project to run and we can work officially in the project from the Milly meeting on what from the September interim and on TSN weekly course, and we have various ballots, we can make those steps and so on and we can done with.

A

F

100 half years is very reasonable.

A

F

Everything is quite clear or if it, if it is a shorter project, it can be one year depends on how the contributions discussions, agreement, consensus.

B

Building is done just a quick question then, on that one to us follow I'm sorry. So that means you know that the timing would be like between now and like a year and a half to two years to come to something. Alright.

O

O

Dorothy Stanley, so, on the question of the timing, Yanis described the process for launching the project officially and given where we are now not in March. The official launch of the project would as soon as that could happen is September. Given that you know, work in a study group can carry on starting now. The project would be officially started by a triple-a in September at the September standards board, teleconference sessions, and then work could continue and then the duration. The project is authorized for four years.

O

The progress of the work and the rate of the work depends on the topics and the the participation level so, depending on the nature of the changes that need to be made. You could finish in a year year and a half two years three years, yeah.

N

But it's clear: your technical contribution can begin now and has already begun. I guess.

E

Capital arcus at the risk of probably saying something wrong, but, as we understand Paul, you are the lies in between I took Lee and LS. We are on what kozara between the two different parties. It would be great if someone can start updating us with the status of my to police, so we could help contribute to whatever that is needed to the ecosystem and make sure we come up with the right solution from point to point periodically, as there are progresses or updates done within I Triple E, particularly for this set of topics. I.

F

Just want to clarify one point in the beginning, as you said, there is no liaison person, typically like a spore made it clear, he's an individual bringing the letter so.

E

Then that would be a note to the working group chairs to somehow set up a process that way at least announcements would come or if you suggest we should be doing it personally, let us know, but.

N

It is a an individual or con transmission organization, just like ITF, so there's nothing that prevents that from happening, understood.

C

Thanks don't say the same thing: I'm also gonna point out that a gray sitting over there is the official IETF I Triple E, able to that one liaison, so the IAB does have a formally issue program. Now. What that means is that there is that formal process of us sending constantly a story back if we have common participation on both sides like what Paul has been doing where he participates in the ITF. It's here. If we can have people from here participate in the atf discussions.

C

That would be the best thing, because we will have to rely on official things back and forth. Yeah.

L

John messenger I'm, acting chair of 802, that one just to clarify the they may I may enter in meeting is in Salt Lake City from May 20th to 24th, and people will be very welcome to attend there. As Janos also mentioned, we do have TSN weekly calls. That may well be be able to be used for discussion of the technical requirements in this area, so we can begin to work on this in a fairly prompt manner. Yeah.

N

And just to add to that and I intend to ask for a time slot on a Monday call very soon actually yeah.

F

We can arrange that so I just want to emphasize it again. What has been said that the tactical discussion can happen from now on. This is kind of if I would like to try to make an analogy. This is before in idea. Phonology like this is pre-party bar discussion and I, typically kind of before working group adoption discussion in idea so kind of similar stuff. So we can have the technical discussions ongoing now and officially, with the project for September yeah.

N

That there is a lot of discussion on the different processes between IETF and I Triple E. They are not so different in many ways and- and that is documented on the coordination website between the two organizations- and we have a lot of history of working together closely on various things, so there should be no barriers really in that process. Okay, so let me transition into again into a discussion of kind of what Ivy and a couple of other US other of us in have been proposing and again it's very you know.

N

May not there may be many changes that could be considered to this. This is nothing casting concrete I did an initial analysis of the the ideas and how they might meet requirements from LS VR and that's been presented previously. This was simply just looking at the list of information that is being exchanged in the LSO e messages today and determining well. Could we could we put that in an lldp v to TLV and clearly many of the things like MAC addresses and IDs and attributes lists?

N

You know, we believe obvious are very obvious that can be done. There was a question about the authentication data itself. Like we don't know what the security proposal is and how big it is there. Currently, there is a limit to a TLV size in in existing lldp that could be extended as a one of the things that this project, for example, obviously encapsulation addresses, keep alive most one thing so keep alive again, there was sort of a desire for a one. Second type of link.

N

You know, liveness melody p, is wouldn't really work well, if, as unless we define something specific for keep alive today, you you send the entire lldp information when you send something, and so we wouldn't want to send an and everything every one second, so something would need to be done for that.

N

But again we also felt there are other layer, two liveness solutions that exist and are widely deployed as well and then in terms of acknowledging information, we kind of that's an implicit part of this new proposal, because the main objective here is to send more than one PDUs worth of data. So, in order to do that, you immediately bring in the need for acknowledgments and things so so that was a summary. Have a look at that and you know, provide me feedback or anything that that's fine, AC Linda.

G

I I, don't I, don't know. If you looked at it, we have a we also before L as so II. There was there's a draft that I wrote the bulk up to use lldp and one thing we really need big or tlps, because you know just that. There's the organ 8 organizational specific for the IETF. You could fill that up very quickly and it wouldn't really help you to have multiple PDUs. Unless you could I mean it would really be cumbersome if you don't make the T of these bigger.

E

Okay, k little R cos I'm talking about the same craft, that AC is talking about which, with I, have co-authored and really there are numerous use cases that we want to go attack and like AC say for that. Extending PD use is one thing, but you really need other things as well to make that which would fundamentally alter the protocol, and we should chat about that.

E

Like I, said happy to contribute, but there are more than one use cases periodic refresh. Eliminating them is one of them right. So.

N

That sounds like an excellent topic for one of our phone calls so that maybe we'll get that on the agenda soon. Okay, again, I'll go briefly over a quick summary. You know why were we doing this? Well, you know one of the. The main things was to send more than one PDUs worth of data, but there might be other two other things.

N

As we know, lgp is widely deployed, so it's likely to be there or remain running, even if there is another protocol, so you know having multiple protocols trying to doing very similar things could be not desirable, but again we do need to meet all the different use cases. So and again, the number of things that we keep sending in lldp continues to grow. Every time we add a new standard protocol, we tend to add another TLV and there's a there's millions of vendor-specific tlvs out there as well.

N

So again, we've looked at motivations to people to to do different proposals just because of this PDU size issue. Relying on jumbo frames is not a good solution, as we know. That's that's not very you know it's difficult to deploy in all environments, so at a minimum we need to exchange more than one teal, more TOB sand and lsv. Our requirements are just one example of that. There's we have many other examples. So there's no matter what it's time to do something to lldp, regardless of if it meets all of lsv. Ours needs or not.

N

We're gonna do something I think. So it's a question of what we do. So the objectives were of obviously to send you know more than one PDU worth of data and- and we also had an objective to to even shrink the PDU if we want to support some kind of smaller PDUs for our time, synchronous environments, because we don't want to just blow out timing other protocols that are mixed on the wire.

N

So so by shrinking the lldp PDU, then we bring even more need for multiple PDUs, so so that was something that came up through our TSN working group as an additional thing and of course, one key objective at that that I'm pushing for strongly is the ability to communicate with existing lldp. That's out there, obviously not all the extra data, but at least the first PDUs worth of data I should a version too should be able to talk to a version one and get the exact same capability we have today.

N

But if you do version 2 you get to get this extra capability. So that's an important aspect, I think of our proposal. Here we want to make sure that that this works right of course, and then then there are other things that we can consider if we're gonna crack the book. Let's look at other things like you know, maybe the the rate at which we're doing updates. Maybe we should have new reach ability, so lldp doesn't just have to be linked by link. We can.

N

We can put different addresses in the packet and have it go different reach across the topology, so one example might be define a new address called nearest router or something, and that might be very useful for clients discovering their gateways and where all the gateways that are out there. So any there's some I think some useful use cases there and then finally, one I think which I've just heard today was allowing a a larger TLB itself, so, rather than the currently were fixed at 511 bytes of information.

N

You know making that larger or some method of fragmenting or what would be needed to support. You know that so that those are ideas. So just a quick reminder: how does it work? I? Think everybody pretty familiar with this, but one one, simple concept that that helps think about how this works is. Imagine that you have a your own local database of information and that database can fit in one packet. Well, anytime, I change, something in that database.

N

What I do is I, send it out to all my peers and then they update their copy and then, if something changed, when then they'll notify higher layer protocols that care about. What's in that database, that's a very simple way to think about it, and then you just periodically refresh that information and it's very simple and straightforward, so that obviously works for the well when you have one packet, but when you have more than one packet, it changes quite a bit of the dynamics, so this slides very hard to read I know.

N

But the idea was this current idea again: I want to keep emphasizing. That is that we would require a new TLB, so there's already a set of TVs required in every packet that help you identify the peer, we would add an additional TLB that would be required if you were aversion to and that TLV is what we call an extension TLB that basically a something that defined that identified defines all the other POVs you might be sending so sort of like checksums or something of each packet and that'll be received by a version. One implementation.

N

So the way lldp works you'll receive that information. They won't know how to interpret it, but they'll still hold it in the mid and it's available. So it doesn't break anything. It's just opaque data to a version one, but that new TLB would would again define all the other extensions that I want to send. It would have some way of identifying each of those extensions, so we could know that we've received them all and again it would be ignored by a current implementation and then that new t-then.

N

So then we would have new PDUs extension PDUs and those would have a different format. At least they would have a something that makes them ignored again by a version one. So we don't want a version, one patient, to wipe out his database every time he gets an extra packet.

N

So we would have it such a way that that frame was ignored and there could be many ways to do that, the easiest of which is just to use a different ether type and then, when a tube person receives the the main PDU that gives the description of all the other PDUs. If he doesn't know he doesn't have those those PDUs, he would send a request message, so he would send hey. I mean I'm missing the following information. Please send it back to me, so that's how you would get your database synced up.

N

If you will so there's a couple cool optimizations about that, as was once usually LOV P once it's stable, nothing, changes, you're, just kind of refreshing in case up here popped up and he needs to hear about it and you should support shared media. Nothing really changes, it's just sort of going on it, so we don't have to send all the world's data every time. So, with this new proposal, we would just send that first first packet and be very compatible with existing implementations and we could age things and stuff that.

N

Similarly, currently the number of extensions that we can send extension PDUs is limited by how we describe them. We're gonna put a in a TLV, we're gonna describe all the other packets, so I can only describe so many. The current proposals is using like a 16 byte checksum, maybe that's overkill, so that only allows like 31 packets. So it's not quite your 64k that l SVR has I think it's about 45 K, but again that we could change that by shrinking the size of that checksum.

N

Okay. So here's kind of the proposed operation of this proposal, so you imagine a list to get two agents this agent on the left. He has a local database.

N

Let's imagine he updates something in his local database and it's expands multiple packets as soon as he does that he's gonna send out the first TLV, the first packet, which is compatible with an old implementation and then he's going to follow it with these existing packets and so the receivers going to kind of coalesce those get those and when he decided when he's received every it all, looks good he's gonna tell his higher layer protocol just like he does today. Hey something changed in this database. Go go!

N

Do what you need to do so then, let's assume, let's assume that that agent, that this say their agent hasn't been around before he nothing's changed. He's gonna send his first packet back. That just says: here's my here's! Here's a description of my database. If that person has never seen that before or he doesn't have the the accurate view of the database, then he's gonna send what we call this request for extension, so he's going to request the missing packets and then the the the other agent would just reply with those missing packets.

N

Everything gets synced up and again we update the higher the higher layer, so very simple, augmentation of the current philosophical lldp with this just allowing additional packets. So that's kind of the high-level summary of how it works. Again. As we mentioned, we approved a part that the we approved to generate a project that again and start working on this and deciding what the scope and requirements are so great time to have an input from LSB.

N

Are we have a design team of people that continue to look at this offline so to speak and and I in? Like said, Randi and others have in the past, participated to that and anyway, I have more details like you know, PDU formats and things like that that are, in the background of this slide deck, but I, don't think we have time for that. It's probably not not necessary all right, so any questions about that.

F

Just for information I want to come come come back the clarification to an earlier point made in the very beginning at the chair scene. So somebody said the person who wrote the lead is a letter. The way it happens in 802 that one is not a person, writes the letter, but the group. So actually we sit in a room like here it's on the screen and do we do the worst meeting like 60 people hundred people in the room? So that's the group's message, not one person's the other thing.

F

I thought it might work, be coming back. I heard.

A

That it was this point.

F

Has been made before in in this group that actually, it is not likely that it would be good for the industry to have two protocols for the same problem.

F

It's seems better for everyone to have a single standard, a single protocol. That's why we do standardization so for link layer discovery. We already have a standard and if we have two standards and everybody has to implement two to protocol. So it's not that good for the industry, I.

E

Killed Patil arcus: let's get the requirements sorted out. First I think we can follow up with the solution later on I as long as the requirements match. What we're after I think the protocols can be worked out, but I can clearly see some of the requirements missing. So we should chat. Okay,.

N

Yeah I'm happy to chat with the offline and happy to also coordinate with the TSN working group, a phone conference where we can share that.

E

N

All right thanks.

E

Morning, folks, my name is ko. Patel I'm gonna give an update on PGP SPF draft, so the draft itself was updated in December. We've got lots of comments from Eric Rosen, particularly focusing on the convergence aspect of the draft itself. The draft they've incorporated lot of those comments as well that we receive it's in a fairly stable state. We've also received lots and lots of reviews from folks that has been incorporated.

E

Implementations are way under way to get it going. I know at least one implementation that got the Safi up and running an SPF being calculated. We gonna start publishing some simulation results pretty quickly.

E

The change with version 4 that came mainly was an edition of link NR a-- NLR. I attribute bgp SPF status, TL v that was added. This is to signal when the link goes down without immediately withdrawing the link and lraa itself, and this is to aid faster convergence. When you have link outages, the similar kind of status TLV was added for prefix NLRA. That would be applicable to the prefixes for that link that had gone down, and this is again to aid fast convergence. Aside from that, there is no more update.

E

Questions comments.

C

So a lot of thought: the.

A

Only comment I have is.

C

That I would like to encourage the working group again to please discussions on the list. Maybe we can get some more reviews, volunteer, reviewers, etc so that we have just four more going on and.

E

To that point, specifically, if you are implementing- and you have an implementation on the way, let us know would be happy to do some interrupt testing it as well. A.

G

Conf I wouldn't expect you to open-source it, but one thing that I think I think they've done for rift is they have have a binary that people can test against at least I I didn't it was I. Didn't talk too much them this time, because it was against the FDA and I need to be at the BFD working groups. I didn't hear, but I think I think that would be an alternative with your implementation. If you could somehow subset the product one into a binary that a person could start up yeah, not.

E

A bad idea, I'm, assuming you all, entered for that.

K

So here's a question of the group: this we seem to have a drafter, that's trying to get mature, or at least so. We think how many folks in the room, have had an opportunity to read the latest versions draft or potentially, maybe the penultimate version. The previous version, just as a show of hands, so have a few.

K

So what we probably want to do as a lara mentioned, is we'll go to the list and we would like probably some additional review so as a will sort out how we can coax a few folks into doing kind of a detailed review is at this point. We want to make sure we gotta kind of vet out any additional challenge or, if there's anything else, that we have to resolve or deal with in the draft.

K

We want to make sure we get that done well, so I'll make that we'll make that ask on the actual list itself as well as to also have that, like I've ever mentioned the comments, if there's questions, concerns or things we need to address, we would really like to see that on the actual list itself, and even if folks had any sidebar conversations, please relay those onto the onto the list, so we can see what that is, and so we can, you know, effectively mature this out.

K

So yeah is that this is the last. The other thing about just I'm gonna try to encapsulate the conversation we had. There was a lot of discussion around liaison and working with people working back and forth.

K

So we'll try to catch that just so, we understand whom will be actually contributing with the folks over like Paul and whatnot, on the I Triple E side and I'm gonna try to sort we're gonna, try to sort out the I heard a lot of session on the requirements I want to just want to understand with country how we can make sure we get that pulled out, and we really understand what it is. I heard it a few times. I didn't really hear resolution on that.

K

Just yet so we'll come up with some ideas as to how to kind of get that resolved and then play that back. So there's clarity as to how we want to get that done. So we don't. We don't assume positions that does that feel worthy. No.

C

Come do Mike, I wrote it that I share that works back for me as.

A

C

Before I think, one of the best things that we can do here is to have that people cross working in both organizations not just depend on on Paul to you know, bring the message back and forth or from aliens, but to have that inter working it yes would be great if we can have a list, a document that email. You know something at least that we can point to and say these are the requirements specifically, so we can share with everyone else. At the same time, yeah.

K

You're released.

F

K

F

Maybe just I just thought to mention one of the recent examples: a with about the good collaboration between the two organizations ITF and 802. There was a project in 802 to specify extensions for VDP for embryo tree, so the annuity working group, a NATO 2.1, has been working together to extend a basically a 2.1 protocol for Andreo tree. So that is one of the recent examples of collaboration.

F

Thank you noted.

N

Yeah I'm, looking forward to working with on this problem. I guess I just want to emphasize that in the it's hard to keep your our eyes, always on the customer and the end game here, but I mean I think we want to do what's best for the industry, regardless of how things kind of come out- and you know just from a taxonomy found a point of view. There could be obviously several several things that could happen. You know we we can.

N

We can look at a suite of protocols that eight or two got one already has that meet the requirements. You know we could, you know, do a new project in 802, the one that that tries to meet your requirements. We could do nothing and just let LSE goats, goats on way and and do all these.

N

These are all options that are on the table, but I think it's really important that we keep an eye on well, what's the most important thing for really the industry here and and in you know, we want to create a bunch of fragmentation and extra work on operators and and everything too so I think it's it's strongly important that as organizations we come together on this particular problem, so again, I'm willing and looking forward to that collaboration.

J

Boston arcus, just um an architectural level for whatever it's worth. The ITF has been down this road before in other protocol Suites, for example, we have x.509 versus DNS, SEC right and really part of the issue in those cases. This is there enough. That's different about the requirements for this protocol. That really needs to be a separate protocol, and that's why I think it's actually really important. We do the requirements analysis, because DNS SEC really did have special requirements, packet, size and just too much baggage for other things.

J

Next 509 is a big, but it's a big network, so, okay whatever, and we just need to figure out whether or not this is special enough. That actually needs to be a different thing. Yeah.

K

I think that's precisely why getting the acquirements teased out well is gonna, be really important for us to isolate, so we can make that determination correctly and having creamin as to what that is. Thank you thing else. Okay with that, unless there's any last comments, we would be adjourned with today's agenda.

K

Okay. Well, oh thank you very much.