doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc8059.txt b/doc/rfc/rfc8059.txt
new file mode 100644
index 0000000..db22c79
--- /dev/null
+++ b/doc/rfc/rfc8059.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         J. Arango
+Request for Comments: 8059                                     S. Venaas
+Category: Experimental                                     Cisco Systems
+ISSN: 2070-1721                                              I. Kouvelas
+                                                    Arista Networks Inc.
+                                                            D. Farinacci
+                                                             lispers.net
+                                                            January 2017
+
+
+                          PIM Join Attributes
+         for Locator/ID Separation Protocol (LISP) Environments
+
+Abstract
+
+   This document defines two PIM Join/Prune attributes that support the
+   construction of multicast distribution trees where the root and
+   receivers are located in different Locator/ID Separation Protocol
+   (LISP) sites.  These attributes allow the receiver site to select
+   between unicast and multicast underlying transport and to convey the
+   RLOC (Routing Locator) address of the receiver ETR (Egress Tunnel
+   Router) to the control plane of the root ITR (Ingress Tunnel Router).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8059.
+
+
+
+
+
+
+
+
+
+
+
+Arango, et al.                Experimental                      [Page 1]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+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
+   (http://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
+   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
+   3.  PIM Join/Prune Attributes . . . . . . . . . . . . . . . . . .   3
+   4.  The Transport Attribute . . . . . . . . . . . . . . . . . . .   4
+     4.1.  Transport Attribute Format  . . . . . . . . . . . . . . .   4
+     4.2.  Using the Transport Attribute . . . . . . . . . . . . . .   5
+   5.  Receiver ETR RLOC Attribute . . . . . . . . . . . . . . . . .   5
+     5.1.  Receiver RLOC Attribute Format  . . . . . . . . . . . . .   6
+     5.2.  Using the Receiver RLOC Attribute . . . . . . . . . . . .   6
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9
+
+1.  Introduction
+
+   The construction of multicast distribution trees where the root and
+   receivers are located in different LISP sites [RFC6830] is defined in
+   [RFC6831].  Creation of (root-EID,G) state in the root site requires
+   that unicast LISP-encapsulated Join/Prune messages be sent from an
+   ETR on the receiver site to an ITR on the root site.  The term "EID"
+   is short for "Endpoint ID".
+
+   [RFC6831] specifies that (root-EID,G) data packets are to be LISP-
+   encapsulated into (root-RLOC,G) multicast packets.  However, a wide
+   deployment of multicast connectivity between LISP sites is unlikely
+   to happen any time soon.  In fact, some implementations are initially
+   focusing on unicast transport with head-end replication between root
+   and receiver sites.
+
+
+
+Arango, et al.                Experimental                      [Page 2]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+   The unicast LISP-encapsulated Join/Prune message specifies the
+   (root-EID,G) state that needs to be established in the root site, but
+   conveys nothing about the receiver's capability or desire to use
+   multicast as the underlying transport.  This document specifies a
+   Join/Prune attribute that allows the receiver ETR to select the
+   desired transport.
+
+   The term "transport" in this document is intentionally somewhat
+   vague.  Currently, it is used just to indicate whether multicast or
+   head-end replication is used; this means that the outer destination
+   address is either a unicast or multicast address.  Future documents
+   may specify how other types of delivery, encapsulation, or underlay
+   are used.
+
+   Knowledge of the receiver ETR's RLOC address is essential to the
+   control plane of the root ITR.  The RLOC address determines the
+   downstream destination for unicast head-end replication and
+   identifies the receiver ETR that needs to be notified should the root
+   ITR of the distribution tree move to another site.  The root ITR can
+   change when the source EID is roaming to another LISP site.
+
+   Service providers may implement unicast reverse path forwarding
+   (uRPF) policies requiring that the outer source address of the LISP-
+   encapsulated Join/Prune message be the address of the receiver ETR's
+   core-facing interface used to physically transmit the message.
+   However, due to policy and load-balancing considerations, the outer
+   source address may not be the RLOC on which the receiver site wishes
+   to receive a particular flow.  This document specifies a Join/Prune
+   attribute that conveys the appropriate receiver ETR's RLOC address to
+   the control plane of the root ITR.
+
+   This document uses terminology defined in [RFC6830], such as EID,
+   RLOC, ITR, and ETR.
+
+2.  Requirements Notation
+
+   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].
+
+3.  PIM Join/Prune Attributes
+
+   PIM Join/Prune attributes are defined in [RFC5384] by introducing a
+   new Encoded-Source type that, in addition to the Join/Prune source,
+   can carry multiple Type-Length-Value (TLV) attributes.  These
+   attributes apply to the individual Join/Prune sources on which they
+   are stored.
+
+
+
+
+Arango, et al.                Experimental                      [Page 3]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+   The attributes defined in this document conform to the format of the
+   encoding type defined in [RFC5384].  The attributes would typically
+   be the same for all the sources in the Join/Prune message.  Hence, we
+   RECOMMEND using the hierarchical Join/Prune attribute scheme defined
+   in [RFC7887].  This hierarchical system allows attributes to be
+   conveyed in the Upstream Neighbor Address field, thus enabling the
+   efficient application of a single attribute instance to all the
+   sources in the Join/Prune message.
+
+   LISP Tunnel Routers (xTRs) do not exchange PIM Hello Messages, and
+   hence no Hello option is defined to negotiate support for these
+   attributes.  Systems that support unicast head-end replication are
+   assumed to support these attributes.
+
+4.  The Transport Attribute
+
+   It is essential that a mechanism be provided by which the desired
+   transport can be conveyed by receiver sites.  Root sites with
+   multicast connectivity will want to leverage multicast replication.
+   However, not all receiver sites can be expected to have multicast
+   connectivity.  It is thus desirable that root sites be prepared to
+   support (root-EID,G) state with a mixture of multicast and unicast
+   output state.  This document specifies a Join/Prune attribute that
+   allows the receiver to select the desired underlying transport.
+
+4.1.  Transport Attribute Format
+
+       0                   1                   2
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|E|  Type = 5 | Length = 1    |  Transport    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   F bit:   The Transitive bit.  Specifies whether the attribute is
+      transitive or non-transitive.  MUST be set to zero.  This
+      attribute is ALWAYS non-transitive.
+
+   E bit:   End-of-Attributes bit.  Specifies whether this attribute is
+      the last.  Set to zero if there are more attributes.  Set to 1 if
+      this is the last attribute.
+
+   Type:   The Transport Attribute type is 5.
+
+   Length:   The length of the Transport Attribute value.  MUST be set
+      to 1.
+
+
+
+
+
+
+Arango, et al.                Experimental                      [Page 4]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+   Transport:   The type of transport being requested.  Set to zero for
+      multicast.  Set to 1 for unicast.  The values from 2 to 255 may be
+      assigned in the future.
+
+4.2.  Using the Transport Attribute
+
+   Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used
+   when the same Transport Attribute is to be applied to all the sources
+   within the Join/Prune message or all the sources within a group set.
+   The root ITR MUST accept Transport Attributes in the Upstream
+   Neighbor Encoded-Unicast address, Encoded-Group addresses, and
+   Encoded-Source addresses.
+
+   There MUST NOT be more than one Transport Attribute within the same
+   encoded address.  If an encoded address has more than one instance of
+   the attribute, the root ITR MUST discard all affected Join/Prune
+   sources.  The root ITR MUST also discard all affected Join/Prune
+   sources if the Transport Attribute value is unknown.
+
+5.  Receiver ETR RLOC Attribute
+
+   When a receiver ETR requests unicast head-end replication for a given
+   (root-EID,G) entry, the PIM control plane of the root ITR must
+   maintain an outgoing interface list ("oif-list") entry for the
+   receiver ETR and its corresponding RLOC address.  This allows the
+   root ITR to perform unicast LISP-encapsulation of multicast data
+   packets to each and every receiver ETR that has requested unicast
+   head-end replication.
+
+   The PIM control plane of the root ITR could potentially determine the
+   RLOC address of the receiver ETR from the outer source address field
+   of the LISP-encapsulated Join/Prune message.  However, receiver ETRs
+   are subject to uRPF checks by the network providers on each core-
+   facing interface.  The outer source address must therefore be the
+   RLOC of the core-facing interface used to physically transmit the
+   LISP-encapsulated Join/Prune message.  Due to policy and load-
+   balancing considerations, that may not be the RLOC on which the
+   receiver site wishes to receive a particular flow.  This document
+   specifies a Join/Prune attribute that conveys the appropriate
+   receiver RLOC address to the PIM control plane of the root ITR.
+
+   To support root-EID mobility, receiver ETRs must also be tracked by
+   the LISP control plane of the root ITR, regardless of the underlying
+   transport.  When the root-EID moves to a new root ITR in a different
+   LISP site, the receiver ETRs do not know the root-EID has moved and
+   therefore do not know the RLOC of the new root ITR.  This is true for
+   both unicast and multicast transport modes.  The new root ITR does
+   not have any receiver ETR state.  Therefore, it is the responsibility
+
+
+
+Arango, et al.                Experimental                      [Page 5]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+   of the old root ITR to inform the receiver ETRs that the root-EID has
+   moved.  When the old root ITR detects that the root-EID has moved, it
+   sends a LISP Solicit-Map-Request (SMR) message to each receiver ETR.
+   The receiver ETRs do a mapping database lookup to retrieve the RLOC
+   of the new root ITR.  The old root ITR detects that the root-EID has
+   moved when it receives a Map-Notify from the Map-Server.  The
+   transmission of the Map-Notify is triggered when the new root ITR
+   registers the root-EID [EID-MOBILITY].  When a receiver ETR
+   determines that the root ITR has changed, it will send a LISP-
+   encapsulated PIM prune message to the old root xTR and a LISP-
+   encapsulated PIM join message to the new root xTR.
+
+5.1.  Receiver RLOC Attribute Format
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|E|  Type = 6 |    Length     |  Addr Family  |  Receiver RLOC
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
+
+   F bit:   The Transitive bit.  Specifies whether this attribute is
+      transitive or non-transitive.  MUST be set to zero.  This
+      attribute is ALWAYS non-transitive.
+
+   E bit:   End-of-Attributes bit.  Specifies whether this attribute is
+      the last.  Set to zero if there are more attributes.  Set to 1 if
+      this is the last attribute.
+
+   Type:   The Receiver RLOC Attribute type is 6.
+
+   Length:   The length in octets of the attribute value.  MUST be set
+      to the length in octets of the receiver RLOC address plus 1 octet
+      to account for the Address Family field.
+
+   Addr Family:   The PIM Address Family of the receiver RLOC as defined
+      in [RFC7761].
+
+   Receiver RLOC:   The RLOC address on which the receiver ETR wishes to
+      receiver the unicast-encapsulated flow.
+
+5.2.  Using the Receiver RLOC Attribute
+
+   Hierarchical Join/Prune attribute instances [RFC7887] SHOULD be used
+   when the same Receiver RLOC Attribute is to be applied to all the
+   sources within the message or all the sources within a group set.
+   The root ITR MUST accept Transport Attributes in the Upstream
+   Neighbor Encoded-Unicast address, Encoded-Group addresses, and
+   Encoded-Source addresses.
+
+
+
+Arango, et al.                Experimental                      [Page 6]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+   There MUST NOT be more than one Receiver RLOC Attribute within the
+   same encoded address.  If an encoded address has more than one
+   instance of the attribute, the root ITR MUST discard all affected
+   Join/Prune sources.  The root ITR MUST also discard all affected
+   Join/Prune sources if the address family is unknown or the address
+   length is incorrect for the specified address family.
+
+6.  Security Considerations
+
+   Security of Join/Prune attributes is only guaranteed by the security
+   of the PIM packet.  The attributes specified herein do not enhance or
+   diminish the privacy or authenticity of a Join/Prune message.  A site
+   that legitimately or maliciously sends and delivers a Join/Prune
+   message to another site will equally be able to append these and any
+   other attributes it wishes.  See [RFC5384] for general security
+   considerations for Join/Prune attributes.
+
+7.  IANA Considerations
+
+   Two new PIM Join/Prune attribute types have been assigned: value 5
+   for the Transport Attribute and value 6 for the Receiver RLOC
+   Attribute.
+
+   The "PIM Join/Prune Transport Types" registry has been created for
+   the Join/Prune Transport attribute.  The registration policy is IETF
+   Review [RFC5226], and the values are in the range 0-255.  This
+   document assigns value 0 for multicast and value 1 for unicast.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arango, et al.                Experimental                      [Page 7]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+8.  References
+
+8.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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC5384]  Boers, A., Wijnands, I., and E. Rosen, "The Protocol
+              Independent Multicast (PIM) Join Attribute Format",
+              RFC 5384, DOI 10.17487/RFC5384, November 2008,
+              <http://www.rfc-editor.org/info/rfc5384>.
+
+   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+              Locator/ID Separation Protocol (LISP)", RFC 6830,
+              DOI 10.17487/RFC6830, January 2013,
+              <http://www.rfc-editor.org/info/rfc6830>.
+
+   [RFC6831]  Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
+              Locator/ID Separation Protocol (LISP) for Multicast
+              Environments", RFC 6831, DOI 10.17487/RFC6831, January
+              2013, <http://www.rfc-editor.org/info/rfc6831>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7761>.
+
+   [RFC7887]  Venaas, S., Arango, J., and I. Kouvelas, "Hierarchical
+              Join/Prune Attributes", RFC 7887, DOI 10.17487/RFC7887,
+              June 2016, <http://www.rfc-editor.org/info/rfc7887>.
+
+8.2.  Informative References
+
+   [EID-MOBILITY]
+              Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
+              F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
+              Unified Control Plane", Work in Progress, draft-portoles-
+              lisp-eid-mobility-01, October 2016.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              DOI 10.17487/RFC5226, May 2008,
+              <http://www.rfc-editor.org/info/rfc5226>.
+
+
+
+
+
+Arango, et al.                Experimental                      [Page 8]
+
+RFC 8059        PIM Join Attributes for LISP Environments   January 2017
+
+
+Authors' Addresses
+
+   Jesus Arango
+   Cisco Systems
+   170 Tasman Drive
+   San Jose, CA  95134
+   United States of America
+
+   Email: jearango@cisco.com
+
+
+   Stig Venaas
+   Cisco Systems
+   170 Tasman Drive
+   San Jose, CA  95134
+   United States of America
+
+   Email: stig@cisco.com
+
+
+   Isidor Kouvelas
+   Arista Networks Inc.
+   5453 Great America Parkway
+   Santa Clara, CA  95054
+   United States of America
+
+   Email: kouvelas@arista.com
+
+
+   Dino Farinacci
+   lispers.net
+   San Jose, CA
+   United States of America
+
+   Email: farinacci@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arango, et al.                Experimental                      [Page 9]
+