Internet DRAFT - draft-xie-mpls-rsvp-bier-extension
draft-xie-mpls-rsvp-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
RSVP-TE Extensions for P2MP-based BIER
draft-xie-mpls-rsvp-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. This document describes extensions to Resource
Reservation Protocol - Traffic Engineering (RSVP-TE) for the set up
of Traffic Engineered (TE) point-to-multipoint (P2MP) Label Switched
Paths (LSPs) with BIER infomation, 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 RSVP-TE Extensions for P2MP-based 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Example of signaling the P2MP-BIER . . . . . . . . . . . 3
3.2. PATH Message . . . . . . . . . . . . . . . . . . . . . . 4
3.3. RESV Message . . . . . . . . . . . . . . . . . . . . . . 5
3.4. SESSION Object . . . . . . . . . . . . . . . . . . . . . 7
3.4.1. P2MP BIER Tunnel IPv4 SESSION Object . . . . . . . . 7
3.4.2. P2MP BIER Tunnel IPv6 SESSION Object . . . . . . . . 8
3.5. SENDER_TEMPLATE Object . . . . . . . . . . . . . . . . . 8
3.5.1. P2MP BIER Tunnel IPv4 SENDER_TEMPLATE Object . . . . 9
3.5.2. P2MP BIER Tunnel IPv6 SENDER_TEMPLATE Object . . . . 9
3.6. S2L_BIER_SUB_LSP Object . . . . . . . . . . . . . . . . . 10
3.6.1. S2L_BIER_SUB_LSP IPv4 Object . . . . . . . . . . . . 10
3.6.2. S2L_BIER_SUB_LSP IPv6 Object . . . . . . . . . . . . 11
3.7. FILTER_SPEC Object . . . . . . . . . . . . . . . . . . . 11
3.7.1. P2MP BIER_IPv4 FILTER_SPEC Object . . . . . . . . . . 11
3.7.2. P2MP BIER_IPv6 FILTER_SPEC Object . . . . . . . . . . 11
4. Capability and Error Handling . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
Xie, et al. Expires March 9, 2019 [Page 2]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
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. [RFC4875] defines extensions to the RSVP-TE protocol
([RFC3209] and [RFC3473] ) to support P2MP TE LSPs satisfying the set
of requirements described in [RFC4461] .
This document extends RSVP-TE to establish P2MP TE LSPs with BIER
information, which is called P2MP based BIER in
[I-D.xie-bier-mvpn-mpls-p2mp].
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 LSP: Label Switch Path
o LSR: Label Switching Router
o BFR: BIER Forwarding Router
o BFR-ID: BIER Forwarding Router IDentify.
o P2MP: Point to Multi-point
o P2MP based BIER: BIER using P2MP as topology
3. RSVP Extensions
RSVP Extensions to setup a P2MP-based BIER is very similar to the
setup of a P2MP LSP described in [RFC4875]. Most of the structure
and description are borrowed from RFC4875, and a precursive example
is put in the beginning to give a whole picture of building the
forwarding state of P2MP based BIER.
3.1. Example of signaling the P2MP-BIER
Consider LSRs A - F, interconnected as follows:
Xie, et al. Expires March 9, 2019 [Page 3]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
( 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.
Consider an P2MP SESSION<P2MPID, TunnelID, ExtTunnelID=RootAddr>, for
which A is the Root, and say that D,E,F are all the Leafs of this
P2MP SESSION.
There are 3 Sub-LSPs: A-->B-->E, A-->B-->C-->D, A-->B-->C-->F.
PATH message: When PATH message walk through A-->B-->E, it include an
session attribute that identify ths session is to establish a P2MP-
based BIER LSP. The same to A-->B-->C-->D and A-->B-->C-->F.
RESV message: When RESV message work throuth A<--B<--E, it include an
Object that identify BFR-ID of E. The same to A<--B<--C<--D and
A<--B<--C<--F.
Procedure: B learns that it's downstream endpoint has a BFR-ID<3>
after a RSVP message passes through A<--B<--E. B also learns a BFR-
ID<1> after a RSVP message passes throuth A<--B<--C<--D, and a BFR-
ID<2> after a RSVP message passes through A<--B<--C<--D.
3.2. PATH Message
This section describes modifications made to the Path message format
as specified in [RFC4875]. The Path message is enhanced to signal
one or more S2L sub-LSPs with BIER information. This is done by
including the S2L BIER sub-LSP descriptor list in the Path message as
shown below.
Xie, et al. Expires March 9, 2019 [Page 4]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ...]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[<S2L BIER sub-LSP descriptor list>]
<S2L BIER sub-LSP descriptor list> ::= <S2L BIER sub-LSP descriptor>
[ <S2L BIER sub-LSP descriptor list> ]
<S2L BIER sub-LSP descriptor> ::= <S2L_BIER_SUB_LSP>
[ <P2MP SECONDARY_EXPLICIT_ROUTE> ]
Figure 2: PATH Message
3.3. RESV Message
The Resv message follows the [RFC4875] format:
Xie, et al. Expires March 9, 2019 [Page 5]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FF flow descriptor>
| <FF flow descriptor list>
<FF flow descriptor>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
[ <S2L BIER sub-LSP flow descriptor list> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
[ <S2L BIER sub-LSP flow descriptor list> ]
<S2L BIER sub-LSP flow descriptor list> ::=
<S2L BIER sub-LSP flow descriptor>
[ <S2L BIER sub-LSP flow descriptor list> ]
<S2L BIER sub-LSP flow descriptor> ::= <S2L_BIER_SUB_LSP>
[ <P2MP_SECONDARY_RECORD_ROUTE> ]
Figure 3: RESV Message
FILTER_SPEC is defined in below section.
The S2L BIER sub-LSP flow descriptor has the same format as S2L BIER
sub-LSP descriptor in previous section with the difference that a
P2MP_SECONDARY_RECORD_ROUTE object is used in place of a P2MP
SECONDARY_EXPLICIT_ROUTE object.
Note that a Resv message can signal multiple S2L BIER sub-LSPs that
may belong to the same FILTER_SPEC object or different FILTER_SPEC
Xie, et al. Expires March 9, 2019 [Page 6]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
objects. The same label SHOULD be allocated if the <Sender Address,
LSP-ID> fields of the FILTER_SPEC object are the same.
However different labels MUST be allocated if the <Sender Address,
LSP-ID> of the FILTER_SPEC object is different, as that implies that
the FILTER_SPEC refers to a different P2MP BIER LSP.
3.4. SESSION Object
A P2MP BIER LSP SESSION object is used. This object uses the
existing SESSION C-Num. New C-Types are defined to accommodate a
logical P2MP destination identifier of the P2MP BIER tunnel. This
SESSION object has a similar structure as the existing point-to-
multipoint RSVP-TE SESSION object. However the C-Types is different.
All S2L BIER sub-LSPs that are part of the same P2MP BIER LSP share
the same SESSION object. This SESSION object identifies the P2MP
BIER tunnel.
The combination of the SESSION object, the SENDER_TEMPLATE object and
the S2L_BIER_SUB_LSP object identifies each S2L BIER sub-LSP. This
follows the existing P2MP RSVP-TE notion of using the SESSION object
for identifying a P2MP Tunnel, which in turn can contain multiple
LSPs, each distinguished by a unique SENDER_TEMPLATE object.
3.4.1. P2MP BIER Tunnel IPv4 SESSION Object
Class = SESSION, P2MP_BIER_TUNNEL_IPv4 C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserve|BS Len |Set Identifier | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: P2MP BIER Tunnel IPv4 SESSION Object
P2MP ID: A 32-bit identifier used in the SESSION object that remains
constant over the life of the P2MP BIER tunnel. It encodes the P2MP
Identifier that is unique within the scope of the ingress LSR.
BS Len: A 4 bits field encoding the supported BitString length
associated with this BFR-prefix. The values allowed in this field
are specified in section 2 of [RFC8296].
Xie, et al. Expires March 9, 2019 [Page 7]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
Set Identifier: A 8 bits fields encoding the Set Identifier (section
1 of [RFC8279])
Tunnel ID: A 16-bit identifier used in the SESSION object that
remains constant over the life of the P2MP BIER tunnel.
Extended Tunnel ID: A 32-bit identifier used in the SESSION object
that remains constant over the life of the P2MP BIER tunnel. Ingress
LSRs that wish to have a globally unique identifier for the P2MP BIER
tunnel SHOULD place their tunnel sender address here. A combination
of this address, P2MP ID, and Tunnel ID provides a globally unique
identifier for the P2MP BIER tunnel.
3.4.2. P2MP BIER Tunnel IPv6 SESSION Object
Class = SESSION, P2MP_BIER_TUNNEL_IPv6 C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Reserve|BS Len |Set Identifier | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (16 bytes) |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: P2MP BIER Tunnel IPv6 SESSION Object
This is the same as the P2MP BIER Tunnel IPv4 LSP SESSION object with
the difference that the extended tunnel ID may be set to a 16-byte
identifier [RFC3209].
3.5. SENDER_TEMPLATE Object
The SENDER_TEMPLATE object contains the ingress LSR source address.
The LSP ID can be changed to allow a sender to share resources with
itself. Thus, multiple instances of the P2MP BIER tunnel can be
created, each with a different LSP ID. The instances can share
resources with each other. The S2L BIER sub-LSPs corresponding to a
particular instance use the same LSP ID.
The combination of the SESSION object, the SENDER_TEMPLATE object and
the S2L_BIER_SUB_LSP object identifies each S2L BIER sub-LSP. This
follows the existing P2MP RSVP-TE notion of using the SESSION object
Xie, et al. Expires March 9, 2019 [Page 8]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
for identifying a P2MP Tunnel, which in turn can contain multiple
LSPs, each distinguished by a unique SENDER_TEMPLATE object.
3.5.1. P2MP BIER Tunnel IPv4 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_BIER_TUNNEL_IPv4 C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Group Originator ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: P2MP BIER Tunnel IPv4 SENDER_TEMPLATE Object
IPv4 tunnel sender address
See [RFC3209].
Sub-Group Originator ID
The Sub-Group Originator ID is set to the TE Router ID of the LSR
that originates the Path message. This is either the ingress LSR or
an LSR which re-originates the Path message with its own Sub- Group
Originator ID.
Sub-Group ID
An identifier of a Path message used to differentiate multiple Path
messages that signal state for the same P2MP BIER LSP. This may be
seen as identifying a group of one or more egress nodes targeted by
this Path message.
LSP ID
See [RFC3209].
3.5.2. P2MP BIER Tunnel IPv6 SENDER_TEMPLATE Object
Class = SENDER_TEMPLATE, P2MP_BIER_TUNNEL_IPv6 C-Type = TBD
Xie, et al. Expires March 9, 2019 [Page 9]
Internet-Draft RSVP-TE Extensions for P2MP-based 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Sub-Group Originator ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: P2MP BIER Tunnel IPv6 SENDER_TEMPLATE Object
This is the same as the P2MP BIER Tunnel IPv4 SENDER_TEMPLATE Object
with the difference that the sender address and Sub-Group Originator
ID may be set to a 16-byte identifier [RFC3209].
3.6. S2L_BIER_SUB_LSP Object
An S2L_BIER_SUB_LSP object identifies a particular S2L BIER sub-LSP
belonging to the P2MP BIER LSP.
3.6.1. S2L_BIER_SUB_LSP IPv4 Object
S2L_BIER_SUB_LSP Class = TBD, S2L_BIER_SUB_LSP_IPv4 C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 S2L BIER Sub-LSP destination address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: S2L_BIER_SUB_LSP IPv4 Object
Xie, et al. Expires March 9, 2019 [Page 10]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
IPv4 BIER Sub-LSP destination address
IPv4 address of the S2L BIER sub-LSP destination.
3.6.2. S2L_BIER_SUB_LSP IPv6 Object
S2L_BIER_SUB_LSP Class = TBD, S2L_BIER_SUB_LSP_IPv6 C-Type = TBD
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 S2L BIER Sub-LSP destination address (16 bytes) |
| .... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFR-ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: S2L_BIER_SUB_LSP IPv6 Object
This is the same as the S2L BIER IPv4 Sub-LSP object, with the
difference that the destination address is a 16-byte IPv6 address.
3.7. FILTER_SPEC Object
The FILTER_SPEC object is canonical to the P2MP BIER SENDER_TEMPLATE
object.
3.7.1. P2MP BIER_IPv4 FILTER_SPEC Object
Class = FILTER_SPEC, P2MP BIER LSP_IPv4 C-Type = TBD
The format of the P2MP BIER_IPv4 FILTER_SPEC object is identical to
the P2MP BIER_IPv4 SENDER_TEMPLATE object.
3.7.2. P2MP BIER_IPv6 FILTER_SPEC Object
Class = FILTER_SPEC, P2MP BIER LSP_IPv6 C-Type = TBD
The format of the P2MP BIER_IPv6 FILTER_SPEC object is identical to
the P2MP BIER_IPv6 SENDER_TEMPLATE object.
4. Capability and Error Handling
TBD.
Xie, et al. Expires March 9, 2019 [Page 11]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
5. IANA Considerations
Allocation is expected from IANA for codepoints from the "Class
Names, Class Numbers, and Class Types" registry.
6. Security Considerations
TBD
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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
<https://www.rfc-editor.org/info/rfc4461>.
Xie, et al. Expires March 9, 2019 [Page 12]
Internet-Draft RSVP-TE Extensions for P2MP-based BIER September 2018
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>.
[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
[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]
