Skip to main content

Minutes IETF112: lsvr
minutes-112-lsvr-00

Meeting Minutes Link State Vector Routing (lsvr) WG
Date and time 2021-11-09 14:30
Title Minutes IETF112: lsvr
State Active
Other versions plain text
Last updated 2021-11-10

minutes-112-lsvr-00
LSVR Notes - Tuesday November 9, 2021 14:30 UTC
* Note well discussed
* Introduction slides (Gunter)
* Discussed agenda
** Welcome & agenda bashing (Chairs) - 10 min
** Updates on drafts:
*** BGP Link-State Shortest Path First (SPF) Routing -  (Keyur Patel) - 15  Min
*** BGP-SPF Flooding Reduction – (Huaimo Chen) – 15 Min
*** LLDPv2 Status Update – (Paul Congdon) - 15 Min
*** LSVR WG re-charter update by wg-chairs - (Chairs) - 5 Min

Attendees - 41 at 9:42AM EST

LSVR WG Status
* Documents sent for last call, sent back for edits/updates
* lsvr-bgp-spf-15 including AD and RTG-DIR review
* draft-ietf-lsvr-applicability-08: Applicability draft ver 7 received had list
of feedback from the AD and was sent back and to be processed into release -08

WG Documents
* drafts are on pending state - need confirm on recharter
* L3DL ULPC and signing

IEEE Status
* LLDPv2

LSVR BGP SPF IETF112 Online
* Keyur speaking
* Version 15 of draft is out
* Terminology is now “BGP SFP speakers”
* Clarification text of NLRI
* Clarification in SPF algorithm section (next hops for ECMP). number links
preferred over unnumbered links, and highest address preferred * Clarification
for SPF section for matching criteria * Added error handling for IPv4
prefix-lengtht TLV * AD comments, now incorporated * Error handling, security
section, interaction with BGP-LS/TLVs, SPF section augmented, minor nits *
Latest status ** Changes so far, min impact on implementation (error handling
had some impact and change needs) * Summary ** received reviews from WG
members, and had review from routing directorate (issues were addressed) **
Draft is considered in stable state, complete the last call ** One Open source
and one with vendor ** only support for new SAFIs needed, so draft should be
stright forward (by next IETF113) Questions * none

BGP-SPF Flooding Reduction
* Huaimo Chen
* discuss bgp-spf flooding, flooding procedures, protocol extentions
* diagram showing speaker flooding / LS process (with BGP-SPF speakers)
* next slide (bgp-spf flooding in node connections models)
* revised flooding procedures discussed (slides 5 and 6)
* discussion of flooding topologies for each node
* discuss protocol extensions for RR model
* discuss node connections model
Questions
* Keyur - how does this works with part implementation (extension)
** (A) if only some have the features, the node with flood reduction, they will
implement, but other nodes will still flood to all nodes ** (A) for router
reflector mode, that case will require some more considerations * Acee - maybe
what we are doing by splitting RRs may be enough (for sparse mode sessions).
What you are doing with selecting 1 RR for groups, may be enough (vs. many
different algorithms) ** (A) for sparce mode we should use similar procedures.
** Acee - this seems complex, and having it implemented * Gunter - the dynamics
of sending link state info over reliable tcp based sessions or igp type
neighborship sessions is different, hence this type of complexity is maybe
undesired ** (A) the flooding is similar, and amount of link-state is still
there

IEEE P802.1ABdh XLLDP/LLDPv2
* Paul Congdon
* IEEE update
* timelines started in Sep 2019, and publication is expected as soon as Dec
2021. * Draft as written is sufficient for implementation * LLDPv2 supported
more than one frame * Discuss original LLDP (v1) (diagram) * Discuss LLDPv2,
updated impl. new TLV is a manifest TLV (more info avail). Rec agent sends
request frame, then sender will send extension PDU (new format) * New TLVs
“Manifest”, “Extension”, “Identifier” and new PDUs (normal, ext request,
extension LLDPDU) * backwards comp. older implementation will ignore the new
PDUs/TLVs * Use unicast when using extensions (vs flooding for LLDPv1)

Discuss Re-charter
* BGP-SPF needs to be processed to IESG
* BGP-SPF needs a technology like LLDPv2 and/or L3DL (if security is needed),
however the charter should not need to mandate either of those * Need to
augment the charter to be able to do that work * Recharter by 113 with
discussion on the list when we are going forward