OSPF Senthil. Dhanaraj, Ed. Internet-Draft J. Xie Intended status: Standards Track Huawei Expires: September 17, 2018 March 16, 2018 OSPFv2 Extensions for BIER-TE draft-senthil-bier-te-ospfv2-extensions-00.txt Abstract BIER-TE: Traffic Engineering for Bit Index Explicit Replication (BIER) is a variant of BIER [RFC8279] to support explicit path engineering. BIER-TE defines a (loose) source routed multicast forwarding method where every hop and destination in the TE path is identified via bits in the bitstring of the BIER header in the data packets. BIER-TE forwarding architecture is described in [I-D.draft- ietf-bier-te-arch]. Control framework for Traffic Engineering with BIER-TE forwarding plane is explained in [I-D.draft-eckert-teas-bier- te-framework]. This document describes the OSPF [RFC2328] protocol extension required for BIER-TE control framework with MPLS encapsulation [RFC8296]. Support for other encapsulation types is outside the scope of this document. The use of multiple encapsulation types is outside the scope of this document. 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 September 17, 2018. Dhanaraj & Xie Expires September 17, 2018 [Page 1] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Flooding of the BIER-TE information in OSPF . . . . . . . . . 3 2.1. BIER-TE TLV . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. BIER-TE MPLS Encapsulation Sub-TLV . . . . . . . . . . . 5 2.3. BIER-TE-LocalDecap Sub-TLV . . . . . . . . . . . . . . . 6 2.4. BIER-TE-FloodAdj Sub-TLV . . . . . . . . . . . . . . . . 7 2.5. BIER-TE-P2PAdj Sub-TLV . . . . . . . . . . . . . . . . . 8 2.6. BIER-TE-LANAdj Sub-TLV . . . . . . . . . . . . . . . . . 9 2.7. BIER-TE-NodeAdj Sub-TLV . . . . . . . . . . . . . . . . . 11 2.8. Flooding scope of BIER Information . . . . . . . . . . . 12 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.1. OSPF Router Information (RI) TLVs Registry . . . . . . . 12 4.2. OSPFv2 Extended Link TLV Sub-TLVs Registry . . . . . . . 12 4.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry . . . . . . 13 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 6. Normative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction BIER-TE: Traffic Engineering for Bit Index Explicit Replication is an architecture that provides optimal multicast forwarding with explicit path engineering through a "BIER-TE domain". BIER-TE defines a (loose) source routed multicast forwarding method where every intermediate hop and the destination in the TE path is identified via bits in a bitstring of the BIER header in the data packets. BIER-TE control framework supports different deployment options as follows, Dhanaraj & Xie Expires September 17, 2018 [Page 2] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 Option-1: Pure centralized controller based network, where in the controller (SDN-Controller, PCE-CC .. ) would directly communicate with all the BFRs (including BFIRs and BFERs) via southbound APIs like (Yang, RestConf, PCEP ..) to learn the BIER-TE capabilities, parameters, assign unique bit-positions to adjacencies and program BIFTs to each BFRs directly. In this option, BIER-TE does not depend on IGP routing underlay to advertise BIER-TE parameters. Option-2: Controller based network, where in the controller (PCE ..) learns the BIER-TE capabilities, parameters from the network. Configuration of BIER-TE domain and assignment of bit-position to adjacencies can be done manually at each BFR. Each BFR advertises the self BIER-TE parameters via IGP to other BFRs. BGP Speaker (BGP-LS) can share the BIER-TE parameters along with the other LS information to the Controller. Controller can autonomously calculate the BIER-TE path and communicate the bit-string and other parameters required to program the BIFT at the BFIR by southbound APIs (like PCEP ..). Option-3: Controller less network, where in configuration of BIER- TE domain and assignment of bit-position to adjacencies is done manually at each BFR by the operator. Each BFR advertises the self BIER-TE parameters via IGP to other BFRs including BFIRs. Each BFIR can autonomously calculate the BIER-TE path. As explained above, BIER-TE framework which uses option-2 or option-3 depends upon the IGP protocols (OSPF, ISIS ..) to advertise the BIER- TE capabilities and associated parameters (bit-positions, labels) to the other BFRs in the network. This document describes the OSPF [RFC2328] protocol extension required for BIER-TE control framework with MPLS encapsulation [RFC8296]. Support for other encapsulation types is outside the scope of this document. The use of multiple encapsulation types is outside the scope of this document. 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]. 2. Flooding of the BIER-TE information in OSPF Like BIER, BIER-TE supports multiple sub-domains, SI and BFR-id as described in section 7 of [I-D.draft-ietf-bier-te-arch]. However unlike BIER, the BIER-TE sub-domain is not necessarily be associated with a IGP prefix of the BFR. Dhanaraj & Xie Expires September 17, 2018 [Page 3] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 Given that BIER-TE sub-domain information is not necessarily be associated with a IGP prefix of BFR, the OSPF Router Information Opaque LSA [RFC7770] has been chosen for the advertisement of BIER-TE sub-domain information and, MPLS labels associated with the BIER-TE sub-domain. BIER-TE assigns a bit-position for each adjacency (a.k.a each hop and destination). OSPFv2 Extended Link Opaque LSA [RFC7684] is chosen to advertise the bit-position assigned for adjacency type forward- connected (described in section 3.2.1 of [I-D.draft-ietf-bier-te- arch]) and OSPFv2 Extended Prefix Opaque LSA is chosen to advertise the bit-position assigned for adjacency type forward-routed (described in section 3.2.2 of [I-D.draft-ietf-bier-te-arch]) . 2.1. BIER-TE TLV The BIER-TE TLV is a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]) and is defined for distributing BIER-TE sub-domain information. The BIER-TE TLV is OPTIONAL. If BIER-TE TLV is not advertised by the node, such node is considered as not being BIER-TE capable. BIER-TE TLVs MAY appear multiple times in a RI LSA, one per each BIER-TE sub-domain. The BIER-TE has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | BFR-id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) | +- -+ | | Type: TBD. Length: Variable, dependent on Sub-TLVs. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. A BFR MAY use the same sub-domain for BIER and BIER-TE. Dhanaraj & Xie Expires September 17, 2018 [Page 4] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. BFR-id: A 2 octet field encoding the BFR-id, as documented in section 7.3 of [I-D.draft-ietf-bier-te-arch]. If the BFR is not locally configured with a valid BFR-id to be used for BIER-TE sub- domain, the value of this field is set to 0, which is defined as illegal in [RFC8279]. At each BFR, BIER-TE sub-domain MUST be associated with one and only one OSPF topology that is identified by the MT-ID. If the association between BIER-TE sub-domain and OSPF topology advertised in the BIER-TE TLV by other BFRs is in conflict with the association locally configured on the receiving router, the BIER-TE TLV MUST be ignored. If the MT-ID value is outside of the values specified in [RFC4915], the BIER Sub-TLV MUST be ignored. If a BFR advertises the same Sub-domain-ID in multiple BIER-TE TLVs, the BRF MUST be treated as if it did not advertise a BIER-TE TLV for such sub-domain. All BFRs MUST detect advertisement of duplicate valid BFR-IDs for a given MT-ID and Sub-domain-ID. When such duplication is detected by the BFR, it MUST behave as described in section 5 of [RFC8279]. 2.2. BIER-TE MPLS Encapsulation Sub-TLV The BIER-TE MPLS Encapsulation Sub-TLV is a Sub-TLV of the BIER-TE TLV. The BIER-TE MPLS Encapsulation Sub-TLV is used in order to advertise MPLS specific information used for BIER-TE. It MAY appear multiple times in the BIER-TE TLV. The BIER-TE MPLS Encapsulation Sub-TLV has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max SI | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |BS Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Dhanaraj & Xie Expires September 17, 2018 [Page 5] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 Length: 8 octets. Max SI : A 1 octet field encoding the Maximum Set Identifier (section 1 of [RFC8296]), used in the encapsulation for this BIER- TE sub-domain for this bitstring length. Label: A 3 octet field, where the 20 rightmost bits represent the first label in the label range. The 4 leftmost bits MUST be ignored. Bit String Length: A 4 bits field encoding the supported BitString length associated with this sub-domain. The values allowed in this field are specified in section 2 of [RFC8296]. The "label range" is the set of labels beginning with the Label and ending with (Label + (Max SI)). A unique label range is allocated for each BitString length and Sub-domain-ID. These labels are used for BIER-TE forwarding as described in [I-D.draft-ietf-bier-te-arch]. The size of the label range is determined by the number of Set Identifiers (SI) that are used in the network. 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 BS length is set to a value that does not match any of the allowed values specified in [RFC8296], the BIER-TE MPLS Encapsulation Sub-TLV MUST be ignored. If same BS length is repeated in multiple BIER-TE MPLS Encapsulation Sub-TLV inside the same BIER-TE TLV, the BIER-TE MPLS Encapsulation TLV MUST be ignored. Label ranges within all BIER-TE MPLS Encapsulation Sub-TLVs advertised by the same BFR MUST NOT overlap. If the overlap is detected, the advertising router MUST be treated as if it did not advertise any BIER-TE MPLS Encapsulation Sub-TLV. 2.3. BIER-TE-LocalDecap Sub-TLV The BIER-TE-LocalDecap Sub-TLV is an optional Sub-TLV of the BIER-TE TLV. The BIER-TE LocalDecap Sub-TLV is used in order to advertise the bit-position of the local_decap adjacency. The BIER-TE LocalDecap Sub-TLV has the following format: Dhanaraj & Xie Expires September 17, 2018 [Page 6] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | Adjacency bit-position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: 8 octets. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. Adjacency bit-position: A 2 octet field encoding the adjacency bit-position for the local-decap adjacency. Flags: TBD. Reserved: SHOULD be set to 0 while sending and MUST be ignored on reception. If a BFR advertises multiple BIER-TE-LocalDecap Sub-TLVs under the same BIER-TE TLV, then the BRF MUST be treated as if it did not advertise a BIER-TE-LocalDecap Sub-TLV. It MAY be possible that the same bit-position is assigned for different BFRs when the BFR is a leaf BFER. Hence the advertisement of same bit-position by different BFRs SHOULD be allowed. 2.4. BIER-TE-FloodAdj Sub-TLV The BIER-TE-FloodAdj Sub-TLV is an optional Sub-TLV of the BIER-TE TLV. The BIER-TE-FloodAdj Sub-TLV is used in order to advertise the bit-position for the flood adjacency type which would flood the multicast packet in all the local adjacencies. The BIER-TE-FloodAdj Sub-TLV has the following format: Dhanaraj & Xie Expires September 17, 2018 [Page 7] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | Adjacency bit-position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: 8 octets. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. Adjacency bit-position: A 2 octet field encoding the adjacency bit-position for the flood adjacency type. Flags: TBD. Reserved: SHOULD be set to 0 while sending and MUST be ignored on reception. If a BFR advertises multiple BIER-TE-FloodAdj Sub-TLVs under the same BIER-TE TLV, then the BRF MUST be treated as if it did not advertise a BIER-TE-FloodAdj Sub-TLV. 2.5. BIER-TE-P2PAdj Sub-TLV The BIER-TE-P2PAdj Sub-TLV is an optional Sub-TLV of the Extended Link TLV in Extended Link Opaque LSA (defined in [RFC7684]) and is defined for distributing the bit-position assigned for the forward- connected p2p adjacency. The BIER-TE-P2PAdj Sub-TLV has the following format: Dhanaraj & Xie Expires September 17, 2018 [Page 8] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | Adjacency bit-position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: 8 octets. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. Adjacency bit-position: A 2 octet field encoding the adjacency bit-position for the adjacency. Flags: TBD. Weight: TBD. Reserved: SHOULD be set to 0 while sending and MUST be ignored on reception. If a BFR advertises the multiple BIER-TE-P2PAdj Sub-TLVs under the same Extended Link TLV, then the BRF MUST be treated as if it did not advertise a BIER-TE-P2PAdj Sub-TLV for the Adjacency. It MAY be possible that the same bit-position is assigned for different P2P adjacencies with in same or different BFR. Hence the advertisement of same Adjacency bit-position across different Extended Link Opaque LSA by the same BFR or different BFR SHOULD be allowed. 2.6. BIER-TE-LANAdj Sub-TLV The BIER-TE-LANAdj Sub-TLV is an optional Sub-TLV of the Extended Link TLV in Extended Link Opaque LSA (defined in [RFC7684]) and is defined for distributing the bit-position assigned for the forward- connected LAN adjacency. The BIER-TE-LANAdj Sub-TLV has the following format: Dhanaraj & Xie Expires September 17, 2018 [Page 9] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | Adjacency bit-position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Weight | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: 12 octets. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. Adjacency bit-position: A 2 octet field encoding the adjacency bit-position for the adjacency. Flags: TBD. Weight: TBD. Reserved: SHOULD be set to 0 while sending and MUST be ignored on reception. Neighbor ID: The Router ID of the neighbor for which the LANAdj- bit-position is advertised. If a BFR advertises the multiple BIER-TE-LANAdj Sub-TLVs for the same Neighbor ID under the same Extended Link TLV, then the BRF MUST be treated as if it did not advertise a BIER-TE-P2PAdj Sub-TLV for the Neighbor. It MAY be possible that the same bit-position is assigned for different LAN adjacencies with in same or different BFR. Hence the advertisement of same Adjacency bit-position across different Extended Link Opaque LSA by the same BFR or different BFR SHOULD be allowed. Dhanaraj & Xie Expires September 17, 2018 [Page 10] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 2.7. BIER-TE-NodeAdj Sub-TLV The BIER-TE-NodeAdj Sub-TLV is an optional Sub-TLV of the Extended Prefix TLV in Extended Prefix Opaque LSA (defined in [RFC7684]) and is defined for distributing the bit-position assigned for the forward-routed adjacency. The BIER-TE-NodeAdj Sub-TLV has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-domain-ID | MT-ID | Adjacency bit-position | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: 8 octets. Sub-domain-ID: Unique value identifying the BIER-TE sub-domain within the BIER-TE domain. MT-ID: Multi-Topology ID (as defined in [RFC4915]) that identifies the topology that is associated with the BIER-TE sub-domain. Adjacency bit-position: A 2 octet field encoding the adjacency bit-position for the adjacency. Flags: TBD. Reserved: SHOULD be set to 0 while sending and MUST be ignored on reception. Neighbor ID: The Router ID of the neighbor for which the LANAdj- bit-position is advertised. If a BFR advertises the multiple BIER-TE-NodeAdj Sub-TLVs under the same Extended Prefix TLV, then the BRF MUST be treated as if it did not advertise a BIER-TE-NodeAdj Sub-TLV. If the same bit-position is advertised for different prefix within same or different BFR, then the BFR(s) advertising the duplicate bit- position MUST be treated as if they did not advertise the BIER-TE- NodeAdj Sub-TLV for the prefix. Dhanaraj & Xie Expires September 17, 2018 [Page 11] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 2.8. Flooding scope of BIER Information TBD. 3. Security Considerations This document introduces new TLVs, Sub-TLVs for existing OSPF Router Information Opaque LSA and new Sub-TLVs for existing OSPF Extended Prefix TLV and OSPFV2 Extended Link TLV. It does not introduce any new security risks to OSPF. Existing security extensions as described in [RFC2328], [RFC7684] and [RFC7770] apply. It is assumed that both BIER and OSPF layer is under a single administrative domain. There can be deployments where potential attackers have access to one or more networks in the OSPF routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC7474] SHOULD be used. Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPF router or routing process. Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate- limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane. 4. IANA Considerations The document requests new allocations from the OSPF registries as follows 4.1. OSPF Router Information (RI) TLVs Registry BIER-TE TLV: 16 BIER-TE MPLS Encapsulation Sub-TLV: 17 BIER-TE-LocalDecap Sub-TLV : 18 BIER-TE-FloodAdj Sub-TLV : 19 4.2. OSPFv2 Extended Link TLV Sub-TLVs Registry BIER-TE-P2PAdj Sub-TLV : 10 BIER-TE-LanAdj Sub-TLV : 11 Dhanaraj & Xie Expires September 17, 2018 [Page 12] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 4.3. OSPFv2 Extended Prefix TLV Sub-TLVs Registry BIER-TE-NodeAdj Sub-TLV : 12 5. Acknowledgments TBD 6. Normative References [I-D.eckert-teas-bier-te-framework] Eckert, T., "Framework for Traffic Engineering with BIER- TE forwarding (Bit Index Explicit Replication with Traffic Engineering)", draft-eckert-teas-bier-te-framework-00 (work in progress), March 2018. [I-D.ietf-bier-te-arch] Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic Engineering for Bit Index Explicit Replication (BIER-TE)", draft-ietf-bier-te-arch-00 (work in progress), January 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . Dhanaraj & Xie Expires September 17, 2018 [Page 13] Internet-Draft OSPFv2 Extensions for BIER-TE March 2018 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [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, . [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, . Authors' Addresses Senthil Dhanaraj (editor) Huawei Email: senthil.dhanaraj@huawei.com Xie Jingrong Huawei Email: xiejingrong@huawei.com Dhanaraj & Xie Expires September 17, 2018 [Page 14]