Chairs:
Acee Lindem <acee.ietf@gmail.com>
Jie Dong <jie.dong@huawei.com>
Date: March 20, 2025
Time: 17:00 - 18:00 (UTC+7) Thursday Session IV
Room: Boromphimarn 4
https://datatracker.ietf.org/meeting/122/session/lsvr
https://meetings.conf.meetecho.com/ietf122/?session=33979
https://notes.ietf.org/notes-ietf-122-lsvr
https://zulip.ietf.org/#narrow/stream/lsvr
https://meetecho-player.ietf.org/playout/?session=IETF122-LSVR-20250320-1000
[Chairs]
Acee Lindem joined as WG co-chair. Ketan is now the responsible AD.
BGP-SPF base and BGP-SPF applicability in DC sent to RFC Editor Queue.
WG rechartered, a Layer-3 discovery and liveness monitoring protocol added to WG deliverables.
Janos Farkas: The liaison suggests the two groups discuss the way forward together. There will be back-to-back IETF/IEEE meeting in July. Virtual meeting is also possible. LLDP has been extended to support multiple PDUs. IEEE suggests new protocols to be backward compatible. There was a draft on extending LLDP for LSVR needs: draft-congdon-lsvr-lldp-tlvs.
Russ Housley: As the liaison manager between IETF and IEEE, we do need to reply the liason. Need to figure out what we want to say. Before ew reply, perhaps have an interim meeting where people can talk to each other.
Janos Farkas: IEEE Webex meeting can be used for the interim. Need to announce the meeting 10 days ahead.
Ketan: To clarify, the WG Charter does not specifially mention any protocol, it is just requirements. But we have a document that have worked for a long time. There are also other proposals. The WG needs to disucss, one or more meetings may be needed to reach some agreement.
Janos Farkas: Suggest to reach out Paul to have an update of the LLDP TLV draft for the discussion.
Randy Bush: I have a zoom account, could be used for the meeting.
Acee Lindem: Who would be the required attendees from IEEE? Do we need Glenn?
Janos Farkas: Yes, Glen and Paul, the meeting will also be announced to the IEEE 802.1 list.
Ketan: Is it possiable to have a technology meeting in Madrid on Saturday?
Janos Farkas: Many meetings have been arranged on Saturday. Another option is to have a meeting on Monday. IEEE provides one-day pass.
Acee: An interim meeting in April sounds good for everyone.
draft-ietf-lsvr-l3dl-14
Acee: Don't quite get the overlay and underlay example. Thought you were provisioning overlay service which can be advertised using BGP. For lookpback peering, will L3DL install a route to the loopback once the loopback peering address is discovered.
Randy: Loopback is just a special case. You can also announce the overlay prefixes.
Acee: I understand the loopback case, while for overlay service, why can't BGP do that?
Randy: We get it for free.
Keyur Patel: One use case is MAC move (of containers) can become simpler. By announcing the overlay in L3DL, it is more deterministic, and ARP or reverse-ARP is not needed.
Acee: This use case does not need to go into the draft, but better explanation of the overlay/underlay in general terms is needed.
Randy: In the draft the overlay or underlay announcement are indicated using one bit.
Ketan: About the experimental status, it is for the WG to decide. When sent to IESG, need some description about why and when (the experiment). About the use cases, suggest to be careful of adding use cases to the draft.
Jie: (As WG member) Is use case specific to BGP-SPF or general?
Randy: This is not a BGP-SPF use case. It shows how L3DL can be used in a different way, and shows another dimension of its characteristics.
Acee: Is the only pending work the cleanup of MPLS? Thought the checksum part also need to be updated.
Randy: MPLS will be the big change. Will also work on other review comments received.
Jie: So we will need another update of this document. And we will need to reply to the liaison.
Acee: The draft update, review, and Liaison discussion can be done concurrently.
draft-li-lsvr-bgp-spf-srv6-01
Zheng Zhang: Better to reuse the existing extensions defined in BGP-LS SRv6, copy functions to BGP-SPF seem duplicated, suggest to find a way to make it simpler. Does SR algorithm TLV mean we will use flex-algo in BGP-SPF too? Is this TLV necessary here?
Li Zhang: We just select the SRv6 extension TLVs which are useful to BGP-SPF, it is the simplest way to enable SRv6 in BGP-SPF.
Keyur: Algorithm was not used in the BGP-SPF base. But for SRv6 or even the base BGP-SPF, the support of slicing would become pretty attractive.
Acee: Looked at the IS-IS and OSPF extensions for SRv6. The current version of the draft describe the TLVs more than they were in the first version. It would be good to provide more guidance as to how the TLVs are being used in the BGP-SPF. Respones to Zheng Zhang's comment, we should add these things as we have use cases, we should not just have a list of TLVs. The draft need to have more text on how the TLVs are used in BGP-SPF. We can do an adoption prior to this being updated but we don't need that for the adoption call to start add BGP-SPF specifics.
Li Zhang: Will provide more clarification about the usage of the TLVs.
Jie Dong: For the TLVs which can simply be reused in BGP-LS, maybe we can just refer to the relevant document. For others, we can provide more text.
Acee: I don't think we should refer to IGP SR document for BGP-SPF specific SR processing, BGP-LS isn't using these TLVs, it isn't just readvertising them from the IGPs. We are using them for the BGP-SPF computation, I'd like to see more text as to how these TLVs are used in the context of BGP-SPF.
Keyur: This requires more detail discussion, maybe we should take that offline and have a meeting and see what can be done. This is a good work, we can issue an adoption call.
Acee: I think there is a use case for it, and we can do an adoption call.