[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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


   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

   MRIB    Multicast Routing Information Base, as defined in PIM

   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",
   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:

   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,

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,

   [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

              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,

   [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

   Phone: +1 617 444 3000
   Email: jholland@akamai.com
   URI:   https://www.akamai.com/

Holland                   Expires June 10, 2018                 [Page 5]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/