diff options
Diffstat (limited to 'doc/rfc/rfc8401.txt')
| -rw-r--r-- | doc/rfc/rfc8401.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc8401.txt b/doc/rfc/rfc8401.txt new file mode 100644 index 0000000..efacc21 --- /dev/null +++ b/doc/rfc/rfc8401.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Ginsberg, Ed. +Request for Comments: 8401 Cisco Systems +Category: Standards Track A. Przygienda +ISSN: 2070-1721 Juniper Networks + S. Aldrin + Google + J. Zhang + Juniper Networks, Inc. + June 2018 + + + Bit Index Explicit Replication (BIER) Support via IS-IS + +Abstract + + This document defines IS-IS extensions to support multicast + forwarding using the Bit Index Explicit Replication (BIER) + architecture. + +Status of This Memo + + This is an Internet Standards Track document. + + 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). Further information on + Internet Standards is available in 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 + https://www.rfc-editor.org/info/rfc8401. + +Copyright Notice + + Copyright (c) 2018 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. + + + + +Ginsberg, et al. Standards Track [Page 1] + +RFC 8401 BIER Support via IS-IS June 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 + 4. Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. BIER Domains and Subdomains . . . . . . . . . . . . . . . 5 + 4.2. Advertising BIER Information . . . . . . . . . . . . . . 5 + 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 5.1. Multi-Topology and Subdomain . . . . . . . . . . . . . . 5 + 5.2. BFR-id Advertisements . . . . . . . . . . . . . . . . . . 6 + 5.3. Logging Misconfiguration . . . . . . . . . . . . . . . . 6 + 5.4. Flooding Reduction . . . . . . . . . . . . . . . . . . . 6 + 6. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 7 + 6.1. BIER Info Sub-TLV . . . . . . . . . . . . . . . . . . . . 7 + 6.2. BIER MPLS Encapsulation Sub-sub-TLV . . . . . . . . . . . 8 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . 11 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + Bit Index Explicit Replication (BIER) [RFC8279] defines an + architecture where all intended multicast receivers are encoded as a + bitmask in the multicast packet header within different + encapsulations such as described in [RFC8296]. A router that + receives such a packet will forward the packet based on the bit + position in the packet header towards the receiver(s) following a + precomputed tree for each of the bits in the packet. Each receiver + is represented by a unique bit in the bitmask. + + This document presents necessary extensions to the currently deployed + IS-IS for IP [RFC1195] to support distribution of information + necessary for operation of BIER domains and subdomains. This + document defines a new TLV to be advertised by every router + participating in BIER signaling. + + This document defines support for MPLS encapsulation as specified in + [RFC8296]. Support for other encapsulation types and the use of + multiple encapsulation types are outside the scope of this document. + + + + + + + +Ginsberg, et al. Standards Track [Page 2] + +RFC 8401 BIER Support via IS-IS June 2018 + + +2. Terminology + + Some of the terminology specified in [RFC8279] is replicated here and + extended by necessary definitions: + + BIER: Bit Index Explicit Replication. The overall architecture of + forwarding multicast using a bit position. + + BIER-OL: BIER Overlay Signaling. The method for the BFIR to learn + about BFERs. + + BFR: Bit Forwarding Router. A router that participates in Bit Index + Multipoint Forwarding. A BFR is identified by a unique BFR-prefix + in a BIER domain. + + BFIR: Bit Forwarding Ingress Router. The ingress border router that + inserts the BitString into the packet. Each BFIR must have a + valid BFR-id assigned. + + BFER: Bit Forwarding Egress Router. A router that participates in + Bit Index Forwarding as a leaf. Each BFER must be a BFR. Each + BFER must have a valid BFR-id assigned. + + BFT: Bit Forwarding Tree used to reach all BFERs in a domain. + + BIER subdomain: A further distinction within a BIER domain + identified by its unique subdomain identifier. A BIER subdomain + can support multiple BitString Lengths. + + BFR-id: An optional, unique identifier for a BFR within a BIER + subdomain. + + Invalid BFR-id: Unassigned BFR-id. The special value 0 is reserved + for this purpose. + + BAR: BIER Algorithm. Used to calculate underlay next hops. + + IPA: IGP Algorithm. May be used to modify, enhance, or replace the + calculation of underlay paths as defined by the BAR value. + + SPF: Shortest Path First routing calculation based on the IGP link + metric. + + + + + + + + + +Ginsberg, et al. Standards Track [Page 3] + +RFC 8401 BIER Support via IS-IS June 2018 + + +2.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. IANA Considerations + + This document adds the following entry to the "Sub-TLVs for TLVs 135, + 235, 236, and 237" registry. + + Value: 32 + + Name: BIER Info + + This document also introduces a new registry for sub-sub-TLVs for the + BIER Info sub-TLV. The registration policy is Expert Review as + defined in [RFC8126]. The "Sub-sub-TLVs for BIER Info Sub-TLV" has + been created within the "IS-IS TLV Codepoints" registry. The defined + value is as follows: + + Type Name + ---- ---- + 1 BIER MPLS Encapsulation + + IANA has created the "BIER Algorithms" registry within the "Bit Index + Explicit Replication (BIER)" registry. The registration policies + [RFC8126] for this registry are: + + "Standards Action" for values 0-127 + + "Specification Required" for values 128-239 + + "Experimental Use" for values 240-254 + + The initial values in the "BIER Algorithms" registry are: + + 0: No BIER-specific algorithm is used + + 255: Reserved + + + + + + + + + +Ginsberg, et al. Standards Track [Page 4] + +RFC 8401 BIER Support via IS-IS June 2018 + + +4. Concepts + +4.1. BIER Domains and Subdomains + + An IS-IS-signaled BIER domain is aligned with the scope of + distribution of BFR-prefixes that identify the BFRs within IS-IS. In + such a case, IS-IS acts as the supporting BIER underlay. + + Within such a domain, the extensions defined in this document + advertise BIER information for one or more BIER subdomains. Each + subdomain is uniquely identified by a subdomain-id (SD). Each + subdomain is associated with a single IS-IS topology (MT) [RFC5120], + which may be any of the topologies supported by IS-IS. Local + configuration controls which <MT,SD> pairs are supported by a router. + The mapping of subdomains to topologies MUST be consistent within the + IS-IS flooding domain used to advertise BIER information. + + Each BIER subdomain has as its unique attributes the encapsulation + used and the type of tree it uses to forward BIER frames (currently + always SPF). Additionally, per supported BitString length in the + subdomain, each router will advertise the necessary label ranges to + support it. + +4.2. Advertising BIER Information + + BIER information advertisements are associated with a new sub-TLV in + the extended reachability TLVs. BIER information is always + associated with a host prefix, which MUST be a node address for the + advertising node. If this is not the case, the advertisement MUST be + ignored. Therefore, the following restrictions apply: + + o Prefix length MUST be 32 for an IPv4 prefix or 128 for an IPv6 + prefix. + + o When the Prefix Attributes Flags sub-TLV [RFC7794] is present, the + N flag MUST be set and the R flag MUST NOT be set. + + o BIER sub-TLVs MUST be included when a prefix reachability + advertisement is leaked between levels. + +5. Procedures + +5.1. Multi-Topology and Subdomain + + A given subdomain is supported within one and only one topology. All + routers in the flooding scope of the BIER sub-TLVs MUST advertise the + same subdomain within the same multi-topology. A router receiving an + <MT,SD> advertisement that does not match the locally configured pair + + + +Ginsberg, et al. Standards Track [Page 5] + +RFC 8401 BIER Support via IS-IS June 2018 + + + MUST report a misconfiguration of the received <MT,SD> pair. All + received BIER advertisements associated with the conflicting <MT,SD> + pair MUST be ignored. Note that in the presence of such a + misconfiguration, this will lead to partitioning of the subdomain. + + Example: + + The following combination of advertisements are valid: <0,0> <0,1>, + and <2,2>. + + The following combination of advertisements are invalid: <0,0> <0,1>, + and <2,0>. Advertisements associated with <0,0> and <2,0> must be + ignored. + +5.2. BFR-id Advertisements + + If a BFER/BFIR is configured with a BFR-id, then it advertises this + value in its BIER advertisements. If no BFR-id is configured, then + the value "Invalid BFR-id" is advertised. A valid BFR-id MUST be + unique within the flooding scope of the BIER advertisements. All + BFERs/BFIRs MUST detect advertisement of duplicate valid BFR-IDs for + a given <MT,SD>. When such duplication is detected, all of the + routers advertising duplicates MUST be treated as if they did not + advertise a valid BFR-id. This implies they cannot act as BFER or + BFIR in that <MT,SD>. + +5.3. Logging Misconfiguration + + Whenever an advertisement is received that violates any of the + constraints defined in this document, the receiving router MUST + support logging this occurrence. Logging SHOULD be dampened to avoid + excessive output. + +5.4. Flooding Reduction + + It is expected that changes in the BIER domain information that is + advertised by IS-IS occur infrequently. If this expectation is not + met for an extended period of time (more than a few seconds of + burstiness), changes will increase the number of Link State PDU (LSP) + updates and negatively impact performance in the network. + Implementations SHOULD protect against this possibility by, for + example, dampening updates if they occur over an extended period of + time. + + + + + + + + +Ginsberg, et al. Standards Track [Page 6] + +RFC 8401 BIER Support via IS-IS June 2018 + + +6. Packet Formats + + All IS-IS BIER information is carried within the TLVs 235, 237, + [RFC5120], 135 [RFC5305], or 236 [RFC5308]. + +6.1. BIER Info Sub-TLV + + This sub-TLV carries the information for the BIER subdomains that the + router participates in as a BFR. This sub-TLV MAY appear multiple + times in a given prefix-reachability TLV -- once for each subdomain + supported in the associated topology. + + The sub-TLV advertises a single <MT,SD> combination followed by + optional sub-sub-TLVs as described in the following sections. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BAR | IPA | subdomain-id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BFR-id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | sub-sub-TLVs (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: As indicated in the IANA section. + + Length: Variable + + BAR: BIER Algorithm. Specifies a BIER-specific algorithm used to + calculate underlay paths to reach BFERs. Values are allocated + from the "BIER Algorithms" registry. 1 octet. + + IPA: IGP Algorithm. Specifies an IGP Algorithm to either modify, + enhance, or replace the calculation of underlay paths to reach + BFERs as defined by the BAR value. Values are from the IGP + Algorithm registry. 1 octet. + + subdomain-id: Unique value identifying the BIER subdomain. 1 octet. + + BFR-id: A 2-octet field encoding the BFR-id, as documented in + [RFC8279]. If no BFR-id has been assigned, the value of this + field is set to "Invalid BFR-id", which is defined as illegal in + [RFC8279]. + + + + + +Ginsberg, et al. Standards Track [Page 7] + +RFC 8401 BIER Support via IS-IS June 2018 + + + The use of non-zero values in either the BAR field or the IPA field + is outside the scope of this document. If an implementation does not + support the use of non-zero values in these fields but receives a + BIER Info sub-TLV containing non-zero values in these fields, it + SHOULD treat the advertising router as incapable of supporting BIER + (one way of handling incapable routers is documented in Section 6.9 + of [RFC8279] and additional methods may be defined in the future). + +6.2. BIER MPLS Encapsulation Sub-sub-TLV + + This sub-sub-TLV carries the information for the BIER MPLS + encapsulation including the label range for a specific BitString + length for a certain <MT,SD>. It is advertised within the BIER Info + sub-TLV (Section 6.1). This sub-sub-TLV MAY appear multiple times + within a single BIER Info sub-TLV. + + If the same BitString length is repeated in multiple sub-sub-TLVs + inside the same BIER Info sub-TLV, the BIER Info sub-TLV MUST be + ignored. + + Label ranges within all BIER MPLS Encapsulation sub-sub-TLVs across + all BIER Info sub-TLVs advertised by the same BFR MUST NOT overlap. + If overlap is detected, the advertising router MUST be treated as if + it did not advertise any BIER sub-TLVs. + + Label values MUST NOT match any of the reserved values defined in + [RFC3032]. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max SI |BS Len | Label | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type: Value of 1 indicating MPLS encapsulation. + + Length: 4 + + Max SI: Maximum Set Identifier (Section 1 of [RFC8279]) used in the + encapsulation for this BIER subdomain for this BitString length, 1 + octet. Each SI maps to a single label in the label range. The + first label is for SI=0, the second label is for SI=1, etc. If + the label associated with the Maximum Set Identifier exceeds the + 20-bit range, the sub-sub-TLV MUST be ignored. + + + + + +Ginsberg, et al. Standards Track [Page 8] + +RFC 8401 BIER Support via IS-IS June 2018 + + + Local BitString Length (BS Len): Encoded BitString length as per + [RFC8296]. 4 bits. + + Label: First label of the range, 20 bits. The labels are as defined + in [RFC8296]. + +7. Security Considerations + + Security concerns for IS-IS are addressed in [RFC5304] and [RFC5310]. + + The Security Considerations section of [RFC8279] discusses the + possibility of performing a Denial-of-Service (DoS) attack by setting + too many bits in the BitString of a BIER-encapsulated packet. + However, this sort of DoS attack cannot be initiated by modifying the + IS-IS BIER advertisements specified in this document. A BFIR decides + which systems are to receive a BIER-encapsulated packet. In making + this decision, it is not influenced by the IS-IS control messages. + When creating the encapsulation, the BFIR sets one bit in the + encapsulation for each destination system. The information in the + IS-IS BIER advertisements is used to construct the forwarding tables + that map each bit in the encapsulation into a set of next hops for + the host that is identified by that bit, but it is not used by the + BFIR to decide which bits to set. Hence, an attack on the IS-IS + control plane cannot be used to cause this sort of DoS attack. + + While a BIER-encapsulated packet is traversing the network, a BFR + that receives a BIER-encapsulated packet with n bits set in its + BitString may have to replicate the packet and forward multiple + copies. However, a given bit will only be set in one copy of the + packet. This means that each transmitted replica of a received + packet has fewer bits set (i.e., is targeted to fewer destinations) + than the received packet. This is an essential property of the BIER- + forwarding process as defined in [RFC8279]. While a failure of this + process might cause a DoS attack (as discussed in the Security + Considerations of [RFC8279]), such a failure cannot be caused by an + attack on the IS-IS control plane. + + Further discussion of BIER-specific security considerations can be + found in [RFC8279]. + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 9] + +RFC 8401 BIER Support via IS-IS June 2018 + + +8. References + +8.1. Normative References + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and + dual environments", RFC 1195, DOI 10.17487/RFC1195, + December 1990, <https://www.rfc-editor.org/info/rfc1195>. + + [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>. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, + <https://www.rfc-editor.org/info/rfc3032>. + + [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi + Topology (MT) Routing in Intermediate System to + Intermediate Systems (IS-ISs)", RFC 5120, + DOI 10.17487/RFC5120, February 2008, + <https://www.rfc-editor.org/info/rfc5120>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <https://www.rfc-editor.org/info/rfc5304>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <https://www.rfc-editor.org/info/rfc5305>. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + <https://www.rfc-editor.org/info/rfc5308>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <https://www.rfc-editor.org/info/rfc5310>. + + [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and + U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 + and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, + March 2016, <https://www.rfc-editor.org/info/rfc7794>. + + + + + + +Ginsberg, et al. Standards Track [Page 10] + +RFC 8401 BIER Support via IS-IS June 2018 + + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., + Przygienda, T., and S. Aldrin, "Multicast Using Bit Index + Explicit Replication (BIER)", RFC 8279, + DOI 10.17487/RFC8279, November 2017, + <https://www.rfc-editor.org/info/rfc8279>. + + [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., + Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation + for Bit Index Explicit Replication (BIER) in MPLS and Non- + MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January + 2018, <https://www.rfc-editor.org/info/rfc8296>. + +8.2. Informative References + + [OPSFv2BIER] + Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., + Przygienda, T., Zhang, Z., and S. Aldrin, "OSPFv2 + Extensions for BIER", Work in Progress, draft-ietf-bier- + ospf-bier-extensions-18, June 2018. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + +Acknowledgements + + This RFC is aligned with "OSPFv2 Extensions for BIER" [OPSFv2BIER] + document as far as the protocol mechanisms overlap. + + Many thanks for comments from (in no particular order) Hannes + Gredler, IJsbrand Wijnands, Peter Psenak, and Chris Bowers. + + Special thanks to Eric Rosen. + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 11] + +RFC 8401 BIER Support via IS-IS June 2018 + + +Authors' Addresses + + Les Ginsberg (editor) + Cisco Systems + 510 McCarthy Blvd. + Milpitas, CA 95035 + United States of America + + Email: ginsberg@cisco.com + + + Tony Przygienda + Juniper Networks + + Email: prz@juniper.net + + + Sam Aldrin + Google + 1600 Amphitheatre Parkway + Mountain View, CA + United States of America + + Email: aldrin.ietf@gmail.com + + + Jeffrey (Zhaohui) Zhang + Juniper Networks, Inc. + 10 Technology Park Drive + Westford, MA 01886 + United States of America + + Email: zzhang@juniper.net + + + + + + + + + + + + + + + + + + +Ginsberg, et al. Standards Track [Page 12] + |