Internet DRAFT - draft-jholland-idr-mcast-source-nexthop-over-amt
draft-jholland-idr-mcast-source-nexthop-over-amt
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
Holland Expires June 10, 2018 [Page 1]
Internet-Draft MBGP For Multicast Source Via AMT December 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Multicast Source Reachability . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Holland Expires June 10, 2018 [Page 2]
Internet-Draft MBGP For Multicast Source Via AMT December 2017
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 [RFC2119].
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
Holland Expires June 10, 2018 [Page 3]
Internet-Draft MBGP For Multicast Source Via AMT December 2017
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 [RFC4760], 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,
<https://www.rfc-editor.org/info/rfc2119>.
Holland Expires June 10, 2018 [Page 4]
Internet-Draft MBGP For Multicast Source Via AMT December 2017
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>.
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", draft-ietf-mboned-interdomain-peering-bcp-14
(work in progress), October 2017.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[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, <https://www.rfc-editor.org/info/rfc7761>.
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/
Holland Expires June 10, 2018 [Page 5]
