The BGP NO_EXPORT_VIA_RS Community for Route Servers
draft-hilliard-grow-no-export-via-rs-00

Abstract

This document describes a BGP Well-known Community called NO_EXPORT_VIA_RS. This community allows BGP route server clients to instruct an Internet Exchange BGP Route Server to tag prefixes destined for other route server clients with the NO_EXPORT Well-Known Community. This mechanism allows route server clients to transitively control distribution of their prefixes in other Autonomous Systems connected to the Internet Exchange Route Server.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Status of This Memo

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 April 13, 2018.

Copyright Notice

Copyright (c) 2017 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. The BGP NO_EXPORT_VIA_RS Community
• 3. Operator Implementation Recommendations
• 4. Vendor Implementation Recommendations
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

Internet Exchange Route Servers [RFC7947] use BGP to broker network reachability information among their clients. BGP operators often wish to control distribution of their prefixes in adjacent autonomous systems. When using bilateral BGP sessions, prefix distribution control can be achieved using the BGP NO_EXPORT community defined in [RFC1997].

[RFC1997] states that the NO_EXPORT community must not be announced outside a BGP confederation boundary, so all BGP speakers that strictly interpret this document will refuse to forward prefixes tagged with this community to a EBGP peer.

Some Internet Exchange route server operators ignored the strict interpretation of [RFC1997] on this point because although it is technically more correct to interpret the NO_EXPORT community on the route server, the point of a route server is to act as a broker rather than a router. Consequently it has been argued that it is more useful for route server clients if prefixes tagged with the NO_EXPORT community are passed unaltered through the route server rather than being blocked. This approach gives route server clients the flexibility of being able to use the NO_EXPORT community to signal adjacent ASNs, even if this behaviour is not technically correct according to [RFC1997].

As there is no consensus among IXP route server operators about which is the more appropriate behaviour, the Internet Exchange Route Server [RFC7947] specification document stayed quiet on the issue, noting only in Section 2.2.4 that a route server may interpret, modify or remove specific BGP communities, as defined by local policy. This formally allowed the practice of treating the NO_EXPORT community as a transparent transitive attribute, but did not define whether NO_EXPORT should be interpreted or passed through the route server.

This allowed an operational ambiguity to continue, namely that there was no consistent way for a route server client to limit propagation of any prefixes announced to a route server.

This document resolves this ambiguity by creating a new BGP Well-Known Community called NO_EXPORT_VIA_RS, which allows BGP route server clients to instruct an Internet Exchange BGP Route Server to tag prefixes destined for other route server clients with the NO_EXPORT Well-Known Community. This mechanism provides an unambiguous and consistent way for route server clients to transitively control distribution of their prefixes in other Autonomous Systems connected to the Internet Exchange Route Server.

2. The BGP NO_EXPORT_VIA_RS Community

The BGP NO_EXPORT_VIA_RS Community is a community interpreted only by [RFC7947] Internet Exchange Route Servers. If a route server client announces a prefix tagged with NO_EXPORT_VIA_RS to a route server, the route server MUST attach the [RFC1997] NO_EXPORT community to all outbound announcements of that prefix to other route server clients. The route server SHOULD strip the NO_EXPORT_VIA_RS community from the outbound prefix announcement.

If a route server client announces a prefix tagged with both the NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the route server MUST ignore the NO_EXPORT community, and otherwise MUST handle the prefix and its attributes as specified in the previous paragraph.

If a BGP speaker that is not a route server receives a prefix tagged with NO_EXPORT_VIA_RS from a BGP peer, the BGP speaker MUST ignore the NO_EXPORT_VIA_RS community, MUST NOT treat the UPDATE as an error according to [RFC7606] and SHOULD strip the NO_EXPORT_VIA_RS community from the prefix.

This document formally updates the NO_EXPORT definition in [RFC1997] and overrides the ambiguity in Section 2.2.4 of [RFC7947] in respect of this specific community.

3. Operator Implementation Recommendations

It is possible to implement the semantics described above in many BGP implementations by using standard BGP policy language statements.

4. Vendor Implementation Recommendations

Route server implementations MUST provide a configuration switch to implement the behaviour specified in Section 2. This configuration switch SHOULD be enabled by default.

5. Security Considerations

The purpose of the NO_EXPORT_VIA_RS BGP Community is to control the NO_EXPORT Community, so there are no additional security considerations outside those associated with the NO_EXPORT community.

Network administrators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454].

6. IANA Considerations

IANA is requested to register NO_EXPORT_VIA_RS in the "BGP Well-known Communities" registry.

• NO_EXPORT_VIA_RS (= TBD) (IANA suggested: 0xFFFFFF05)

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses