Export of BGP VPN Information in IPFIX

Abstract

This document introduces new IP Flow Information Export (IPFIX) information elements to carry information that can be used to identify the egress PE in BGP VPN scenarios.¶

1. Introduction

BGP/MPLS VPN, as described in [RFC4364], is a method that uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. Each route within a VPN is assigned an MPLS label.¶

Typical MPLS VPN scenarios include:¶

• MPLS VPN over MPLS traffic engineering (MPLS-TE) tunnel: The MPLS-TE tunnel can be built based on RSVP-TE LSP [RFC5824] or SR-MPLS Policy.¶
• MPLS VPN with MPLS best effort tunnel: A single MPLS label/SR-MPLS SID for the FEC on the egress PE is used to tunnel the VPN traffic over the backbone.¶

For SRv6 VPN services, [RFC9252] defines procedures and messages for SRv6-based BGP services, including L3VPN, EVPN, and Internet services. SRv6 Service SID refers to an SRv6 SID associated with one of the service-specific SRv6 Endpoint Behaviors on the advertising PE router.¶

As in [RFC9252], typical SRv6 VPN scenario includes:¶

• SRv6 service with SRv6-TE connectivity: To provide SRv6 service in conjunction with an underlay Service Level Agreement (SLA) from the ingress PE to the egress PE, the egress PE colors the overlay service route with a Color Extended Community [RFC9012] for steering flows for those routes. The ingress PE encapsulates the payload packet in an outer IPv6 header with the SR Policy segment list associated with the related SLA along with the SRv6 Service SID associated with the route using the Segment Routing Header (SRH) [RFC8754].¶
• SRv6 service with best-effort(SRv6-BE) connectivity: The egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay between the PEs only needs to support plain IPv6 forwarding.¶

When monitoring traffic flows on the ingress PE in a network with BGP VPN deployed, the network monitor may want to know the following information:¶

• Which egress PE is the flow forwarded to?¶
• How is the traffic transmitted through the network?¶

This document introduces new IP Flow Information Export (IPFIX) information elements to carry information that can be used to identify the egress PE in BGP VPN scenarios.¶

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document makes use of the terms defined in [RFC7011], [RFC8402] and [RFC9252].¶

The following terms are used as defined in [RFC7011]:¶

• IPFIX¶
• IPFIX Information Elements¶
• Metering Process¶
• Template Record¶
• Data Record¶
• Collector¶

The following terms are used as defined in [RFC8402]:¶

• Segment Routing (SR)¶
• Segment List¶
• SRv6¶
• SR-MPLS¶
• Segment Identifier (SID)¶

The following terms are used as defined in [RFC9252]:¶

• SRv6 Service SID¶

3. New IPFIX IEs for VPN Egress PE Information

The following subsections define different types of IEs to fulfill the requirement to obtain the egress PE information via IPFIX.¶

4. Operational Considerations

The IE bgpNextHopIPv4Address(18) and bgpNextHopIPv6Address(63) define the IPv4/IPv6 address of the next (adjacent) BGP hop, which provide the generic BGP next-hop address. If BGP VPN route is the only BGP route deployed on the PE, the value carried in IE 18 or IE 63 indicates the next hop address of the BGP VPN route. However, when there are many types of BGP route used in the network (e.g., BGP VPN [RFC4364] and BGP-LU [RFC8277] are deployed together), it is not clear which type of the BGP route the next BGP hop carried in IE 18 or IE 63 is.¶

To avoid ambiguity between the IEs for the generic BGP next hop and VPN-specific next hop, the following implementation guidance is provided:¶

• For VPN flows, the bgpVpnNextHopIPv4/bgpVpnNextHopIPv6Address IE SHOULD be preferred.¶
• It is RECOMMENDED not to use the generic bgpNextHopIPv4/bgpNextHopIPv6Address IE for VPN flows to prevent the simultaneous export of two semantically overlapping IEs for the same flow.¶
• Collectors and applications processing IPFIX records SHOULD prioritize the bgpVpnNextHopIPv4/bgpVpnNextHopIPv6Address IE over the generic bgpNextHopIPv4/bgpNextHopIPv6Address IE when both are present, as the VPN-specific IE provides more precise information.¶
• When generic bgpNextHopIPv4Address or bgpNextHopIPv6Address IEs appear alone in an IPFIX Record, their specific routing context (e.g., BGP unicast, BGP VPN) is ambiguous and cannot be determined solely from the IE itself. If the routing context is desired, it is RECOMMENDED to combine the bgpNextHopIPv4Address or bgpNextHopIPv6Address IEs with additional information. Such additional information may come from external sources, e.g., network planning and IP address allocation policies. The detailed method is implementation-specific and out of scope for this document.¶

In the multi-as backbones, if inter-AS option A or option B with BGP next-hop changed are used as described in Section 10 of [RFC4364], the address of the egress PE can't be obtained via "bgpVpnNextHopIPv4Address" or "bgpVpnNextHopIPv6Address" since the next hop address of the BGP VPN route received by the ingress PE is the address of the ASBR instead of the address of the egress PE.¶

In inter-AS Option C as in Section 10 of [RFC4364], the BGP next hop is preserved end-to-end across AS boundaries. In this case, the bgpVpnNextHopIPv4Address or bgpVpnNextHopIPv6Address IE carries the address of the egress PE directly.¶

5. Security Considerations

The new IPFIX Information Elements defined in this document export sensitive network infrastructure information, including BGP-VPN next hop addresses and SRv6 service SIDs. Exposure of such information could aid reconnaissance against the VPN backbone. Therefore, access to collected data SHOULD be restricted to authorized personnel and systems, and operators SHOULD evaluate the necessity of exporting these IEs in untrusted environments. Security considerations in [RFC7011] and [RFC7012] apply to this document.¶

Other security considerations for BGP/MPLS VPN in [RFC4364] and for BGP Overlay Services Based on SRv6 in [RFC9252] apply to this document as well.¶

6. IANA Considerations

This document requests IANA to create new IEs under the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].¶

7. Acknowledgement

The authors would like to thank Thomas Graf, Chongfeng Xie, Benoit Claise, Stephane Litkowski and Paul Aitken for their helpful comments and discussions.¶

8. References