Minutes interim-2018-lsvr-03: Mon 10:00
minutes-interim-2018-lsvr-03-201810011000-00

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 ?