Minutes IETF104: lsvr
minutes-104-lsvr-00
Meeting Minutes | Link State Vector Routing (lsvr) WG | |
---|---|---|
Date and time | 2019-03-28 08:00 | |
Title | Minutes IETF104: lsvr | |
State | Active | |
Other versions | plain text | |
Last updated | 2019-05-09 |
minutes-104-lsvr-00
LSVR WG Meeting - IETF 104 --------------------------- Admin update: - new jabber scribe Note well: Everything discussed and said is contribution to ietf Agenda: As listed Comments / updates: - Gunter: Applicability document adopted - Gunter: WGLC opened 3-17 Dec and there was good discussion on the mailing list - Gunter LSVR does work on Layer 2 tech and prompted the Liason with IEEE. Response is on the IETF WG - Alvaro: Formal IEEE response came in 3/28/2019 - Keyur: yang model work is also underway. Asking for collaboration if anyone else is working on it. - WG LC for bgp spf draft done, new document based on all feedback received. - IEEE Liaison: o IEEE liaison because of overlap with l2 technologies o LLDP enhancements underway as a result, updated on the IEEE page o Acee: incase of an impasse, should we add a 20 byte header to LLDP and multicast addr o John Scudder:l had more negative reading of the response, does not seem like a simple technical problem to solve o Randy: lets not create unnecessary conflict and work together. LSOE update (Randy Bush): Recap: - main goal: LL topology discovery for LSVR - pushed to upper layer protocols Additions: - extensions underway with respect to evpn-lsoe draft - large PDUs: 64K octet delimiter - duplicate frame - vendor extension - explicit ack/error - HELLO (multicast) and keep alive (unicast) are still separate with separate timers - open; should each PDU have a signature / authenticity check? - seeking feedback for providers - MACs are not unique globally, need to be qualified by vlan-id or the interface - state machine is still pending, rob�s implementation about to be open sourced. - code written in Python3 - Keyur: code will be open sourced shortly - asking for reviewers - John Scudder: Question on security - about users have to ask for it. General guideline in ietf is to have security unless user says to not have it - Randy: need to understand the threat model to design security - Randy: would gladly get it in, just need to figure out the right - Rob: cannot design with just knowing to add security without knowing what that means - Alvaro: add to the document, assumptions about security - victor: assume that no devices are trusted, and there has to be a way to validate each device. Will supply more text around that. - Randy: are you willing to do a CA for every device in your system - Victor: Yes LSoE Based PE-CE Control Plane for EVPN By Neeraj Malhotra - Acee: very good simplification and makes things more active. The only problem it brings the CE devices in to EVPN and getting them updated will be administratively impossible - Neeraj: this is optional and co-exists with the legacy methods in place - Robbert Raszuk: can you use the CE as a GW for prefix learning - Neeraj: Yes, it can be used that way - Robert: any kubernetes - Neeraj: not yet - Paul Congdon: Can you analyze what the actual requirements are? - Neeraj: Yes, we need to do that especually for timing etc - Janos Farkas: Have you studied LLDP - Neeraj: we used LSoE becausee it is session - Keyur: The fact is that neither arp nor lldp comes into effect when EVPNs is in use. A connection oriented protocol alleviates the issues of data path learning Paul / IEEE LLDPv2 liaison response: - LSoE is not a link state protocol - misnomer - llldp - enhancing to meeting the needs of lsvr - liveliness does not fit into lldp, but can be supported via other protocols like CFM - Keyur: happy relay more requirements and collaborate with lldp - Alvaro: what happens next from IEEE perspective - Paul: needs to be an IEEE project authorization - has not happened yet - IEEE is also contribution driven, anyone can contribute - Janos Farkas: 1 - 2 year horizon, project launch officially in spetember, technical contribution - Keyur: need a process for the community to be able to contribute back to IEEE to make sure that all requirements are covered Paul (continuing with the presentation): - looked at list of information being exchanged and be put into LLDP TLV - TLV size limit could be extended as part of this extension - link liveliness would not work nicely with LLDP because protocol requires everything to be sent everytime, recommend - ack: implicit part of LLDPv2 proposal. - Acee / Keyur: need beyond the existing use case beyond what is the LSOE draft, beyond larger TLV payloads - need to be able to exchange more than one TLV, jumbo frame not a good solution. - needs to be backwards compatible - allowing a larger TLV - summary of how LLDP works - approved to generate the project, design team continue to look at it to meet lsvr requirements. - Keyur: need to have requirements solidified before the protocol LSVR BGP SPF (Keyur): - draft updated 12/20 - lot of comments from Eric Rosen incorporated and lots of reviews - main change is addition of the Link NLRI attribute BGP SPF - implementations are underway, one implementation is up - signal link down without having to withdraw BGP NLRI for fast convergence - Alvaro: asking for more discussion / comments - Keyur: asking for other folks starting implementation to seek help on the list - Acee: don�t expect to open source but could we look at to have a binary for person to start testing interworking - Rob: need to figure out if the requirements are special enough for it to require a new protocol