LSVR Minutes - IETF 102
Gunter and Victor chairing

First thing in the morning proving challenging finding scribes

Agenda:
    Interim meeting comments.  Some actions from it.
    Interim meetings will happen throughout the year to help maintain forward motion.
    BGP SPF draft will be discussed.
    Have adopted an applicability document.  New document will be shipped now that docs can be posted again.
    Discussion of neighbor discovery and ... LSOE -
    Closing with next steps and inputs to next interim.

Alvaro Retana (RT): Agenda on tracker doesn't match displayed one.
Victor: One on data tracker is correct.

Jakob Uecker - LSVR interim 1 update:
    *slides*
(remote presentation via meetecho - tech issues...)

Victor: 3 key action items: adoption of applicability ; discussion of requirements for liveness and ND; 3 (?) was deferred.

LSVR BGP SPF applicability (Keyur for Acee):
    *slides*
Jeff Tantsura (JT): yang policy - see how it may apply?
KeyurPatel (KP): Should be in here as well.

Sue Hares (SH): re - routing policy. Is Randy sending third option?
Keyur (KP): Depends on whether he's covering it. He doesn't want to be part of this discussion.
SH: Stuff coming into IDR re: policy- [...] Segment routing people have had peculiar ideas about policy. want to know how it might apply for lsvr possibly?
KP: Trying to keep working group sane.  Stuff for normal bgp/policies would probably apply here too.
SH: That's one way to do it; requirements driven good.  [...]
KP: From draft point of view, if there's specific text desired let us know.
JT: SR-TE policy has nothing to do with routing policies.  Please don't mix them, Sue.

BGP-Based SPF - Acee Lindem presenting
*slides*

Alvaro: MUST put this (how to run the spf) in the doc
Acee: To people that thought about it, it was intuitive, but some didn't find it so.
AR: Don't let people make assumptions.  We need things to be clear for interop.
AL: This has a third grandularity of how link state is processed.
Jeff Tantsura: Optimization/caching of policies for SPF?
AL: Take this off line.

Jeff Haas: re: multiple domains, presume it up front.
Gunter: The charter is explicit about the applicability in a single domain, hence multiple domains is currently taken out of charter
AR: charter says "single distribution domain".  More in the concept of a flooding domain. If there's consensus to do this, we can massage the charter.  I really want the WG to focus - not accrete work.
AL: let's write something about it and see how it falls out.

Jeff Haas: Optimisation on aspects where the node falls away and the NLRI is dormant/stale on the BGP-LS table. Maybe something would be done to add communities or something else that would break that property
Keyur Patel: This will be hard for a node to figure out if a node is failed or something else is failed. Keyur would prefer to keep it out of the routing property.

LSVR Charter review:

Link Discovery and Liveness (Randy Bush):
    *slides*
Jeff Tantsura: Don't we need a more generic solution? Why just bgp space?
Randy Bush (RB): This is auto-discovery for lsvr only.  Centered on spf. [switching hats] another presentation later for some suggestions for _this_, that might have wider applicability.  Question here is narrowed - what is minimally requirements.
JT: Requirements really for data center.
Gunter: Requirements are for lsvr perspective.
Keyur Patel: Requirements here for lsvr, but more specifically that are generic that can be extended for future.  E.g. bfd can be used for more as a single technology.
Sue Hares: Liveliness - can you define that more precisely?
RB: I think you can do better job of that than I can. Link up? For what encapsulation? How often?
SH: Is this link up? Are you requiring _transport_ across it?  You're doing this via bgp.
Jeff Haas: Sue, this may be a separate protocol.
SH: This is _for_ bgp-lsvr.
RB: ... run BFD _after_ we run this, e.g.?  We're just trying to do the encapsulation liveness.  BFD on top?
SH: How does this make sense? Two liveness protocols, going for fast convergence, two protocols likely to be less fast than a single one.
KP: Simply requirements, not a solution.  Liveness is in the context of protocols - bfd.  Don't see the need to do another protocol extension.  What's needed is discovery.  Should the protocol be defined over udp or tcp?
Bruno Rijsman: Support multipoint LANs or only p2p?  We can do only p2p in a DC context.  Must have of discovering addresses, for v4/v6 - but not downstream labels.
Acee: Maintain liveness - people see this different ways.  Shouldn't try to maintain session using mechanism - just use BFD.
RB: Responsibility at this level is to tell SPF, your topology has changed.  Encapsulation gone/come up.  Other topology
[...] disconnected from etherpad
SH: Two stack protocols, determine encapsulation, or are you trying to bring up liveness quickest way possible.  Why two protocols faster than one.
John Scudder: Since this is a slide of requirements. Is there a missing bullet point for timeliness?

*slides*
non features:
Acee Lindem: LLDP draft had but took out (robert invented fourth option over weekend) - you can learn a loopback and have it install routes for that. would allow you to have completely unnumbered interfaces.
RB: Not a fan of unnumbered, but like loopbacks.  Don't need routing for that? Just have that address available, with that attribute.
AL: It's a connected route in people's implementations.  This protocol could do that.
RB: I'm inclined that way.
KP: Implementation specific detail. BGP peering address might be different from interface address; could be text that says you can peer over it even if it's not on that subnet.  In scope with discovery protocol.  Implementation could do this via injecting route.
John Scudder: Good to have a way to bootstrap loopbacks.

*slides*

Paul Konga author of LLDP: propagation through switches depends on what you put on the address

LSOE comments - Sue Hares: [...]?

Gunter: No violent disagreement with Randy's slides. Timeliness requires further discussion.
John Scudder: Randy had big question mark around security.
Jeff Haas: BFD single hop rfc 5880 may have issues as both protocol liveliness and link liveliness together.  You get fastest timer. BFD fails, you take down both together.  This may be good or bad.  There may need to be BFD work.
Rob Austein: one protocol vs. two. hello phase in ospf is basically a separate protocol, just happens to be tightly coupled. Whether you consider it a separate protocol or not
Sue Hares: I disagree with your analysis, Rob.  Consider timeliness.  It's important to come to a decision what we should have on the list.
Alvaro Retana: Manet has DLEP, e.g.  for security, got away with explaining normal use case; security could come later.  Personally, okay with not needing additional overhead, once the operational cases are clearer.
RB: Are there actual data center ops in this room? Those people who raised their hands? Do you have security issues?
Bruno Rijsman: Seriously.
Dan V (bell canada): prior speaker had question about operator interest.  poll operators.  security is a MUST.  Presentation are we trying to reimplement another link state protocol?
Jeff T: 70% of presentations in lsr were on optimizing data center.
Alvaro: Odd that you're asking me the question (what was it?) we had a bof about whether we need more things, and were willing to work on them? [very little traffic on list] Told chairs: we'll charter the work here and see what happened. If community doesn't want to do this, we'll lose interest.
Victor as individual contrib: operators vary in how they deal with security. this should be extensible so we could use it. polling ops is a good idea to gauge response. operators make independent decisions. lots of things drive to simplicity (telemetry, complexity, number of people to hire, etc.)


draft-xu-idr-neighbour-autodiscovery (Ketan presenting)
*slides*
Sue Hares: (adjacency state machine) doesn't interact with bgp fsm as you might expect. Let's talk about this offline.
*slides*
Keyur Patel: Ask for implementor feedback other than just operational feedback.  There are scaling considerations.  Keepalive machinery has its own issues/scaling.  If scaling concerns are there and are taken out of BGP, then you have to specify how the FSM interacts. Why not go generic? The mandatory to implement changes to keepalive stuff needs to be resolved.
Ketan: Why not generic? Intended to be for bgp - no desire to deal with other protocols.
Kevin Wang: Idea very similar to LDP neighbor discovery. LDP has nothing specific for the session.  BGP can have a lot of things that vary per session.
Ketan: no such assumption (of homogeneity) - still requires templates.
KW: But if you have to configure the templates, how does it vary from bgp session config?
Ketan: [in clos] position in the network, things are [largely uniform]. not much policy in a data center context.
Sue Hares: BGP state machine in 4271 is so interesting to read is to try to make it more bullet proof.

draft LSoE:
    Ciena: is this proposal expose the scaling aspect as discussed in previous meeting?
    Randy: no, IGP neighbor discoveries are very noisy, even disproportional to the number of links. Here the solution is only associate dto the link itself, and not to number of notes