Minutes IETF103: lsvr
minutes-103-lsvr-00

LSVR agenda:
    Time: 1:50-3:50 Bangkok time (Thursday 11/8/2018)

Welcome (10min)
  (Chairs)

Call to action (5min)
  YANG work MIA from current deliverables
  (Chairs)
[see slides]
Chair: Agenda is not too full.
Adam and Sue Hares will help with Etherpad
Acee will assist with Jabber.

* 2 meetings + 2 interim, good progress in document.
* in future: 1 meeting + 1 interim
* Any Comments?
[none]
* Keyur Patel: LSVR YANG model (July milestone) would have dependency on BGP
YANG model. Has been discussed at IDR.

Exec highlights of the LSVR Interim (15min)
(Jacob)
* 10 attendees + 2 chairs
* Randy reviewed requirements for link discovery, LSoE -02 draft
* Keyur reviewed BGP-SPF draft
* Security was highlighted as open point; security blob was proposed to provide
identity, authentication, etc. * Randy: There has been further progress on
security

Update of draft-ymbk-lsvr-lsoe-02 (15min)
  (Randy)
* New data framing: PDU is application layer message, can be fragmented into
datagrams, each which is one Ethernet frame * Open of session is now ACKed. If
ACK is not received, the PDU is retransmitted * Link hello is now multicast *
Open has authentication blob, could contain public key signed with private key
* L2 keepalive could be in addition to L3 BFD * Encapsulation PDU provides the
addresses eassociated with each encapsulation. Flags to indicate addresses as
primary, loopback, etc. * Acee + Randy: encapsution encoding is borrowed from
BGP-SPF * Paul + Randy + Rob: 1 TLV per PDU, should version allow forward
compatibility? * On security: don't want key exchanges, no need for
confidentiality, all PDUs signed with 512 bit suffix, keepalive sequence number
to deal with replay vulnerability. Randy wants feedback. * Alvaro: security
should be part of base LSoE draft * RAndy: States that this mechanism should be
used outside of a secure.  Please provide input to Randy on the threat model. o
Should the security + LSOE - be a separate protocol or should it be one
protocol? * Rob A: The advice is use TLS or or you will be creating TLS. 
Design decision to keep this as simple. * Acee: Is the security in your draft
now? * Randy: Only in the presentation.  Paul what do you think about this
signing it? * Paul: I'd be concerned about authentication for life of the
product. * Randy: Current specification says if you get another open, you have
reset.
     The proposal says "do not destroy state."  It could be finessed to change
     keys.
* Acee:  Why not use public/private key pairs?  You can change.
* Randy: It only has to be specified that you should not drop state.  I have
v4/v6 state and then I receive v4 information.  How long do I keep state? *
Gunter: How much more effort to finalize the draft? Randy states they are
working on an implementation. Aside from security open points, it should be
stable.

LSoE Next Steps (15min)
  (Chairs)
* IDR and LSVR chairs have discussed. Want one approach for auto-discovery.
* Slide shows John Scudder's summary from interim. 5-6 different proposals.
Only common requirement is to bring up single-hop EBGP sessions. * LSVR may not
want to wait for IDR interim/design team proposal. * Acee: There is an
interaction where it uses the same BGP-LS address space. * Randy: My read
BGP-LS covers to RTP to jabber.  My reading is the IDR is coming and needs to
stop.  IDR is big and slow - and carries a large burden on the back. If they
have input, we should take the input seriously. * Gunter: We agreed with the
chairs with IDR that it should not exclude the future requirements.  It will
also look into what LSOE is doing and see if matches the IDR requirements.  I
would like to propose going forward that to adopt this work in this WG.  I
would like to propose that we have a WG adoption call. * Ketant: We have seen
addition of fragment, session acks, encapsulation, hooks for BGP API, and
security. I suggest that the WG wait until we see this information. * Keyur: I
disagree that we cannot use LLDP due to the limit on packet size. * Jacob: I
brought the discovery of the whole network. I was told there is no
auto-discovery required since everything is planned. Is there any need for
auto-discovery? * Igor: There is need for verification that something is wired
correctly.  We do not want protocols to start automatically.  Unless the
protocol is correct. We do not want the protocol to start-up. * Randy: We are
not suggesting that LSOE should be used to provide protocols. Wide variance (no
discovery, some discovery, all-discovery). * Ketant: This protocol could use IP
or ARP.   LLDP was only at L2 level. I do not see a strong at level 2. * Keyur:
Randy has a good set of requirements document.  Let's have a conversation based
on this document. * Wim: We need something to list of all open bootstrapping
requirements and verify we have the correct on e. * Acee: I agree with Keyur
and Wim.  I think that LLDP and Cisco DP is justification for this protocol.
This is still useful in the bigger data-centers. * Igor: We do need
auto-discovery from the verification.  If we have a problem with Ethernet 1500,
then LLDP will not be enough. * Alvaro: Are you going to ask a question about
adoption?  I would still prefer 1 protocol. The recommendation from the chairs
is that we do not delay the work. o IDR may say LSOE or something else. o It
would be nice that BGP would receive information from any types. It is
important that we know what information we need to start the BGP session. 
Otherwise, we had discuss that the interest was in this WG - we should start
the protocol here. Then IDR could add it now. o The protocol needs to have to
satisfy LSVR and other protocols. * Igor: Has anyone looked at the difference
between LLDP and other protocols?  Can we do a LLDPv4? * Randy: It hits an IPR
barrier rather than a technology barrier. * Igor: Why not replace it? * Randy:
LLDP is a rich protocol. * Igor: My concern that LLDP or LSOE will be
deployed.  What happens if they disagree? * Keyur: When we started off in this
work, this deeper replacement * Igor: What happens when LLDP and LSOE disagree.
* Randy: Replacing LLDP is not something in the short-term, perhaps for the
mid-term. * Alvaro: You know that this work is not charter for the WG. It is a
layer-2 protocol so we need to discuss with the IEEE.  There is a coordination
meeting on Friday AM.  Gunter is going to the meeting to tell them what we are
doing. If we want to replace LLDP with LLDPv2, then we should tell IEEE.  We
should take this information list. * Randy: If IEEE wants to take up this
standardization, I am happy. * Gunter: The Adoption will call will be for the
LSVR WG.  More eye-balls would help the working group.

Update of draft-ietf-lsvr-applicability-01 (30min)
  (Keyur/Acee)
* In -01 (updated just before meeting), added sparse peering section to
Applicability draft * No comments

Update of draft-ietf-lsvr-bgp-spf-03 (30min)
  (Keyur/Acee)
* One outstanding point is need for explicit withdrawals. Should BGP-SPF have
it, similar to max-age in IGP protocols? * Randy: We do have a distributed
database problem, but we are not going to solve it quickly. * Acee: We do not
want to change too much of the BGP machinery, outside of SPF. * * Victor: BGP
was chosen for wide-deployment and operational simply (there, common, and
simplified performance) * Randy: Not a lot of noise. * Gunter: What worries me
is the silence on the WG list.  The RTG-DIR and OPS-DIR went well. * Randy: I'm
writing a draft to support it. * Gunter: Shall we launch a WG LC?  We need to
look into whether we need implementation for standardization. o IDR has 2
implementations due to many types of deployment. o LSVR will have mostly 1 or 2
vendors. o I will be launching a WG LC. * Randy: I would like 2 have 2
interoperability implementations. * Gunter: This is a gating requirement - if
you require 2 interoperability implementations. * Igor: We want at least 2
interoperabiliy implementation.  If there is 1 implementation, then the bugs
become the standards. * Gunter - any other comments?