LSVR Interim Meeting
Oct 1, 2018, 701 E Middleton
Nokia Facility

In Room: EriK Kline, Jacob Uecker, Victor Kuarsingh, Randy Bush, Gunter Van De Velde, Tony P

Remote: Keyur Patel, Susan Hares, Acee Lindem, Eric Rosen, Paul Congdon, Alvaro Retana

Agenda

* AdministriviaÊand agenda bashing (5 min) - Chairs
- Deep Dive into Link Discovery (60 minutes) - Randy
- Review / confirm requirements in - draft-ymbk-lsvr-discovery-req-01
- Discussion LSOE Draft - draft-ymbk-lsvr-lsoe-02 (10 Minutes)
* Next steps
- Update on Draft BGP-SPF (40 Minutes) Ð Acee/Keyur
- Summary of OPS and RTG Directorate review 
- What changed with draft-ietf-lsvr-bgp-spf-03
* BGP-SPF Security Requirement (30 Minutes) Ð Jacob? Randy? Chairs?
- Re-cap current discussion, close on areas that need to be address
- (discussion and plan for closure / if needed)T
* Test code for protocol validation (10 Minutes) Ð Chairs
* Closing and next steps (Chairs) (5 min)


10:04 PDT / 13:04 EDT (Intro remarks by Chairs)
* Introductory remarks with Gunter 
* Note Well discussed
* Making good progress, need progression between main meetings
* We have a ~1 year timeframe
* Agenda Bashing
* Discuss LSOE, requirements, and changes in -02 document
* BGP-SPF review and feedback will be discussed 
* Then discuss security requirements in DCs and how that intersects the working group and needed inclusion of work
* Brainstorming on how to get test code, hackathons or other options
* Closing statements 
* Victor is notetaker
* Reviewed milestones Ð no comments


10:10 PDT / 13:10 EDT (Randy Bush)
Requirements Draft

* Now doing requirements, as a post event to LSOE
* Quick review of the history of LSOE and basic requirements 
* Discussion of slides of neighbor discovery, what data is needed.
* Need Layer 2 liveness.
* Security was added, since operators said they cared about it.  But no current feedback provided
* Need routing data, to be done by BGP-SPF
* Just need discovery and liveness for BGP-SPF (10K or more nodes)
o Keyur: requirements should cover more then just ToRs
* Needs to be simple, no IPR, understandable
* Discussed the candidates. (IPR barrier for >1500 bytes for LLDP)
o Sue Hares to send references and spec.
* IS-IS discussion.  Have control in IETF, not common on SDC
* ECP Ð itÕs a transport, controlled by IEEE
* BGP Neighbor Autdodiscovery Ð needs peering address, still in progress (AS-based)
o More about configuration Ð extra comment
o Contrast of Jupiter rising (and how it differs).  Collection and distribution 
* LSOE, custom made for BGP-SPF use case (originally)
o No current measuring and monitoring tools
* Showed a table with all options and top level
* Q: what do to with this document
o Chairs: we need something like this for BGP-SPF
o Acee: we need something like this, but out of scope of main documents
o Keyur: from a requirements standpoint, this is a good start.  ItsÕ tailored crafted, but generic enough to cover BGP later.
* Needs immediate application to serve BGP-SPF
* Would like to see it in LSVR
o Randy: LSOE vs. Requirements.  Where should each document live?  We are in a delicate balance (between where IDR is vs. LSVR needs)
o Sue: comment on how to get something out the door as first order of business.  Lets talk about whatÕs happened.  
* Randy: donÕt get too much feedback, but positive feedback on LSOE
* Randy: got best paper at RIPE
* Keyur: we can get operators on record 
* Sue: to look at IDR/Sue feedback É (audio was cut off), may be skipping some information needed to address
* Sue: proposal to adopt it in both WGs, and progress it as best. (both document) 
* Victor: how to manage mechanics Ð Sue: can adopt in both data tracker lists
* Gunter: have chairs meet before 103 to clear up logistics Ð Victor: confirms what Gunter noted and in-line with Sue
* Keyur: will work with Randy on ES-IS and have a slide on this
* Paul: Q on LLDP, frame side, due to security?  What data causes that to increase.
* Randy: with Jumboframes, in place of multiple PDUs, you can increase a single set / and room
* Jacob: LLDP, may or or may pass through switch?  Do we want this to go through a swtich? Or not? Ð Randy: responded.  Undefined? Keyur: matter of policy
* Paul: LLDP has addressing options, to allow for different types of propagation (if you needed different destinations)
* Erik: comment on PaulÕs
* Tony:  Any 802.1 inclusion.  Randy: none at this time
* Alvaro: Agree with SueÕs proposal.  Fast track this.  Use what we have if we can, but, also make sure we tackle problem.  Concerned a risk to define for everything. Ð First set solves LSVR, and accessible protocol (e.g. extensions)
* Process to be worked out before IETF103
o 

Randy: LSOE -02 Draft.

* Review motivation 
* Topology, ether-layer discovery
* Allow forward progression, upgrades/updates.  Seq numbers etc
* Checksum slide.  -  discussion of 32bit vs. 64-bit (old procs on some hardware)
* Inter-link Ether protocol ,  nodes can appear, so repeat the hello
* Hello.  Multicast, MAC address
* ID unique in global routing domain (Erik: confirmed 80-bits)
* Discuss Attributes slide
* Authentication Data.  Desire to understand how this ties into operators CA structure 
o Erik: could this map to next x509?  Randy, confirms yes could work (hash of cert)
o EK: may need part of auth chain
* Victor: get key input from a couple of players, to get threat model is Ð Randy: Key redistributing, etc.  Ð Tony: re- revocation. (Randy Ð things revocation is a big deal).  Acee, canÕt negate whatÕs needed for auto-discovery
* Chairs: need to sort out how to get operator input on threat models
* After Macs are known, L2 keep alives
o Hellos are MC, keepalives need only be UC
o Sue: ratio / loss on network may require we have both of these.  Randy: had input for keep alives in different timescale vs. hello
* Encapsulation PDUs discussed
* IPv4 Encap slide: Sue wants to know why we changed it.  Randy: Feedback from John S.
* PrimLoop flags.  Sue: should have one address one address per slot.
* IPv6 looks like IPv4 encap
* MPLS IPv4, similar to IPv4 with label list.
* MPLs IPv6, similar to IPv6, 96-bits longer, no magic
* North/South using RFC7752.
* Node descriptions, from 7752, as with MPLS links.


11:35 Keyur on BGP-SPF

o Status update on BGP-SPF
o Updates made from comments, in stable state, with a lot of feedback (online and offline)
o Ready to beginning to work on implementations 
o Fred Baker thought it was ready Ð small nit on section 5.4
o Dan Frost also had some minor input.  Concerned BGP is not designed as a DB disruption (BGP is currently fairly stable) 
o Randy: comment on data distribution problem. Ð this should be moved to IAB
o Version 2 changes
o Version 3 changes
o Explicit withdrawal? 

Key take-a-ways

- DB distribution
- Explicit withdrawals 

Victor: do we bake in DB distribution (abstraction) in BGP-SPF. 
Keyur: suggests that implementation specific 
Gunter: there were three components. Make it more expressive in document
	Keyur: just getting feedback from Frost, that BGP is stressed
Keyur: intended -03 to be last call version (and version for implementers to use) 
Chair: Did authors have any comments on implementers.
AD: agrees, we would like to see more traffic on channel, and interest 



12:10 Section/ Topic Ð Security of debate

* July 30th, debate/ discussion started.  Threat model 
* Not a lot of feedback after that initial common (from Randy)
* Gunter has list on the ÒSecurity DebateÓ
* Shared the comment to other groups (IDR, OpsSec), as a result of that, feedback was received 
o Randy / Erik, comments and inclusion for 802.1x (need L3..)
* What type of Dc operators are of interest ?  
* Randy:  allow for the right hooks to map into the operatorÕs security model 
o If enough of the open allows for the hook, would that be enough?
* Acee: work in anima ?  (Randy was not impressed)
* Victor: have enough to be implemented simply, or in a more advanced way  - Keyur: agrees
* Randy: Q to operator in room (Jacob), position on what we have, and would it bind operators too restrictive 
*  Erik:  the bolb, can be used for identity. Can also be use for privacy (and authentication Ð e.g. signed with something) 
o Different layers, full trust, somewhat trust, and non-trust.
o What do you need for this?  Have a TLV to put information (e.g. signature / auth) 
* VK: would this be configurable ?