Minutes interim-2018-lsvr-01: Fri 16:30
minutes-interim-2018-lsvr-01-201806081630-00
| 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 |
minutes-interim-2018-lsvr-01-201806081630-00
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
Notes:
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
mechanism
- 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