Shepherd writeup
draft-ietf-bier-mvpn-11

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?Ê Why
is this the proper type of RFC?Ê Is this type of RFC indicated in the
title page header?


draft-ietf-bier-mvpn-09 is Experimental.  This is indicated on the title page.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Ê  The Multicast Virtual Private Network (MVPN) specifications require
   the use of multicast tunnels ("P-tunnels") that traverse a Service
   Provider's backbone network.  The P-tunnels are used for carrying
   multicast traffic across the backbone.  A variety of P-tunnel types
   are supported.  Bit Index Explicit Replication (BIER) is a new
   architecture that provides optimal multicast forwarding through a
   "multicast domain", without requiring intermediate routers to
   maintain any per-flow state or to engage in an explicit tree-building
   protocol.  This document specifies the protocol and procedures that
   allow MVPN to use BIER as the method of carrying multicast traffic
   over an SP backbone network.



Working Group Summary

Ê The draft has been well received.

Document Quality

Based on the discussions at the WG (IETF 98/99) multiple implementations exist and in other cases vendors indicated a strong roadmap commitment.
Ê

Not aware of changes requiring special attention.



Who is the Responsible Area Director? 

Alia Atlas



(1.a)  Who is the Document Shepherd for this document?  

Nabeel Cocker

Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Yes, the Document Shepherd has reviewed version -09 of the draft updated Nov 13th 2017 and it addresses all the comments made on the mailing list and is ready for IESG publication.


(1.b)  Has the document had adequate review both from key WG members  and from key non-WG members?  

Yes for within the WG and for  outside the WG PIM, MBONED, and MPLS have been involved.


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No

(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.  

No such concerns

Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No

(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Based on the discussion held during the IETFs and on the mailing list, the consensus is solid.  Have not seen any objections


(1.f)  Has anyone threatened an appeal or otherwise indicated extreme discontent?  If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.  (It should be in a separate email because this questionnaire is entered into the ID Tracker.)

No

(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough.  Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews?  If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Verified the checklist...also used the online tool.  Looks good. (NITS output attached at the bottom)

Authors indicate that there are no MIBs


(1.h)  Has the document split its references into normative and informative?  

Yes

Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state?  If such normative references exist, what is the strategy for their completion?  Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area  Director in the Last Call procedure for them [RFC3967].

No
					

Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No status change to existing RFCs


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Yes

 If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified?  If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations?  Does it suggest a reasonable name for the new registry?  See [RFC2434].  If the document describes an Expert Review process, has the Document  Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.

(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in  an automated checker?

No such sections in the document




idnits 2.15.00 


tmp/draft-ietf-bier-mvpn-09.txt:

 - The draft-ietf-bess-mvpn-expl-track state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-bess-mvpn-expl-track state file.

 - The draft-ietf-bier-architecture state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-bier-architecture state file.

 - The draft-ietf-bier-mpls-encapsulation state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-bier-mpls-encapsulation state file.

 - The draft-ietf-bier-mvpn state file is not from today.
   Attempting to download a newer one...
 - Success fetching draft-ietf-bier-mvpn state file.

 - The rfc1137 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc1137 state file.

 - The rfc4364 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc4364 state file.

 - The rfc510 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc510 state file.

 - The rfc5331 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc5331 state file.

 - The rfc6513 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc6513 state file.

 - The rfc6514 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc6514 state file.

 - The rfc6625 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc6625 state file.

 - The rfc7524 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc7524 state file.

 - The rfc7900 state file is not from today.
   Attempting to download a newer one...
 - Success fetching rfc7900 state file.

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

     No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     No issues found here.

  Checking references for intended status: Experimental
  ----------------------------------------------------------------------------

     No issues found here.

     No nits found.
--------------------------------------------------------------------------------


2	Internet Engineering Task Force                            E. Rosen, Ed.
3	Internet-Draft                                    Juniper Networks, Inc.
4	Intended status: Experimental                               M. Sivakumar
5	Expires: May 17, 2018                                Cisco Systems, Inc.
6	                                                               S. Aldrin
7	                                                            Google, Inc.
8	                                                             A. Dolganow
9	                                                                   Nokia
10	                                                           T. Przygienda
11	                                                  Juniper Networks, Inc.
12	                                                       November 13, 2017

14	                        Multicast VPN Using BIER
15	                        draft-ietf-bier-mvpn-09

17	Abstract

19	   The Multicast Virtual Private Network (MVPN) specifications require
20	   the use of multicast tunnels ("P-tunnels") that traverse a Service
21	   Provider's backbone network.  The P-tunnels are used for carrying
22	   multicast traffic across the backbone.  A variety of P-tunnel types
23	   are supported.  Bit Index Explicit Replication (BIER) is a new
24	   architecture that provides optimal multicast forwarding through a
25	   "multicast domain", without requiring intermediate routers to
26	   maintain any per-flow state or to engage in an explicit tree-building
27	   protocol.  This document specifies the protocol and procedures that
28	   allow MVPN to use BIER as the method of carrying multicast traffic
29	   over an SP backbone network.

31	Status of This Memo

33	   This Internet-Draft is submitted in full conformance with the
34	   provisions of BCP 78 and BCP 79.

36	   Internet-Drafts are working documents of the Internet Engineering
37	   Task Force (IETF).  Note that other groups may also distribute
38	   working documents as Internet-Drafts.  The list of current Internet-
39	   Drafts is at https://datatracker.ietf.org/drafts/current/.

41	   Internet-Drafts are draft documents valid for a maximum of six months
42	   and may be updated, replaced, or obsoleted by other documents at any
43	   time.  It is inappropriate to use Internet-Drafts as reference
44	   material or to cite them other than as "work in progress."

46	   This Internet-Draft will expire on May 17, 2018.

48	Copyright Notice

50	   Copyright (c) 2017 IETF Trust and the persons identified as the
51	   document authors.  All rights reserved.

53	   This document is subject to BCP 78 and the IETF Trust's Legal
54	   Provisions Relating to IETF Documents
55	   (https://trustee.ietf.org/license-info) in effect on the date of
56	   publication of this document.  Please review these documents
57	   carefully, as they describe your rights and restrictions with respect
58	   to this document.  Code Components extracted from this document must
59	   include Simplified BSD License text as described in Section 4.e of
60	   the Trust Legal Provisions and are provided without warranty as
61	   described in the Simplified BSD License.

63	Table of Contents

65	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
66	   2.  Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . .   5
67	     2.1.  MPLS Label  . . . . . . . . . . . . . . . . . . . . . . .   7
68	     2.2.  Explicit Tracking . . . . . . . . . . . . . . . . . . . .   9
69	       2.2.1.  Using the LIR Flag  . . . . . . . . . . . . . . . . .   9
70	       2.2.2.  Using the LIR-pF Flag . . . . . . . . . . . . . . . .  10
71	   3.  Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . .  11
72	   4.  Data Plane  . . . . . . . . . . . . . . . . . . . . . . . . .  12
73	     4.1.  Encapsulation and Transmission  . . . . . . . . . . . . .  12
74	     4.2.  Disposition . . . . . . . . . . . . . . . . . . . . . . .  13
75	       4.2.1.  At a BFER that is an Egress PE  . . . . . . . . . . .  14
76	       4.2.2.  At a BFER that is a P-tunnel Segmentation Boundary  .  14
77	   5.  Contributor Addresses . . . . . . . . . . . . . . . . . . . .  14
78	   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
79	   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
80	   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
81	   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
82	     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
83	     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
84	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

86	1.  Introduction

88	   [RFC6513] and [RFC6514] specify the protocols and procedures that a
89	   Service Provider (SP) can use to provide Multicast Virtual Private
90	   Network (MVPN) service to its customers.  Multicast tunnels are
91	   created through an SP's backbone network; these are known as
92	   "P-tunnels".  The P-tunnels are used for carrying multicast traffic
93	   across the backbone.  The MVPN specifications allow the use of
94	   several different kinds of P-tunnel technology.

96	   Bit Index Explicit Replication (BIER) ([BIER_ARCH]) is an
97	   architecture that provides optimal multicast forwarding through a
98	   "multicast domain", without requiring intermediate routers to
99	   maintain any per-flow state or to engage in an explicit tree-building
100	   protocol.  The purpose of the current document is to specify the
101	   protocols and procedures needed in order to provide MVPN service
102	   using BIER to transport the multicast traffic over the backbone.

104	   Although BIER does not explicitly build and maintain multicast
105	   tunnels, one can think of BIER as using a number of implicitly
106	   created tunnels through a "BIER domain".  In particular, one can
107	   think of there as being one Point-to-Multipoint (P2MP) tunnel from
108	   each "Bit Forwarding Ingress Router" (BFIR) to all the "Bit
109	   Forwarding Egress Routers" (BFERs) in the BIER domain, where a BIER
110	   domain is generally co-extensive with an IGP network.  These
111	   "tunnels" are not specific to any particular VPN.  However, the MVPN
112	   architecture provides protocols and procedures that allow the traffic
113	   of multiple MVPNs to be aggregated on a single P-tunnel.  In this
114	   document, we specify how to use these multi-VPN aggregation
115	   procedures to enable BIER to transport traffic from multiple MVPNs.

117	   MVPN traffic must sometimes traverse more than one IGP domain,
118	   whereas BIER only carries multicast traffic within a single IGP
119	   domain.  However, the MVPN specifications allow P-tunnels to be
120	   "segmented", where the segmentation points may either be Autonomous
121	   System Border Routers (ASBRs), as described in [RFC6514], or Area
122	   Border Routers (ABRs), as described in [RFC7524].  As long as the
123	   segmentation points are capable of acting as BFIRs and BFERs, BIER
124	   can be used to provide some or all of the segments of a P-tunnel.

126	   Procedures to support MVPN customers who are using BIDIR-PIM are
127	   outside the scope of this document.

129	   This document uses the following terminology from [BIER_ARCH]:

131	   o  BFR: Bit-Forwarding Router.

133	   o  BFIR: Bit-Forwarding Ingress Router.

135	   o  BFER: Bit-Forwarding Egress Router.

137	   This document uses the following terminology from [RFC6513]:

139	   o  MVPN: Multicast Virtual Private Network -- a VPN [RFC4364] in
140	      which multicast service is offered.

142	   o  P-tunnel.  A multicast tunnel through the network of one or more
143	      SPs.  P-tunnels are used to transport MVPN multicast data

145	   o  PMSI: Provider Multicast Service Interface.  PMSI is an
146	      abstraction that represents a multicast service for carrying
147	      packets.  A PMSI is instantiated via one or more P-tunnels.

149	   o  C-S: A multicast source address, identifying a multicast source
150	      located at a VPN customer site.

152	   o  C-G: A multicast group address used by a VPN customer.

154	   o  C-flow: A customer multicast flow.  Each C-flow is identified by
155	      the ordered pair (source address, group address), where each
156	      address is in the customer's address space.  The identifier of a
157	      particular C-flow is usually written as (C-S,C-G).

159	      Sets of C-flows can be identified by the use of the "C-*" wildcard
160	      (see [RFC6625]), e.g., (C-*,C-G).

162	   o  I-PMSI A-D Route: Inclusive PMSI Auto-Discovery route.  Carried in
163	      BGP Update messages, these routes are used to advertise the
164	      "default" P-tunnel for a particular MVPN.

166	   o  S-PMSI A-D route: Selective PMSI Auto-Discovery route.  Carried in
167	      BGP Update messages, these routes are used to advertise the fact
168	      that particular C-flows are bound to (i.e., are traveling through)
169	      particular P-tunnels.

171	   o  x-PMSI A-D route: a route that is either an I-PMSI A-D route or an
172	      S-PMSI A-D route.

174	   o  Leaf A-D route: a route that a multicast egress node sends in
175	      order to join a particular P-tunnel.

177	   o  PMSI Tunnel attribute (PTA).  In an x-PMSI A-D route, the NLRI of
178	      the route identifies a PMSI.  The BGP attribute known as the PMSI
179	      Tunnel attribute is attached to such a route in order to identify
180	      a particular P-tunnel that is associated with the PMSI.  When
181	      C-flows of multiple VPNs are carried in a single P-tunnel, this
182	      attribute also carries the information needed to multiplex and
183	      demultiplex the C-flows.  A PTA can also be carried by a Leaf A-D
184	      root.  In this case, it contains information that is needed in
185	      order for the originator of the route to join the specified
186	      P-tunnel.

188	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
189	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
190	   document are to be interpreted as described in RFC 2119 [RFC2119].

192	2.  Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes

194	   As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by
195	   an x-PMSI A-D route identifies the P-tunnel that is used to
196	   instantiate a particular PMSI.  If a PMSI is to be instantiated by
197	   BIER, the PTA is constructed by a BFIR.

199	   If segmented P-tunnels are not being used, the PTA attached to a
200	   given x-PMSI A-D route is constructed by the router that originated
201	   the route (typically by the ingress PE), and the PTA is not changed
202	   as the route is propagated.

204	   If segmented P-tunnels are being used, the PTA attached to a given
205	   x-PMSI A-D route by the route's originator may replaced, at a
206	   segmentation point (a BFER), by a PTA identifying the next segment of
207	   the P-tunnel.  If the next segment of the P-tunnel is instantiated by
208	   BIER, the segmentation point serves as the BFIR for that next
209	   segment.

211	   In either case, a PTA is constructed by a BFIR as follows (see
212	   Figure 1):

214	   The PTA contains the following fields:

216	   o  "Tunnel Type".  IANA has assigned 0x0B as the tunnel type
217	      codepoint for "BIER" in the "P-Multicast Service Interface Tunnel
218	      (PMSI Tunnel) Tunnel Types" registry.  This codepoint is used to
219	      indicate that the PMSI is instantiated by BIER.

221	      Although BIER does not actually create tunnels, the MVPN
222	      procedures treat BIER as if it were a type of tunnel.

224	   o  "Tunnel Identifier".  When the "tunnel type" is "BIER", this field
225	      contains three subfields:

227	      1.  The first subfield is a single octet, containing a BIER
228	          sub-domain-id.  (See [BIER_ARCH].)  This indicates that
229	          packets sent on the PMSI will be sent on the specified BIER
230	          sub-domain.  How that sub-domain is chosen is outside the
231	          scope of this document.

233	      2.  The second subfield is a two-octet field containing the
234	          BFR-id, in the sub-domain identified in the first subfield, of
235	          the router that is constructing the PTA.

237	      3.  The third subfield is the BFR-prefix (see [BIER_ARCH]) of the
238	          router (a BFIR) that is constructing the PTA.  The BFR-prefix
239	          will either be a /32 IPv4 address or a /128 IPv6 address.

241	          Whether the address is IPv4 or IPv6 can be inferred from the
242	          total length of the PTA.

244	          The BFR-prefix need not be the same IP address that is carried
245	          in any other field of the x-PMSI A-D route, even if the BFIR
246	          is the originating router of the x-PMSI A-D route.

248	      Failure to properly set the Tunnel Identifier field cannot be
249	      detected by the protocol, and will result in improper delivery of
250	      the data packets sent on the PMSI.

252	   o  "MPLS Label".  This field MUST contain an upstream-assigned non-
253	      zero MPLS label.  It is assigned by the router (a BFIR) that
254	      constructs the PTA.  Constraints on the way in which a BFIR
255	      selects this label are discussed in Section 2.1.

257	      Failure to follow the constraints on label assignment cannot be
258	      detected by the protocol, and may result in improper handling of
259	      data packets by the egress PE routers.

261	   o  "Flags".  When the tunnel type is BIER, two of the flags in the
262	      PTA Flags field are meaningful.  Details about the use of these
263	      flags can be found in Section 2.2.

265	      *  "Leaf Info Required per Flow (LIR-pF)".  This flag is
266	         introduced in [EXPLICIT_TRACKING].  A BFIR SHOULD NOT set this
267	         flag UNLESS it knows that all the BFERs in the BIER domain (or
268	         at least all the BFERs to which it needs to transmit) support
269	         this flag.  (How this is known is outside the scope of this
270	         document.)  Procedures for the use of this flag are given in
271	         Section 2.2.2.  Support for this flag is OPTIONAL.

273	      *  "Leaf Info Required Bit".  See Section 2.2.1.

275	          +---------------------------------+
276	          |  Flags (1 octet)                |
277	          +---------------------------------+
278	          |  Tunnel Type = 0x0B (1 octet)   |
279	          +---------------------------------+
280	          |  MPLS Label (3 octets)          |
281	          +---------------------------------+
282	          |  Sub-domain-id (1 octet)        |  <---
283	          +---------------------------------+     |
284	          |  BFR-id (2 octets)              |     |-- Tunnel
285	          +---------------------------------+     |   Identifier
286	          |  BFR-prefix (4 or 16 octets)    |  <---
287	          +---------------------------------+

289	                 Figure 1: PMSI Tunnel Attribute for BIER

291	   If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D
292	   route, the route MUST NOT be distributed beyond the boundaries of a
293	   BIER domain.  That is, any routers that receive the route must be in
294	   the same BIER domain as the originator of the route.  If the
295	   originator is in more than one BIER domain, the route must be
296	   distributed only within the BIER domain in which the BFR-prefix in
297	   the PTA uniquely identifies the originator.  As with all MVPN routes,
298	   distribution of these routes is controlled by the provisioning of
299	   Route Targets.  Thus the requirement expressed in this paragraph is
300	   really a requirement on the way the Route Targets are provisioned.

302	2.1.  MPLS Label

304	   The MPLS Label carried in the PTA is an upstream-assigned label.

306	   If two PTAs contain the same BFR-prefix in their respective Tunnel
307	   Identifier fields, then the labels carried in those PTAs MUST come
308	   from the same label space.  (See section 7 of [RFC5331].)  An
309	   implementation may choose to use this fact when setting up the tables
310	   it uses to interpret the upstream-assigned labels.

312	   Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and
313	   both PTAs specify a tunnel type of "BIER".

315	   o  If the two routes do not carry the same set of Route Targets
316	      (RTs), then their respective PTAs MUST contain different MPLS
317	      label values.

319	   o  If the two routes do not have the same Address Family Identifier
320	      (AFI) value, then their respective PTAs MUST contain different
321	      MPLS label values.  This ensures that when an egress PE receives a
322	      data packet with the given label, the egress PE can infer from the
323	      label whether the payload is an IPv4 packet or an IPv6 packet.

325	   o  If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])
326	      functionality, and if the two routes originate from different VRFs
327	      on this ingress PE, then the respective PTAs of the two routes
328	      MUST contain different MPLS label values.

330	   o  If the BFIR is an ingress PE supporting the "Extranet Separation"
331	      feature of MVPN extranet (see Section 7.3 of [RFC7900]), and if
332	      one of the routes carries the "Extranet Separation" extended
333	      community but the other does not, then the respective PTAs of the
334	      two routes MUST contain different MPLS label values.

336	   o  If segmented P-tunnels are being used, then the respective PTAs of
337	      the two routes MUST contain different MPLS label values whenever
338	      the respective NLRIs of the two routes are not identical.  The
339	      MPLS label can then be used at the next segmentation point to
340	      switch packets from one P-tunnel segment directly to the next,
341	      without requiring the segmentation points to contain any other
342	      multicast forwarding state.  This is explained further below.  See
343	      also Section 4.

345	   When segmented P-tunnels are being used, a segmentation point, call
346	   it "B1", may receive, from within a given BIER domain, an x-PMSI A-D
347	   route whose PTA specifies "BIER".  This means that BIER is being used
348	   for the previous segment of a segmented P-tunnel.  If the next
349	   segment is also of type "BIER", B1 will be the BFIR for the next
350	   segment.  That is, B1 is a BFER of one BIER domain (corresponding to
351	   the previous segment), and a BFIR of another BIER domain
352	   (corresponding to the next segment).  B1 needs to replace the PTA of
353	   the x-PMSI A-D route with a new PTA, specifying its own BFR-prefix,
354	   and specifying an upstream-assigned label assigned by B1 itself.

356	   Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where:

358	   o  R1 and R2 each have a PTA specifying BIER,

360	   o  R1's PTA specifies BFR-prefix B2 and Label L2.

362	   o  R2's PTA specifies BFR-prefix B3 and Label L3.

364	   Suppose B1 decides to propagate both R1 and R2, replacing each PTA
365	   with a new PTA specifying BIER.  Suppose these new PTAs specify
366	   labels L4 and L5 respectively.  Then L4 and L5 MUST be different
367	   (upstream-assigned) label values, UNLESS both of the following
368	   conditions hold:

370	   o  R1 and R2 have the same value in the Originating Router field of
371	      their respective NLRIs, and

373	   o  B2 is equal to B3, and

375	   o  L2 is equal to L3.

377	   The segmentation point (B1 in this example) MUST also program its
378	   dataplane appropriately.  For example, when:

380	   o  B1 receives a BIER packet for which it is a BFER, and

382	   o  the BIER header specifies the BFIR-id that corresponds to B2,and

384	   o  the BIER payload is an MPLS packet with upstream-assigned label,
385	      and

387	   o  the top label value is L2,

389	   then the dataplane must be programmed to replace L2 with L4, and to
390	   reencapsulate the packet in a BIER header, with B1's BFR-id in the
391	   BFIR-id field.  The BitString of the new BIER header is determined by
392	   the MVPN explicit tracking procedures (see Section 2.2 in the BIER
393	   domain of the next segment.

395	2.2.  Explicit Tracking

397	   When using BIER to transport an MVPN data packet through a BIER
398	   domain, an ingress PE functions as a BFIR (see [BIER_ARCH]).  The
399	   BFIR must determine the set of BFERs to which the packet needs to be
400	   delivered.  This can be done in either of two ways:

402	   1.  Using the explicit tracking mechanism based on the "Leaf Info
403	       Required" flag specified in [RFC6513] and [RFC6514].  This method
404	       is further described in Section 2.2.1.

406	   2.  Using the OPTIONAL explicit tracking mechanism based on the
407	       LIR-pF flag specified in [EXPLICIT_TRACKING].  This method,
408	       further described in Section 2.2.2, may be used if (and only if)
409	       segmented P-tunnels are not being used.

411	2.2.1.  Using the LIR Flag

413	   To determine the set of BFERs to which the packets of a given C-flow
414	   must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for
415	   the given C-flow.  It MUST attach a PTA to that route, and MUST set
416	   the LIR flag in the PTA.  Per [RFC6514], the BFERs that need to
417	   receive that C-flow will respond with (C-S,C-G) Leaf A-D routes.  By
418	   matching the received Leaf A-D routes to the originated S-PMSI A-D
419	   routes, the originator of the S-PMSI A-D route determines the set of
420	   BFERs that need to receive the multicast data flow that is identified
421	   in the NLRI of S-PMSI A-D route.

423	   Suppose an ingress PE has originated an I-PMSI A-D route or a
424	   wildcard S-PMSI A-D route [RFC6625] with a PTA specifying a tunnel
425	   type of BIER.  Now suppose the ingress PE originates an S-PMSI A-D
426	   route specifying (C-S, C-G), where (C-S, C-G) "matches" (according to
427	   the rules of [RFC6625]) the wildcard S-PMSI A-D route or the I-PMSI
428	   A-D route.  Instead of attaching to the (C-S, C-G) route a PTA
429	   specifying BIER, the ingress PE MAY attach a PTA specifying a tunnel
430	   type of "no tunnel information".  This is equivalent to attaching the
431	   same PTA attached to the matching "less specific" route.

433	2.2.2.  Using the LIR-pF Flag

435	   If segmented P-tunnels are not being used, the BFIR can determine the
436	   set of BFERs that need to receive the packets of a given (C-S,C-G)
437	   C-flow as follows.  The BFIR MUST originate a wildcard S-PMSI A-D
438	   route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G)) and the PTA of that
439	   route MUST the following settings:

441	   o  The LIR-pF flag MUST be set;

443	   o  The tunnel type MUST be set to "BIER";

445	   o  A non-zero MPLS label MUST be specified.

447	   Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G)
448	   traffic from the BFIR will respond with a Leaf A-D route.

450	   A BFIR MUST NOT use this method of finding the set of BFERs needing
451	   to receive a given C-flow unless it knows that all those BFERs
452	   support the LIR-pF flag.  How this is known is outside the scope of
453	   this document.

455	   This method greatly reduces the number of S-PMSI A-D routes that a
456	   BFIR needs to originate; it can now originate as few as one such
457	   route (a (C-*,C-*) S-PMSI A-D route), rather than one for each
458	   C-flow.  However, the method does not provide a way for the BFIR to
459	   assign a distinct label to each C-flow.  Therefore it cannot be used
460	   when segmented P-tunnels are in use (see Section 4 for an
461	   explanation).

463	   Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the
464	   LIR-pF flag set, but also originates a more specific wildcard route
465	   that matches a particular (C-S,C-G), the BFERs will not originate
466	   Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set
467	   in the more specific wildcard route.  If the BFIR also originates a
468	   (C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will
469	   not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag
470	   is also set in that route.

472	3.  Use of the PMSI Tunnel Attribute in Leaf A-D routes

474	   Before an egress PE can receive a (C-S,C-G) flow from a given ingress
475	   PE via BIER, the egress PE must have received one of the following
476	   x-PMSI A-D routes from the ingress PE:

478	   o  A (C-S,C-G) S-PMSI A-D route (i.e., an S-PMSI A-D route whose NLRI
479	      encodes (C-S,C-G) and whose PTA specifies a tunnel type of "BIER".
480	      If such a route is found, we refer to it as the "matching x-PMSI
481	      A-D route."

483	   o  A "less specific" x-PMSI A-D route (one specifying (C-*,C-*),
484	      (C-*,C-G), or (C-S,C-G)) whose PTA specifies a tunnel type of
485	      "BIER", and that is the egress PE's "match for reception" of
486	      (C-S,C-G).

488	      The rules for determining which x-PMSI A-D route is the match for
489	      reception are given in [RFC6625].  However, these rules are
490	      modified here to exclude any x-PMSI A-D route that does not have a
491	      PTA, or whose PTA specifies "no tunnel type".

493	      If such a route is found, we refer to it as the "matching x-PMSI
494	      A-D route."

496	   If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE
497	   cannot receive the (C-S,C-G) flow from the ingress PE via BIER until
498	   such time as a matching route is received.

500	   When an egress PE determines that it needs to receive a (C-S,C-G)
501	   flow from a particular ingress PE via BIER, it originates a Leaf A-D
502	   route.  Construction of the Leaf A-D route generally follows the
503	   procedures specified in [RFC6514], or optionally, the procedures
504	   specified in [EXPLICIT_TRACKING].  However, when BIER is being used,
505	   the Leaf A-D route MUST carry a PTA that is constructed as follows:

507	   1.  The tunnel type MUST be set to "BIER".

509	   2.  The MPLS Label field SHOULD be set to zero.

511	   3.  The Sub-domain-id subfield of the Tunnel Identifier field (as
512	       defined in Section 2) MUST be set to the corresponding value from
513	       the PTA of the matching x-PMSI A-D route.

515	   4.  The BFR-id subfield of the Tunnel Identifier field MUST be set to
516	       the BFR-id, in the sub-domain identified by the sub-domain-id
517	       subfield, of the egress PE (BFER).

519	   5.  The BFR-prefix field of the Tunnel Identifier field (as defined
520	       in Section 2) MUST be set to the egress PE's (BFER's) BFR-prefix.

522	       The BFR-prefix need not be the same IP address that is carried in
523	       any other field of the Leaf A-D route.

525	   When an ingress PE receives such a Leaf A-D route, it learns the
526	   BFR-prefix of the egress PE from the PTA.  The ingress PE does not
527	   make any use the value of the PTA's MPLS label field.

529	   Failure to properly construct the PTA cannot always be detected by
530	   the protocol, and will cause improper delivery of the data packets.

532	4.  Data Plane

534	   The MVPN application plays the role of the "multicast flow overlay"
535	   as described in [BIER_ARCH].

537	4.1.  Encapsulation and Transmission

539	   To transmit an MVPN data packet, an ingress PE follows the rules of
540	   [RFC6625] to find the x-PMSI A-D route that is a "match for
541	   transmission" for that packet.  (In applying the rules of [RFC6625],
542	   any S-PMSI A-D route with a PTA specifying "no tunnel information" is
543	   ignored.)  If the matching route has a PTA specifying "BIER", the
544	   (upstream-assigned) MPLS label from that PTA is pushed on the
545	   packet's label stack.  Then the packet is encapsulated in a BIER
546	   header.  That is, the ingress PE functions as a BFIR.  The BIER sub-
547	   domain used for transmitting the packet is specified in the PTA of
548	   the abovementioned x-PMSI A-D route.

550	   In order to create the proper BIER header for a given packet, the
551	   BFIR must know all the BFERs that need to receive that packet.  It
552	   determines this by finding all the Leaf A-D routes that correspond to
553	   the S-PMSI A-D route that is the packet's match for transmission.
554	   There are two different cases to consider:

556	   1.  The S-PMSI A-D route that is the match for transmission carries a
557	       PTA that has the LIR flag set but does not have the LIR-pF flag
558	       set.

560	       In this case, the corresponding Leaf A-D routes are those whose
561	       "route key" field is identical to the NLRI of the S-PMSI A-D
562	       route.

564	   2.  The S-PMSI A-D route that is the match for transmission carries a
565	       PTA that has the LIR-pF flag.

567	       In this case, the corresponding Leaf A-D routes are those whose
568	       "route key" field is derived from the NLRI of the S-PMSI A-D
569	       route according to the procedures described in Section 5.2 of
570	       [EXPLICIT_TRACKING].

572	   The Leaf A-D route from a given BFER will contain a PTA that
573	   specifies the BFER's BFR-prefix.  With this information, the BFIR can
574	   construct the BIER BitString.

576	   However, if the PTA of the Leaf A-D route from a given BFER specifies
577	   a sub-domain other than the one being used for transmitting the
578	   packet, the bit for that BFER cannot be determined, and that BFER
579	   will not receive the packet.

581	   The BIER-encapsulated packet is then forwarded, according to the
582	   procedures of [BIER_ARCH] and [BIER_ENCAPS].  (See especially
583	   Section 4, "Imposing and Processing the BIER Encapsulation", of
584	   [BIER_ENCAPS].)

586	4.2.  Disposition

588	   When a BFER receives an MVPN multicast data packet that has been
589	   BIER-encapsulated, the BIER layer passes the following information to
590	   the multicast flow overlay:

592	   o  The sub-domain-id and the BFIR-id from the BIER header.  (As the
593	      sub-domain-id is inferred from the BIFT-id field of the BIER
594	      header, an implementation might choose to pass the BIFT-id rather
595	      than the sub-domain-id; this is an implementation matter.)

597	   o  The "payload", which is an MPLS packet whose top label is an
598	      upstream-assigned label.  In the dataplane, the BFIR-id and the
599	      sub-domain-id provide the context in which the upstream-assigned
600	      label is interpreted.

602	   By looking up the upstream-assigned label in the appropriate context,
603	   the multicast flow overlay determines whether the BFER is an egress
604	   PE for the packet.

606	   Note that if segmented P-tunnels are in use, a BFER might be a
607	   P-tunnel segmentation border router rather than an egress PE, or a
608	   BFER might be both an egress PE and a P-tunnel segmentation border
609	   router.  Depending upon the role of the BFER for given packet, it may
610	   need to follow the procedures of Section 4.2.1, the procedures of
611	   Section 4.2.2, or both.

613	4.2.1.  At a BFER that is an Egress PE

615	   From looking up the packet's upstream-assigned label in the context
616	   of the packet's BFIR-prefix, the egress PE determines the egress VRF
617	   for the packet.  From the IP header of the payload, the multicast
618	   states of the VRF, the upstream-assigned label, and the BFR-prefix,
619	   the egress PE can determine whether the packet needs to be forwarded
620	   out one or more VRF interfaces.

622	4.2.2.  At a BFER that is a P-tunnel Segmentation Boundary

624	   When segmented P-tunnels are being used, a BFER that receives a BIER-
625	   encapsulated MVPN multicast data packet may need to be forwarded on
626	   its next P-tunnel segment.  The choice of the next P-tunnel segment
627	   for the packet depends upon the C-flow to which the packet belongs.
628	   As long as the BFIR has assigned the MPLS label according to the
629	   constraints specified in Section 2.1, the BFIR will have assigned
630	   distinct upstream-assigned MPLS labels to distinct C-flows.  The BFER
631	   can thus select the proper "next P-tunnel segment" for a given packet
632	   simply by looking up the upstream-assigned label that immediately
633	   follows the BIER header.

635	5.  Contributor Addresses

637	   Below is a list of other contributing authors in alphabetical order:

639	   IJsbrand Wijnands
640	   Cisco Systems, Inc.
641	   De Kleetlaan 6a
642	   Diegem  1831
643	   Belgium

645	   Email: ice@cisco.com

647	6.  Acknowledgments

649	   The authors wish to thank Jeffrey Zhang for his ideas and
650	   contributions to this work.  We also thank Stig Venaas for his review
651	   and comments.

653	7.  IANA Considerations

655	   IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast
656	   Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.

658	8.  Security Considerations

660	   The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513]
661	   and [RFC6514] are applicable.

663	9.  References

665	9.1.  Normative References

667	   [BIER_ARCH]
668	              Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,
669	              and S. Aldrin, "Multicast using Bit Index Explicit
670	              Replication", internet-draft draft-ietf-bier-architecture-
671	              07, June 2017.

673	   [BIER_ENCAPS]
674	              Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and
675	              S. Aldrin, "Encapsulation for Bit Index Explicit
676	              Replication in MPLS Networks", internet-draft draft-ietf-
677	              bier-mpls-encapsulation-07.txt, June 2017.

679	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
680	              Requirement Levels", BCP 14, RFC 2119,
681	              DOI 10.17487/RFC2119, March 1997,
682	              <https://www.rfc-editor.org/info/rfc2119>.

684	   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
685	              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
686	              2006, <https://www.rfc-editor.org/info/rfc4364>.

688	   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
689	              Label Assignment and Context-Specific Label Space",
690	              RFC 5331, DOI 10.17487/RFC5331, August 2008,
691	              <https://www.rfc-editor.org/info/rfc5331>.

693	   [RFC6513]  Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
694	              BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
695	              2012, <https://www.rfc-editor.org/info/rfc6513>.

697	   [RFC6514]  Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
698	              Encodings and Procedures for Multicast in MPLS/BGP IP
699	              VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
700	              <https://www.rfc-editor.org/info/rfc6514>.

702	   [RFC6625]  Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
703	              Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
704	              RFC 6625, DOI 10.17487/RFC6625, May 2012,
705	              <https://www.rfc-editor.org/info/rfc6625>.

707	9.2.  Informative References

709	   [EXPLICIT_TRACKING]
710	              Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
711	              "Explicit Tracking with Wild Card Routes in Multicast
712	              VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02,
713	              June 2017.

715	   [RFC7524]  Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
716	              Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
717	              Point-to-Multipoint (P2MP) Segmented Label Switched Paths
718	              (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
719	              <https://www.rfc-editor.org/info/rfc7524>.

721	   [RFC7900]  Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
722	              and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
723	              RFC 7900, DOI 10.17487/RFC7900, June 2016,
724	              <https://www.rfc-editor.org/info/rfc7900>.

726	Authors' Addresses

728	   Eric C. Rosen (editor)
729	   Juniper Networks, Inc.
730	   10 Technology Park Drive
731	   Westford, Massachusetts  01886
732	   United States

734	   Email: erosen@juniper.net

736	   Mahesh Sivakumar
737	   Cisco Systems, Inc.
738	   510 McCarthy Blvd
739	   Milpitas, California  95035
740	   United States

742	   Email: masivaku@cisco.com

744	   Sam K Aldrin
745	   Google, Inc.
746	   1600 Amphitheatre Parkway
747	   Mountain View, California
748	   United States

750	   Email: aldrin.ietf@gmail.com
751	   Andrew Dolganow
752	   Nokia
753	   438B Alexandra Rd #08-07/10
754	   Alexandra Technopark
755	   Singapore  119968

757	   Email: andrew.dolganow@nokia.com

759	   Tony Przygienda
760	   Juniper Networks, Inc.
761	   1137 Innovation Way
762	   San Jose, California  94089
763	   United States

765	   Email: prz@juniper.net




















Back