This document discusses providing additional context for peer addresses in BMP Loc-RIB messages. It received feedback that directly updating the existing peer address field could cause implementation issues. It therefore proposes using new TLVs to include the receiving peer address, previous VRF name, origin VRF name, and VRF name sequence to provide full context for paths that were imported between VRFs. There was debate on whether the origin VRF TLV alone would suffice or if the full import path provides useful monitoring information. It also asked if the idea of updating the peer address field should be canceled in favor of just using new TLVs.

1. BMP Loc-RIB: Peer address
draft-francois-grow-bmp-loc-peer-01
IETF 117
Pierre FRANCOIS, INSA-Lyon
Maxence YOUNSI, INSA-Lyon
Paolo LUCENTE, NTT

2. Agenda
● Reminder
● Feedback received
● Update
● Debate

3. Reminder
● BMP Loc RIB (RFC 9069) provides a view on Loc-RIB
○ Peer-address field in per-peer header is zero-filled
■ You don’t know which peer gave you the paths you put in Loc-RIB
■ Requires effort when digging in the data,
especially in multi-path/add-path scenarii
○ Unfortunate as BMP implementations may have the information
● We’d like to allow to provide this information

4. How
● Draft opens two options
● Allow the peer-address to be non zero-filled
○ Backward compatibility…
○ Default behaviour remains zero-filled, cfg to enable the behaviour
● Use draft-ietf-grow-bmp-tlv
○ TLV type "Peer-Address TLV" to be reserved
○ Ignored by collectors who can’t recognize it by design

5. Feedback #1: Option 1 is messy
● Option 1: Allow the peer-address to be non zero-filled
● Nice on paper
● Maybe less so IRL
○ Implementations may suffer as update was not anticipated
in the code and new flags may be improperly dealt with
○ Operator will have to pay attention and configure stuff
selectively based on router and collector capability, maybe
for things not to break

6. Feedback #2: VRF Imports
● “It’s nice to get to know the peer from which I received a loc-rib
path, but if the path was imported from another VRF, you’re
unable to figure out the right context for this peer address”
● True…

7. draft-francois-grow-bmp-loc-peer-01
● Rx Peer Address TLV
● Previous VRF Name TLV
● Origin VRF Name TLV
● VRF Name Sequence TLV

8. Previous VRF Name TLV
● Loc-RIB on VRF V
● A Path received in VRF cust1 was imported into global, then into V
⇒
● Previous VRF Name TLV is: “global”
● (V is already identified through RFC9069)

9. Origin VRF Name TLV
● Loc-RIB on VRF V
● A Path received in VRF cust1 was imported into global, then into V
⇒
● Origin VRF Name TLV is: “cust1”
● (V is already identified through RFC9069)

10. VRF Name Sequence TLV
● Loc-RIB on VRF V
● A Path received in VRF cust1 was imported into global, then into V
⇒
● VRF Name Sequence TLV is:
[“global”, “cust1”]
● (V is already identified through RFC9069)
● Pro
○ Everything in one message, no need to work on collection-side
● Cons
○ Maybe difficult for some BMP implementations to obtain the sequence from the context
where this was message was generated
○ Devs won’t like it

11. Self originated prefixes
● Zero-filled RX Peer Address TLV means it was self originated in the
corresponding VRF

12. Debates
● “Origin VRF TLV is the only one needed”
○ For the purpose of resolving the peer address, yes
○ Yet the VRF import information is a nice piece of information for
monitoring purposes…
● Ok solution to deal with VRF imports?
● Cancel idea of updating RFC9069 Peer Address field?

13. WG Doc?