Minutes interim-2018-lsvr-01: Fri 16:30

Meeting Minutes Link State Vector Routing (lsvr) WG Snapshot
Title Minutes interim-2018-lsvr-01: Fri 16:30
State Active
Other versions plain text
Last updated 2018-07-07

Meeting Minutes

Chairs : Gunter, Victor

Attendees: Acee Lindem, Jacob Uecker, Longfei Dai, Randy Bush, Shunwan Zhunag,
Alvaro Retana, Jorge Rabadan , Donald Sharp , Tony Przygienda

Call-in: Keyur Patel


Introduction :
- Victor started recording at 10:35AM EST
- Gunter sharing agenda slides
- Gunter supplying introduction and detailed agenda review (page 4 of chair
slides) - Key points
        - State of LSVR
        - Discuss SPF Extensions Draft (adopted)
        - Usage Applicability of LSVR document
        - Discuss need for neighbor and liveliness detection (discussion only)
        - Closing and next steps

- Slide 5 - view of “where we are at”.  Interim Meeting 1 post IETF101 and
pre-IETF102 - Slide 6 - Discussion of missing work on YANG spec document -
Slide 7 - LSVR Charter Status
        - New applicability draft version is one for review / based on
        potential adoption
- Slide 8 - Agenda review / bashing?
- Comment Keyur on agenda - as we looking into this work, neighbor discovery is
a key component.  preference that work comes into this WG.

<< BGP-Based SPF IETF Interim 1 Slides >>
- Keyur Patel
- Slide 1: status update
        - 01 submitted end of may
        - incorporate most of the comments
- Slide 2: Changes to to Draft version 1 slide
        - added peer models section
        - BGP SPF SAFI section update.  Removed VPN SAFI as it’s not used in
        RFC7752 - Node NLRI section updated for SPF algorithm types - want to
        removed MRAI timer

- Slide 4: Changes to Draft 1 continue
        - BGP decision process for better readability
        - changes to next-hop manipulation / MP_REACH_ATTRIBUTE next hop
        - IANA section simplified

Slide 5: Things to discuss
        - discovery for neighbor
        - deployment use cases
        - should we adopt AS hop count?

Slide 6: Things to discuss (cont’d)
        - Multipel SFP Domain

Q: Alvaro: questions on deployments.  Where are we on implementations ?
A: Keyur: we are not there yet, from after WG document status (looking to get
implementations going)

Q: Victor/hat-off: what other topologies vs. CLOS? support non-uniform
topologies A: Keyur: other clos topologies. we got feedback that this can go
beyond clos. - yes consider non-uniform topologies

C: Gunter/Chair: discussion of what we need to have in document.  would like to
see WG that includes both sPF and vector routing as well. A: Keyur: it’s quite
possible.  solution as it stands, does not constrain to any given topology A:
Randy: this is the BGP/SPF.  Are we wanting to go up-level on LsVR routing
overall ?  Gunter: yes, that’s what I am thinking A: Alvaro: looking at the
charter.  Randy is right, we charted this to be BGP/SFP.  Agree with Gunter,
there can be other transports later, partition domains (understand).  I wanted
to show we can do this fast, and ship within a year.  Also want us to be ready
for the future.  Preferred solution (D hat), include what Gunter said, in the
draft. A: Victor: do we include reference architecture in the spec to start A:
Alvaro: use that text / reference for future work. C: Acee: one of the main
motivations for BGP/SPF, is that all the underlying machinery exits.  We need
more requirements to generalize it. C: Randy: comment on word controller, what
did we mean? Acee: response

Q: Gunter: would we have different link state database? Randy: why is BGP make
this case more likely? (e.g. flooding deltas?) C: Keyur: how to manage ways of
announcements. If policy drops traffic, link state can drop it.  In CLOS, you
don’t just have one path, you have N-multi-paths. NO flooding? Randy: no
flooding is big trade-off. and we have update only propagation. Errors or
policy can cause discrepancies.   Good trade-off of update only, vs. flooding
which does not scale. C: detailed multi-party discussion on risks of BGP ,
errors, and risks.

<< LSVR BGP SPF Applicability Interim1 >>
- Acee Lindem
- Slide 2 Agenda,
- Slide 3 version 1 slides.
        - discussion what to put int applicability vs. base spec
        - security items not in draft yet
- Slide 4 Interaction with Other BGP AFI/SAFs (1/2)
        - intended for underlay where other AFI/SAFIs resolve next-hops using
        BGP-LS sPF routers - intended for flat data center network -
        interaction with IPv4/IPv6 (first SAF which is dual stack with EVPN)
- Slide 5 Interaction with other BGP AFI/SAFs (2/2)
        - Interaction with base BGP-LS address family
- Slide 6 BGP-only Data center routing
        - diagram, discussion on that diagram (shows underlay, overlay and
        overall TE environment)  Focus on cloud in middle / underlay
- Slide 8 Sparse BGP Peering and BFD Peering
        - if you have dense topology, you may not want BGP on every link
        - Liveness detection outside of BGP (link status can be BFD)
        - IBGP case.  EBGP case, may need to be done differently (wanted to
        leave open for IBGP or EBGP)
- Slide 9 BGP SPF Data Center Spares Peering Example
        - diagram.  Show sessions vs. topology

- Slide 10 Bi-conneted peer heuristic (new section)
        - new area, not a lot of comments
        - routers should know what are your northbound and southbound ports
        - work in other WGs discuss how to know

- Slide 11 BGP SPF Bi-Connected Heuristic
        - diagram.  spines and leaves .  discussion on slide on how leaves peer
        to spines - Q: Randy: may not be comfortable with partial topology
        (prefer full connectivity - maybe) - C; we should have full mesh of
        sessions without updates on all of them. - C: Park conversation for
        later / list

- Slide 12: BGP Discovery Mechanisms
        - We need a mech. Three current options: LLDP, LSOV, and BGP peer
        discovery (draft-xu-idr-neighbor-autodiscovery) - Comment, LSOE has not
        other owner, could work on it (opinion) - Chair: comment on where to
        have / discuss need for BGP discovery mech.  Mention of ECP (Edge
        Control Protocol).  we should discuss what we expect form such a
                - the ECP must be new, I have not heard of it.
        - C: Keyur, I cannot find it in IETF.  Comment it’s in IEEE, not in
        IETF.  It’s hard to modify these protocols (the protocols need to be
        extendable) - C: Randy: if we can describe what we need, then we can
        describe the API, and then protocols would need to meet the API.

- Slide 13: DCI and Non-Data Center Applicability
        - put sections for questions that people asked.
        - DCI does not seem to fit here / that’s more of a GW function
        - Non DC use?  we are not talking about that now

- Slide 14: BGP SPF Security
        - Not really different the classic BGP

- Slide 15: BGP-LS SP Applicability Discussion Points
        - What else needs to go into draft
        - some issues are about scaling and assumptions
        - routing policy.  discussions of aggregation
        - partitioning of BGP-LS domains ? - we may not want to use AS to be
        that partition
                - Randy: confederations? Acee- possible

- Slide 16: Next Steps
        - Consider for WG adoption
        - Discovery mech?
        - Refine Discussions
        - Chair : where are we at? is this ready for adoption?

Chair : any more comments?

<< Discuss of neighbor and liveness discussions >>

- Chair: with respect to neighborship, or liveness - we should create a common
understanding of what is needed/ requirements.  we can use this to compare this
to options.  This does not mean the solution space will be in our working
group. location is separate discussion.


= List Items

- Adoption for Applicability
- Discussion on Requirements for Liveness and Neighbor Discovery
- Ensure we have discussion on any prototypes being developed