Internet DRAFT - draft-xie-mpls-ldp-bier-extension
draft-xie-mpls-ldp-bier-extension
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<Root,N>, this is the F-BM that
included in Label Mapping from a downstream LSR for P2MP FEC<Root,N>
to A.
Downstream F-BM: For LSR A and P2MP FEC<Root,N>, this is the OR'ing
result of each of the F-BM included in Label Mapping from downstream
LSR for P2MP FEC<Root,N> to A. A use this Downstream F-BM in its
Lable Mapping to upstream node for P2MP FEC<Root,N>. 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<Root=A,N=10> for which A is the Root, and say
that D,E,F are all the Leafs of this P2MP FEC<Root=A, N=10>.
While D send LDP Mapping to C, it includes a F-BM 0001. Say that C
got a Peer<D> 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> 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<C> 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<E> 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<B> 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<Root,N>. The steps
are as follows:
1. First, L computes its Downstream F-BM for P2MP FEC<Root,N>:
If L is a leaf for P2MP FEC<Root,N>, 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<Root,N> 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,
<https://www.rfc-editor.org/info/rfc3988>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009,
<https://www.rfc-editor.org/info/rfc5561>.
[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,
<https://www.rfc-editor.org/info/rfc6388>.
[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>.
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, <https://www.rfc-editor.org/info/rfc8296>.
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,
<https://www.rfc-editor.org/info/rfc2119>.
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]