Minutes IETF102: lsvr
minutes-102-lsvr-00

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