Inter-Domain Routing J. Holland
Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track December 7, 2017
Expires: June 10, 2018

MBGP Extensions For Multicast Source Reachability Via AMT
draft-jholland-idr-mcast-source-nexthop-over-amt-00

Abstract

This document describes a BGP-based method to communicate source IP reverse-path reachability for sources of multicast IP traffic which is available via AMT (RFC 7450). This document defines a new SAFI (Subsequent Address Family Identifier) Parameter type for MBGP which declares the next hop for RPF (Reverse Path Forwarding) of a source IP to be the AMT tunnel discovered via an explicitly provided anycast IP address for AMT Relay Discovery.

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 June 10, 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

AMT [RFC7450] provides a way to forward multicast traffic from an AMT relay in a multicast-capable domain to an AMT gateway in a different multicast-capable domain over a unicast-only network.

AMT also defines a well-known anycast address for relay discovery. However, a relay needs to have multicast connectivity sufficient to receive traffic from a source in order to forward traffic from that source. In some cases, multicast traffic sources may not have multicast connectivity to a relay which can be discovered by a gateway using the well-known address. This issue is described in more detail in [I-D.ietf-mboned-interdomain-peering-bcp], sections 3.3, 3.4, and 3.5.

A service provider may provide multicast traffic and also provide AMT relays that can receive their multicast traffic and forward it to AMT gateways, but the AMT gateways in receving networks need a way to discover an appropriate AMT relay for the sources of IP multicast channels with subscribers in that network.

This document defines such a mechanism by using BGP with Multiprotocol Extensions [RFC4760], with a new NLRI (Network Layer Reachability Information), described in Section 3.

Although it is also possible to provide multicast connectivity between domains via a GRE tunnel protected with IPSEC, and although a BGP connection between domains is likely to operate over such a tunnel, the service provider has more flexibility in load balancing and automated distribution of multicast traffic-forwarding responsibilities among different forwarders by using AMT instead of using the same GRE tunnel that communicates the routing information.

2. Terminology

AFI
Address Family Information, as defined in BGP
AMT
Automatic Multicast Tunneling [RFC7450]
BGP
Border Gateway Protocol [RFC4271]
MBGP
Border Gateway Protocol with Multiprotocol Extensions [RFC4760]
MRIB
Multicast Routing Information Base, as defined in PIM [RFC7761]
NLRI
Network Layer Reachability Information, as defined in MBGP
SAFI
Subsequent Address Family Information, as defined in MBGP

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 RFC 2119.

3. Multicast Source Reachability

This document defines a new NLRI called the "Multicast Source over AMT" NLRI. The Multicast Source over AMT NLRI is carried in BGP [RFC4271] using BGP Multiprotocol Extensions [RFC4760] with an Address Family Identifier (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of TBD1.

The following is the format of the Multicast Source over AMT NLRI:

+---------------------------------+
|       Relay-AFI (2 octets)      |
+---------------------------------+
|   AMT Relay Discovery Address   |
+---------------------------------+

The value of the AFI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the Multicast Source over AMT NLRI determines whether the source route is IPv4 or IPv6. The value of the Relay-AFI field in the Multicast Source over AMT NLRI indicates whether the Relay Discovery Address is IPv4 or IPv6. (AFI 1 indicates IPv4, AFI 2 indicates IPv6.)

The route for the source address MUST NOT be added to any unicast RIB (Routing Information Base) as a result of processing this NLRI. The route SHOULD be added to MRIBs (Multicast Routing Information Bases) as appropriate according to the BGP peering configuration.

In order for two BGP speakers to exchange labeled Multicast Source over AMT NLRIs, they MUST use a BGP Capabilities Advertisement to ensure that they both are capable of properly processing such an NLRI. This is done as specified in [RFC4760] by using capability code 1 (multiprotocol BGP) with an AFI of 1 or 2 and a SAFI of TBD1.

4. IANA Considerations

IANA has assigned the SAFI Value TBD1 from the SAFI Value registry defined in Section 9 of RFC 4760, to denote the new NLRI defined in Section 3 of this document.

[TO BE REMOVED: During experimental development, the private value 242 from that registry will be used in our implementation.

This registration should take place at the following location: https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml

Value    Description
-----    -------------------------
TBD1     Multicast Source over AMT

]

5. Security Considerations

The behavior defined in this document will cause an AMT Gateway to open new tunnels to IP addresses specified by an external AS. As such, this has the same security considerations as section 6.2 and section 6.3 of [RFC7450], in addition to the usual security implications of running the underlying BGP, as described in [RFC4271] and [RFC4272].

It is RECOMMENDED that implementations provide a configurable limit on the number of unique AMT Relay Discovery IPs.

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015.

6.2. Informative References

[I-D.ietf-mboned-interdomain-peering-bcp] Tarapore, P., Sayko, R., Shepherd, G., Eckert, T. and R. Krishnan, "Use of Multicast Across Inter-Domain Peering Points", Internet-Draft draft-ietf-mboned-interdomain-peering-bcp-14, October 2017.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z. and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016.

Author's Address

Jacob Holland Akamai Technologies, Inc. 150 Broadway Cambridge, Massachusetts 02142 USA Phone: +1 617 444 3000 EMail: jholland@akamai.com URI: https://www.akamai.com/