| Internet-Draft | Group Policy ID BGP Extended Community | October 2022 |
| Lin & Drake | Expires 23 April 2023 | [Page] |
Group Based Policy can be used to achieve micro or macro segmentation of the user traffic. For Group Based Policy, a Group Policy ID, as known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This specification defines a new BGP extended community that can be used to propagate Group Policy ID through a route advertisement in the control plane. This is to facilitate policy enforcement at the ingress node when the optimization of network bandwidth is desired.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
EVPN: Ethernet Virtual Private Networks, as per [RFC7432].¶
GBP: Group Based Policy¶
VXLAN: Virtual Extensible LAN¶
NVO: Network Virtualization Overlay¶
In the virtualized overlay network where EVPN with VXLAN encapsulation is used as the overlay solution, without external management software or controller, the propagation of a Group Policy ID is done through the data plane. The source Group Policy ID is encoded in the VXLAN header before the user traffic is sent to the VXLAN tunnel. The encoding format of a Group Policy ID in the VXLAN header is specified in [I-D.smith-vxlan-group-policy].¶
When the source Group Policy ID is propagated through the data plane to the remote VXLAN tunnel endpoint, the policy enforcement is carried out at the egress node based on both the source and destination Group Policy tags. The policy rule for the source and destination Group Policy Tags may result in the traffic being dropped at the remote VXLAN tunnel endpoint which is the egress node. To send the traffic all the way from an ingress node and then drop it at an egress node is an inefficient use of the network bandwidth.¶
To optimizes the network bandwidth usage, it may be desirable to have policy enforcement done at the head-end of a VXLAN tunnel that is the ingress node for the user traffic. To accomplish this, there is a need to communicate the destination Group Policy ID from the egress node to the ingress node. This document defines a Group Policy ID BGP Extended Community that can be used in the control plane to achieve the propagation of Group Policy ID from an ingress node to an egress node.¶
In an EVPN VXLAN overlay network, a policy group tag may be assigned based on the MAC, IP, port, VLAN, etc, or a combination of the above. Similar to the MAC/IP addresses in the EVPN network, once the Policy Group ID is known for a local host/server/VM attached to an EVPN network, its Group Policy ID can be advertised to other Network Virtualization Edge devices in the control plane through the Group Policy ID extended community. The scheme used for classification and allocation of Policy Group IDs used for GBP in an EVPN overlay network with VXLAN encapsulation is outside the scope of this document.¶
Policy group tag prorogation in the EVPN/BGP control plane can be applied to the EVPN type-2 MAC/IP route[RFC7432], EVPN type-3 Ethernet Inclusive Multicast route [RFC7432] or EVPN type-5 IP host and prefix route [RFC9136]. If Policy Group ID is allocated for a MAC address, IP host or prefix address through the GBP classification scheme, EVPN can encode its Group Policy ID through the Group Policy ID extended community and advertise it alongside its corresponding EVPN route.¶
For the flows that the ingress VXLAN tunnel endpoint has learned its destination group policy tag through EVPN/BGP control plane signaling, the policy enforcement can be thus carried out right at the ingress node. Otherwise, policy enforcement can be carried out at the egress node. If policy enforcement is carried out at the head-end VXLAN tunnel, the ingress node MUST set the GBP applied bit, the A-bit as it is specified in [I-D.smith-vxlan-group-policy], to 1 in the VXLAN header before forwarding the traffic to the VXLAN tunnel. Otherwise, the ingress node set the A-bit to 0 in the VXLAN header.¶
In the EVPN interworking use case as it is specified in the [I-D.ietf-bess-evpn-ipvpn-interworking], two or more EVPN networks/domains are interconnected by a layer 3 IP-VPN network with VPN-IPv4/VPN-IPv6 BGP address families. To support ingress policy enforcement, the Policy Group ID extended community needs to be propagated by the GW PEs sitting at the border of an EVPN domain and IP-VPN domain from one domain to another.¶
For the Uniform-Propagation-Mode defined in the [I-D.ietf-bess-evpn-ipvpn-interworking], when propagating an EVPN IP prefix route across the domain boundary to IP-VPN network, the Gateway PE SHOULD propagate communities, extended communities and large communities except for all the EVPN extended communities. The Policy Group ID extended community defined in this document is a new transitive Opaque Extend Community. It is not subject to stripping at the GW PE when the Uniform-Propagation-Mode is used.¶
The Group Policy ID BGP Extended Community is a new transitive Opaque Extended Community with a Type value of 0x03. This extended community may be advertised along with an EVPN type-2 MAC/IP route, EVPN type-3 Ethernet Inclusive Multicast route, and EVPN type-5 IP prefix route. This new Opaque Extended Community enables the EVPN route it attached to propagate the Group Policy ID used for Group Based Policy in the control plane.¶
When the "Uniformed-Propagation-Mode" is used under the EVPN and IPVPN interworking use case, the Group Policy ID extended community is carried over by the GW PE when a route for a given IP or IPv6 prefix is propagated from one domain to another with a different address family.¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x03 | Sub-Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Group Policy ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+¶
Group Policy ID (GPI): The GPI field is 16-bit long and it encodes the value of a Group Policy ID.¶
The reserved fields MUST be set to zero by the sender and ignored by the receiver.¶
This document requests a codepoint value in the Sub-type registry of Type 0x03 Transitive Opaque Extended Community.¶
Sub-Type Name Reference TBD Group Policy ID Extended Community [this document]¶
All the security considerations for BGP extended communities can be applied there. Attackers may alter the value carried in a BGP extended community. In this case, the Group Policy ID carried in the Group Policy ID field can be altered by attackers, which could lead to the wrong policy rule being enforced on the user traffic.¶
The authors would like to thank Jeffrey Zhang, Jeff Haas for their careful review and valuable feedbacks.¶
We also would like to thank Prasad Miriyala and Selvakumar Sivaraj for their contributions.¶