Extended Communities Derived from Route Targets
draft-zzhang-idr-rt-derived-community-00

idr                                                             Z. Zhang
Internet-Draft                                          Juniper Networks
Intended status: Informational                         February 22, 2021
Expires: August 26, 2021

            Extended Communities Derived from Route Targets
                draft-zzhang-idr-rt-derived-community-00

Abstract

   This document describes a way to derive an Extended Community from a
   Route Target and its use cases.

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 August 26, 2021.

Copyright Notice

   Copyright (c) 2021 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.

Zhang                    Expires August 26, 2021                [Page 1]
Internet-Draft               RT-derived ECs                February 2021

1.  Introduction

   Consider a VPN with 10 PEs.  A Route Target (say RT1) [RFC4360] is
   configured for the VPN and all PEs will import VPN routes with RT1
   attached.  The RT is an Extended Community (say EC1), with its sub-
   type being 0x02.  While RT1 and EC1 have the same encoding, typically
   when we mention a Route Target, its property of being able to control
   the route propagation and importation is implied.  When we just
   mention an Extended Community, that property is not implied.

   Now consider that another BGP route needs to be imported by some but
   not all those PEs.  The route could be of any SAFI/type (does not
   need to be a VPN prefix), but it needs to be associated with the VPN
   on those importing PEs.  The exact meaning of "association" here does
   not matter, but the key is that those PEs need to know that the route
   is related to that VPN.

   To control the propagation to and importation by those PEs, a
   different Route Target (say RT3) is attached to the route.  For those
   PE to associate the route with the VPN, an Extended Community (say
   EC2) is attached.  Even though RT1/EC1 is already tied to the VPN,
   EC2 needs to be different from RT1/EC1, because if EC1 was used, the
   route would be propagated to and imported by all the 10 PEs.  EC2
   cannot be the same as RT3 either, because there could be other routes
   to be propagated to and imported by those same set of PEs yet those
   other routes are not related to the VPN.

   While EC2 can be any Extended Community (that is not a RT) configured
   on the originating and receiving PEs to map it to the VPN, it is
   convenient if EC2 is derived from the RT1/EC1, e.g. the sub-type of
   RT1/EC1 is changed to a new known value while everything else remains
   the same.  We call this a Route Target derived Extended Community, or
   RT-derived EC.  A new sub-type is assigned specifically for this
   purpose (see IANA considerations).

   This document is for information only.  Any protol/feature that can
   take advantages of the convenience of generic RT-derived ECs may use
   them, or not use them at its own discretion.

2.  Use Cases

   The following are a few examples of use cases.  To reiterate, these
   are example scenarios where generic RT-derived ECs could be used
   (when the routes to which they are attached provide enough context).
   It is not the intention of this document to mandate that it must be
   used.

Zhang                    Expires August 26, 2021                [Page 2]
Internet-Draft               RT-derived ECs                February 2021

2.1.  EVPN EVI-RT Extended Community

   Section 9.5 "EVI-RT Extended Community" of
   [I-D.ietf-bess-evpn-igmp-mld-proxy] describes a situation similar to
   the above.  As a solution, four EVPN specific EVI-RT ECs are defined,
   each mapping to a type of Route Target for the corresponding EVPN
   instance.

   As a theoretical alternative, a RT-derived EC described in this
   document could be used instead - just derive a generic EC from the
   EVI RT.  Note that this document does not attempt to change the
   existing procedures in [I-D.ietf-bess-evpn-igmp-mld-proxy], but
   merely use it for illustration purposes.

2.2.  Leaf Discovery with Controller Signaled BGP-MVPN

   In Section 2 "Alternative to BGP-MVPN" of
   [I-D.ietf-bess-bgp-multicast-controller], BGP MCAST-TREE SAFI
   signaling can be used for a controller to program multicast
   forwarding state in VRFs of ingress/egress PEs, instead of relying on
   distributed BGP-MVPN signaling.  For the controller to learn egress
   PEs of a VPN customer multicast tree (so that it can build/find a
   corresponding provider tunnel), egress PEs signal leaf information to
   the controller via Leaf Auto-Discovery routes.  The routes carry a
   Route Target for the controller (so that only the controller receives
   them), and an EC derived from the VPN's Route Target (so that the
   controller knows which VPN they are for).

3.  Security Considerations

   To be provided.

4.  IANA Considerations

   This document requests IANA to assign a new sub-type "RT-derived-EC"
   from the following registries:

   o  Transitive Two-Octet AS-Specific Extended Community Sub-Types

   o  Transitive Four-Octet AS-Specific Extended Community Sub-Types

   o  Transitive IPv4-Address-Specific Extended Community Sub-Types

   o  Transitive IPv6-Address-Specific Extended Community Sub-Types

   o  Non-Transitive Opaque Extended Community Sub-Types

   o  EVPN Extended Community Sub-Types

Zhang                    Expires August 26, 2021                [Page 3]
Internet-Draft               RT-derived ECs                February 2021

   The same value is preferred across these registries.

   If and when additional Extended Community types are defined with a
   Route Target sub-type, the "RT-derived-EC" sub-type may also be
   registered for those types, preferably with the same value.  With
   that consideration, it is preferred that the sub-type value is
   assigned from the higher end of the "first come first serve" area, to
   increase the probability of assigning the same value for future types
   of Extended Communities with Route Target sub-type.

5.  Acknowledgements

   The authors thank Jeff Haas for his valuable comments and
   suggestions.

6.  References

6.1.  Normative References

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

6.2.  Informative References

   [I-D.ietf-bess-bgp-multicast-controller]
              Zhang, Z., Raszuk, R., Pacella, D., and A. Gulko,
              "Controller Based BGP Multicast Signaling", draft-ietf-
              bess-bgp-multicast-controller-05 (work in progress),
              September 2020.

   [I-D.ietf-bess-evpn-igmp-mld-proxy]
              Sajassi, A., Thoria, S., Drake, J., and W. Lin, "IGMP and
              MLD Proxy for EVPN", draft-ietf-bess-evpn-igmp-mld-
              proxy-06 (work in progress), January 2021.

Author's Address

   Zhaohui Zhang
   Juniper Networks

   Email: zzhang@juniper.net

Zhang                    Expires August 26, 2021                [Page 4]