Chairs:
Acee Lindem <acee.ietf@gmail.com>
Jie Dong <jie.dong@huawei.com>
https://datatracker.ietf.org/meeting/123/session/lsvr
https://meetecho.ietf.org/client/?session=34390
https://notes.ietf.org/notes-ietf-123-lsvr
https://zulip.ietf.org/#narrow/stream/lsvr
===============================================================================
Date: July 24, 2025
Time: 12:00 - 13:00 (UTC+2) Thursday Session II
Room: Tapices
Jie Dong presenting (see slides).
Keyur Patel gave an Update at the microphone:
Paul Bottoroff (See Slides)
Acee Lindem: Why do you say application interface for information
disemination needs to be standardized?
Paul: Maybe it doesn't. It just isn't part of LLDP.
Russ Housley: Is the direction to use LLDP for layer-2 discovery and
everything else will be on layer-3, including BFD for layer-3 liveness.
Is this understanding correct?
Paul: BFD is always an option, can also be enabled in LLDP.
Keyur: Want to keep BFD simple. Think Russ summarized it perfectly.
Jie: (As WG member) A Clarification question on the organizationally
specific TLV?
Paul: This is already standardized and allocated by IEEE. One OUI is for
IETF. The subtypes are for the IETF to define and are controlled by
IANA.
Jie: Can there be multiple of these TLVs?
Paul: Yes, you can have as many as you like.
Ketan Talaulikar: I heard the request for WG adoption, and heard the
L3DL authors are looking at using LLDP for the discovery part, and other
information are carried using L3DL. What is your views on that?
Paul: Technically it is viable to do that, but not sure it is necessary.
Don't see the advantage of using L3DL for information transfer. You can
do the same with the extended LLDP.
Ketan: What is the relationship with the LLDP BGP neighbor discovery
draft in IDR?
Paul: Demonstrates the usage of OUI TLV in LLDP.
Ketan: In IANA, it can have a flat code point space instead of another
level of hierarchy.
Acee: IANA registry is needed for OUI subtype allocations.
Ketan: (To the chairs) What is the plan?
Keyur: Need to discuss on the mailing list. Want to discuss the
motivations for L3DL design and the pros and cons of the two approaches.
Will consider to levarage LLDP as much as possible, while the reasons of
introducing L3DL need to be well discussed on the list. And as an author
on both the L3DL draft and IDR BGP neighbor discovery draft and a router
vendor, I understand the tradeoffs.
Jie: Makes sense.
Paul: Support to debate on the mailing list. After the interim, there
wasn't much discussion on the mailing list.
Ketan: Would like to encourage the discussion on the mailing list
between this and next IETF.
Acee: (As chairs) We would like to see a decision before the next IETF.
Jie: Please use the mailing list for discussion.
draft-li-lsvr-bgp-spf-srv6-02
[Li Zhang]
Acee: The TLVs are much better defined and the validation for BGP-LS
advertisement. Would like to have high-level description of the usage of
the TLVs, and the installation of the information into the RIB, could
use reference to SR architecture.
Li Zhang: Do you mean we can remove the redefinitions in the draft?
Acee: No - you need the definition in the context of BGP-LS-SPF. You
don't need to provide pseudo-code as is done in the BGP-SPF base
document. You just need to describe the usage of the SRv6 TLVs and the
installation of SIDs in the IPv6 RIB.
Li Zhang: We can continue the discussion on the list.
Jie: Suggest to check the IGP SRv6 documents and see what can be
referred to in terms of the behavior.
Ketan: IEEE 802.1 plenary will be held in this hotel next week. Consider
use the opportunity to discuss with IEEE 802.1 folks.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 55 minutes