Minutes IETF104: lsvr
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