Network Working Group J. Xie Internet-Draft Huawei Technologies Intended status: Standards Track M. Chen Expires: March 9, 2019 R. Li Huawei September 5, 2018 Multipoint LDP Extension for P2MP-based BIER draft-xie-mpls-ldp-bier-extension-01 Abstract Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding without requiring intermediate routers to maintain any per-flow state by using a multicast-specific BIER header. An extension to the Label Distribution Protocol (LDP) defined in [RFC5036] for the setup of point-to-multipoint (P2MP) is described in [RFC6388] is called mLDP, and is used for multicast- specific tree building. This document describes mLDP extensions to setup a P2MP with BIER information, which is called P2MP based BIER in [I-D.xie-bier-mvpn-mpls-p2mp]. Requirements Language 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]. 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 March 9, 2019. Xie, et al. Expires March 9, 2019 [Page 1] Internet-Draft LDP Extension for BIER September 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MLDP P2MP BIER Signalling . . . . . . . . . . . . . . . . . . 4 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Signaling the P2MP BIER . . . . . . . . . . . . . . . . . 5 3.4. The P2MP BIER LSP Identifier . . . . . . . . . . . . . . 5 3.5. BIER TLV . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Make Before Break (MBB) . . . . . . . . . . . . . . . . . 7 4. Capability and Error handling . . . . . . . . . . . . . . . . 7 4.1. BIER Capability . . . . . . . . . . . . . . . . . . . . . 7 4.2. BIER Status . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Check Capability and Use Status for Error Handling . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding without requiring intermediate routers to maintain any per-flow state by using a multicast-specific BIER header. An extension to the Label Distribution Protocol (LDP) defined in [RFC5036] for the setup of point-to-multipoint (P2MP) is described in [RFC6388] is called mLDP, and is used for multicast- specific tree building. This document describes mLDP extensions to Xie, et al. Expires March 9, 2019 [Page 2] Internet-Draft LDP Extension for BIER September 2018 setup a P2MP with BIER information, which is called a P2MP based BIER in [I-D.xie-bier-mvpn-mpls-p2mp] . Related documents that may be of interest include [RFC5561], and [RFC3988]. 2. Terminology Readers of this document are assumed to be familiar with the terminology and concepts of the documents listed as Normative References. For convenience, some of the more frequently used terms and new terms list below. o mLDP: Multipoint extensions for LDP. o P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs. o Ingress LSR: An Ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. MP2MP LSPs can have multiple Ingress LSRs, P2MP LSPs have just one, and that node is often referred to as the "root node". o Egress LSR: An Egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. P2P and MP2P LSPs have only a single egress node, but P2MP and MP2MP LSPs can have multiple egress nodes. o Transit LSR: An LSR that has reachability to the root of the MP LSP via a directly connected upstream LSR and one or more directly connected downstream LSRs. o Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs. o Leaf node: A leaf node can be either an Egress or Bud LSR when referred to in the context of a P2MP LSP. o FEC: Forwarding Equivalence Class o P2MP FEC: defined in RFC6388. o F-BM: Forwarding Bit Mask o BSL: Bit String Length, that is 64, 128, 256, etc (per [RFC8279]). Xie, et al. Expires March 9, 2019 [Page 3] Internet-Draft LDP Extension for BIER September 2018 3. MLDP P2MP BIER Signalling 3.1. Definitions F-BM: Forwarding Bit Mask, An array of Bit, which is defined in [RFC8279]. Peer F-BM: For LSR A and P2MP FEC, this is the F-BM that included in Label Mapping from a downstream LSR for P2MP FEC to A. Downstream F-BM: For LSR A and P2MP FEC, this is the OR'ing result of each of the F-BM included in Label Mapping from downstream LSR for P2MP FEC to A. A use this Downstream F-BM in its Lable Mapping to upstream node for P2MP FEC. In other words, A's Downstream F-BM is A's upstream node's Peer F-BM. 3.2. Example Consider LSRs A - F, interconnected as follows: ( A ) ------------ ( B ) ------------ ( C ) ------------ ( D ) (Root) \ \ 1 (0:0001) \ \ ( E ) ( F ) 3 (0:0100) 2 (0:0010) Figure 1: P2MP-based BIER Topology Say that the node D has a BFR-id 1, F has a BFR-id 2, and E has a BFR-id 3, and we use a Bit String Length 4 (which is not valid per [RFC8296]) as an example. Consider an P2MP FEC for which A is the Root, and say that D,E,F are all the Leafs of this P2MP FEC. While D send LDP Mapping to C, it includes a F-BM 0001. Say that C got a Peer F-BM 0001, and then C form a Downstream F-BM 0001. While F send LDP Mapping to C, it includes a F-BM 0010. Say that C got a Peer F-BM 0010, and then C form a Downstream F-BM 0011. While C send LDP Mapping to B, it includes a F-BM 0010. Say that B got a Peer F-BM 0011, and then B form a Downstream F-BM 0011. While E send LDP Mapping to B, it includes a F-BM 0100. Say that B got a Peer F-BM 0100, and then B form a Downstream F-BM 0111. Xie, et al. Expires March 9, 2019 [Page 4] Internet-Draft LDP Extension for BIER September 2018 While B send LDP Mapping to A, it includes a F-BM 0111. Say that A got a Peer F-BM 0111, and then A form a Downstream F-BM 0111. This memo describes how every nodes in a P2MP tree get Peer F-BM from every downstream LSR, form a Downstream F-BM by OR'ing all it's Downstream Peer F-BM, and send a Mapping to it's upstream node using the Downstream F-BM. 3.3. Signaling the P2MP BIER The procedure for signalling the P2MP BIER is performed hop-by-hop by each LSR L along an P2MP LSP for a given P2MP FEC. The steps are as follows: 1. First, L computes its Downstream F-BM for P2MP FEC: If L is a leaf for P2MP FEC, L sets the F-BM with it's BFRID's BitPosition to 1. Otherwise (L is not a Leaf), L computes the Downstream F-BM by OR'ing all it's downstream Node's F-BM, as described above. 2. For each LDP neighbor of L to which L decides to send a Mapping for FEC F, L attaches an BIER TLV with the F-BM that it computed for this P2MP FEC. 3. When a new BIER TLV is received for P2MP FEC from a downstream LSR or the set of downstream LSRs, L returns to step 1. If the newly computed Downstream F-BM is unchanged, L SHOULD NOT advertise new information to its upstream neighbor. Otherwise, L readvertises its Mappings to its upstream neighbor with an updated BIER TLV. This behavior is standard for attributes such as path vector, hop count, and MTU, and the same rules apply, as specified in [RFC5036]. If the Downstream F-BM changes, L MAY readvertise the new F-BM immediately, or hold down the readvertisement for a while. 3.4. The P2MP BIER LSP Identifier [RFC6388] defined the P2MP FEC Element, which include a LDP MP Opaque Value Element. It also defined a Generic LSP Identifier as the LDP MP Opaque Value Element, with a TLV of Type 1. This document defined a new type of LDP MP Opaque Value Element, called the P2MP BIER LSP Identifier. The encoding for the P2MP BIER LSP Identifer is as follows: Xie, et al. Expires March 9, 2019 [Page 5] Internet-Draft LDP Extension for BIER September 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 |ID(High 8bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID(Low 24bits) |Reserve|BS Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Set Identifier | +-+-+-+-+-+-+-+-+ Type: TBD. Need to be less than 255. Length: 6 ID: A 32-bit integer, same as RFC6388. BS Len: Bit String Length Set Identifier: as defined in RFC8279. Figure 2: P2MP BIER LSP Identifer 3.5. BIER TLV The BIER TLV encodes information on the F-BM for an LSP, from the advertising LSR to the egress(es) over all valid paths. The encoding for the BIER TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1| BIER TLV (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |BS Len |Set Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F-BM (first 32 bits) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ F-BM (last 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Length: Length BSL: Bit String Length Set Identifier: as defined in RFC8279. F-BM: Forwarding Bit Mask Figure 3: BIER TLV Xie, et al. Expires March 9, 2019 [Page 6] Internet-Draft LDP Extension for BIER September 2018 3.6. Make Before Break (MBB) The Make Before Break (MBB) mechanism for mLDP P2MP defined in RFC6388 also applies. 4. Capability and Error handling The extensions defined in this document utilize the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for a session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all multi-topology label mappings learned via the session. An LSR should respond with an LDP MP Status in LDP Notification Messages when it receives an LDP Label Mapping message with a P2MP FEC element specifying an BIER TLV that is not locally known or not supported. The LSR MUST also discard the entire message before sending the Notification message. 4.1. BIER Capability A new optional capability parameter TLV, RMR Capability, is defined. Following is the format of the RMR Capability Parameter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| BIER Capability (IANA) | Length (= 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved |P|D|I|R| Rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BIER Capability TLV Format U: set to 1. Ignore, if not known. F: Set to 0. Do not forward. S: MUST be set to 1 to advertise the BIER TLV. P: The node has BIER P-Capability. D: The node has BIER D-Capability. I: The node Ignore the BIER Header except the Label. R: The node Require a packet without BIER Header except the Label. Figure 4: BIER Capability The BIER Capability TLV MUST be advertised in the LDP Initialization message. If the peer has not advertised the BIER capability, then label messages including a BIER TLV MUST NOT be sent to the peer. If an LSR has not advertised that it is BIER capable, its LDP peers MUST NOT send it messages that include BIER TLV. If an LSR receives Xie, et al. Expires March 9, 2019 [Page 7] Internet-Draft LDP Extension for BIER September 2018 a Label Mapping message with an BIER TLV from downstream LSR-D and its upstream LSR-U has not advertised that it is BIER capable, the LSR MUST send an BIER notification immediately to LSR-D. If this happens, an P2MP BIER LSP will not be established, a normal P2MP LSP will not be established either. P-Capability indicate a complete BIER function, which includes P-Capability and D-Capability. If a node support P-Capability, then it support the whole BIER function, which means it support both P-capability and D-capability. D-Capability indicate a subset of BIER function, to Disposition some length of a packet from some offset. For example, from BIER Label and a whole ( BIER Header Length ) , or from the position after BIER Label and a length of ( BIER Header Length - BIER Label Length ) . If a node don't support P-Capability, it may still support D-Capability. If a node don't support D-capability, it must not support P-Capability. If a Node doesn't have P-Capability, then P flag MUST be cleared. Whether the node will be a Branch or BUD or Leaf, the I flag SHOULD be set. if a node doesn't have D-Capability, then P and D flag MUST be cleared. If the node will be a BUD or Leaf then R flag SHOULD be set. if the node will be a Branch then R flag MAY not be set. if a node doesn't have P-Capability but does have D-Capability, then D flag SHOULD be set, but R flag MAY be set or not be set. 4.2. BIER Status A new optional LDP MP Status Value Element (RFC6388), BIER Status, is defined. Following is the format of the BIER Status: Xie, et al. Expires March 9, 2019 [Page 8] Internet-Draft LDP Extension for BIER September 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BIER Type = 1 | Length = 1 | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The BIER Status is a type of the LDP MP Status Value Element LDP MP Status Value Element TLV Type(RFC6388): Type 0: Reserved Type TBD: BIER Status Status Code: 1 = BIER TLV not supported 2 = Leaf or Bud don't have D-capability, must set R flag 3 = Branch or Bud don't have P-capability, must set I flag 4 = Node must set R flag when Upstream has R flag 5 = Node must clear R flag when any of downstream not have R flag Figure 5: BIER Status TLV 4.3. Check Capability and Use Status for Error Handling In order to deploy P2MP BIER on a network with some legacy nodes, which may not support P-capability or D-capability, some Capability flags need to be checked and notification messages may be generated. If all edge nodes support D-capability, but some nodes don't support P-capability and they set a I flag as required, then deployment of P2MP BIER is fine, and a BIER packet can walk from Root to all Leaf(s) without any change except the BIER Label. If an LSR support P-capability, and it's upstream node also support P-capability, and when the LSR receives a Label Mapping message with an BIER TLV and R flag set from downstream LSR-D, the LSR will accept such Label Mapping message. If receives a Label Mapping wiht an BIER TLV and R flag cleaned another downstream LSR-D', the LSR will accept too. If an LSR receives a Label Mapping message with an BIER TLV from downstream LSR-D with a R flag, and its upstream LSR-U has no P-capability, the LSR MUST send an BIER notification immediately to LSR-D. If this happens, an P2MP BIER LSP will not be established, a normal P2MP LSP will not be established either. When an LSR receives a Label Mapping message, it need to do some check before process and build P2MP BIER forwarding table. Such check includes: 1) Check if the node's P-capability and D-capability conflict with it's I flag and R flag. Xie, et al. Expires March 9, 2019 [Page 9] Internet-Draft LDP Extension for BIER September 2018 The following table list the whole check matrix. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NODE's | NODE's | Check | | | Role | PDIR-flag | Result | Rule | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf | [PDxx] | OK | (*) Comment 1 | | Leaf | [-Dxx] | OK | | | Leaf | [--xR] | OK | Rule 1 | | Leaf | [--x-] | ERR | Rule 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Branch | [PDxx] | OK | (*) Comment 1 | | Branch | [-DIx] | OK | Rule 2 | | Branch | [-D-x] | ERR | Rule 2 | | Branch | [--Ix] | OK | (*) Comment 2 | | Branch | [---x] | ERR | Rule 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BUD | [PDxx] | OK | (*) Comment 1 | | BUD | [-DIx] | OK | Rule 2 | | BUD | [-D-x] | ERR | Rule 2 | | BUD | [--IR] | OK | | | BUD | [--I-] | ERR | Rule 1 | | BUD | [---R] | ERR | Rule 2 | | BUD | [----] | ERR | Rule 1 & 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (*) Comment 1: In some cases, set a R flag is useful (*) Comment 2: In some cases, Clear R flag on a Branch node is useful Rule 1: Leaf don't have D-capability, must set R flag Rule 2: Branch don't have P-capability, must set I flag Figure 6: BIER Self Check Matrix 2) Check the node's R flag, the node's upstream R flag, the node's downstream R flag. The following table list the whole check martrix about the R flag of node, the upstream node, the downstream nodes. Xie, et al. Expires March 9, 2019 [Page 10] Internet-Draft LDP Extension for BIER September 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NODE's | Upstream |Downstream | Check | | | PDIR-flag | PDIR-flag | PDIR-flag | Result | Rule | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [XXX-] | [XXX-] | Any | Success | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [XXX-] | [XXXR] | Any | Fail | Rule A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [XXXR] | [XXXX] | [XXX-] | Fail | Rule B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [XXXR] | [XXXX] | [XXXR] | Success | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rule A: Node must set R flag when Upstream has R flag Rule B: Node must clear R flag when any of downstream not have R flag Figure 7: BIER upstream and downstream check When the above two checks fail, a notification message with a reason code is sent to the downstream node which send the Label Mapping message. 5. IANA Considerations Allocation is expected from IANA for a new type codepoints for "P2MP BIER LSP Identifier" from the "LDP MP Opaque Value Element basic type" registry of the "Label Distribution Protocol (LDP) Parameters" registry. Allocation is expected from IANA for a new type codepoints for "BIER TLV" from the "TLV Type Name Space" registry of the "Label Distribution Protocol (LDP) Parameters" registry. Allocation is expected from IANA for a new type codepoints for "BIER capability TLV" from the "TLV Type Name Space" registry of the "Label Distribution Protocol (LDP) Parameters" registry. Allocation is expected from IANA for a new type codepoints for "BIER Status" from the "LDP MP Status Value Element type" registry of the "Label Distribution Protocol (LDP) Parameters" registry. 6. Security Considerations TBD Xie, et al. Expires March 9, 2019 [Page 11] Internet-Draft LDP Extension for BIER September 2018 7. Acknowledgements TBD 8. References 8.1. Normative References [I-D.ietf-bier-mvpn] Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- mvpn-11 (work in progress), March 2018. [I-D.xie-bier-mvpn-mpls-p2mp] Xie, J., McBride, M., Chen, M., and L. Geng, "Multicast VPN Using MPLS P2MP and BIER", draft-xie-bier-mvpn-mpls- p2mp-02 (work in progress), July 2018. [RFC3988] Black, B. and K. Kompella, "Maximum Transmission Unit Signalling Extensions for the Label Distribution Protocol", RFC 3988, DOI 10.17487/RFC3988, January 2005, . [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, . [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point- to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, . [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, . Xie, et al. Expires March 9, 2019 [Page 12] Internet-Draft LDP Extension for BIER September 2018 [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, . 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Jingrong Xie Huawei Technologies Q15 Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China Email: xiejingrong@huawei.com Mach Chen Huawei Email: mach.chen@huawei.com Robin Li Huawei Email: lizhenbin@huawei.com Xie, et al. Expires March 9, 2019 [Page 13]