Skip to main content

Shepherd writeup
draft-ietf-bier-mldp-signaling-over-bier

´╗┐Shepherds Review of:
https://datatracker.ietf.org/doc/draft-ietf-bier-mldp-signaling-over-bier/03/

(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? [This is a
Standards track draft.  It is indicated in the title page.  This is the correct
type of RFC for the content as it describes procedures needed to signal mLDP
tunnels across a BIER doman and defines two new Interface ID sub-TLVs for BIER.]

(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: [This document
describes a procedure needed for mLDP tunnels to be signaled over and stitched
through a BIER core, allowing LDP routers to run traditional mLDP services
through a BIER core.  This is especially the case in a pre-existing mLDP
network deploying BIER in a segment of the network.]

Working Group Summary:
Was there anything in the WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where the
consensus was particularly rough? [There was good discussion around the draft
during the WG meetings.  There have been no controversial views or discussions
(both during the WG meetings and on the mailing list.]

Document Quality:
Are there existing implementations of the protocol? Have a significant number
of vendors indicated their plan to implement the specification? Are there any
reviewers that merit special mention as having done a thorough review, e.g.,
one that resulted in important changes or a conclusion that the document had no
substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other
expert review, what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted? [The document does not introduce a
new protocol but rather describes procedures.  The authors acknowledge Jingrong
Xie for his comments, review and help with the draft. No reviews carried out by
MID Doctor, YANG Doctor, Media Type.]

Personnel:
Who is the Document Shepherd?
[Nabeel Cocker]
Who is the Responsible Area Director?
[Andrew Alston]
(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG. [
Both versions of the draft have been reviewed and comments provided to the
authors (Primarily nits).  These have been incorporated into Draft version 03
by the authors]

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed? [No concerns.  The document has had a
fair bit of discussion]

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place. [NO] (6)
Describe any specific concerns or issues that the Document Shepherd has 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.

[ IANA considerations: new interface_ID Type of BIER (BIER Interface TLV) ]

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why? [  Yes   ]

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

[ Not yet    ]
(9) 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? [ It is well supported and has
authors from multiple vendors as well as customers/service providers ]

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.) [  NO   ]

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough. [  Non
identified.  Review attached below this write up   ]

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, YANG Doctor, media type, and URI type reviews. [  Not
required  ]

(13) Have all references within this document been identified as either
normative or informative? [  YES  ] (14) 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 plan for their
completion? [  There are two normative references that are in draft format:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-aggregation-label/14
is advanced and not in an unclear state
 https://datatracker.ietf.org/doc/html/draft-ietf-bier-pim-signaling-12 is also
 fairly advanced ]

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure. [  NO ]

(16) 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   ]

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 8126) [  IANA considerations: new interface_ID Type of BIER (BIER Interface
TLV).  No new IANA registry but rather an existing registry.   In particular
IANA maintains a registry of Interface ID Types for use in GMPLS in the
registry "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Parameters" and sub-registry "Interface_ID Types".  ] (18) List any new IANA
registries that require Expert Review for future allocations. Provide any
public guidance that the IESG would find useful in selecting the IANA Experts
for these new registries. [  NONE  ] (19) Describe reviews and automated checks
performed by the Document Shepherd to validate sections of the document written
in a formal language, such as XML code, BNF rules, MIB definitions, YANG
modules, etc. [  NONE   ] (20) If the document contains a YANG module, has the
module been checked with any of the recommended validation tools
(https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module comply
with the Network Management Datastore Architecture (NMDA) as specified in
RFC8342? [  No YANG module ]

idnits 2.17.1

draft-ietf-bier-mldp-signaling-over-bier-03.txt:

  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:
  ----------------------------------------------------------------------------

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Unused Reference: 'RFC8401' is defined on line 375, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8444' is defined on line 378, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC8556' is defined on line 382, but no explicit
     reference was found in the text

     Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 0 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.
--------------------------------------------------------------------------------

2        Network Working Group                                    H. Bidgoli,
Ed. 3        Internet-Draft                                               J.
Kotalwar 4        Intended status: Standards Track                             
     Nokia 5        Expires: 23 April 2024                                     
 I. Wijnands 6                                                                 
     M. Mishra 7                                                               
    Cisco System 8                                                             
          Z. Zhang 9                                                           
    Juniper Networks 10                                                        
              E. Leyton 11                                                     
                   Verizon 12                                                  
              21 October 2023

14                           M-LDP Signaling Through BIER Core
15                      draft-ietf-bier-mldp-signaling-over-bier-03

17        Abstract

19           Consider an end-to-end Multipoint LDP (mLDP) network, where it is
20           desirable to deploy BIER in a segment of this network.  It might be
21           desirable to deploy BIER with minimal disruption to the mLDP
network 22           or a redesign of the network.

24           This document describes a procedure needed for mLDP tunnels to be
25           signaled over and stitched through a BIER core, allowing LDP
routers 26           to run traditional mLDP services through a BIER core.

28        Status of This Memo

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

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

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

43           This Internet-Draft will expire on 23 April 2024.

45        Copyright Notice

47           Copyright (c) 2023 IETF Trust and the persons identified as the
48           document authors.  All rights reserved.

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

59        Table of Contents

61           1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . 
 2 62           2.  Conventions used in this document . . . . . . . . . . . . .
.   2 63             2.1.  Definitions . . . . . . . . . . . . . . . . . . . .
. . .   3 64           3.  mLDP Signaling Through BIER domain  . . . . . . . .
. . . . .   4 65             3.1.  Ingress BBR procedure . . . . . . . . . . .
. . . . . . .   5 66               3.1.1.  Automatic tLDP session Creation . .
. . . . . . . . .   5 67               3.1.2.  ECMP Method on IBBR . . . . . .
. . . . . . . . . . .   5 68             3.2.  Egress BBR procedure  . . . . .
. . . . . . . . . . . . .   5 69               3.2.1.  IBBR procedure for
arriving upstream assigned 70                       label . . . . . . . . . . .
. . . . . . . . . . . . .   6 71               3.2.2.  BIER Interface ID
SUB-TLVs  . . . . . . . . . . . . .   6 72           4.  Datapath Forwarding .
. . . . . . . . . . . . . . . . . . . .   7 73             4.1.  Datapath
traffic flow . . . . . . . . . . . . . . . . . .   7 74           5.  Recursive
FEC . . . . . . . . . . . . . . . . . . . . . . . .   7 75           6.  IANA
Consideration  . . . . . . . . . . . . . . . . . . . . .   7 76           7. 
Security Considerations . . . . . . . . . . . . . . . . . . .   8 77          
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8 78       
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8 79    
        9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8 80 
           9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
81           Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 
 9

83        1.  Introduction

85           Some operators that are using mLDP P2MP LSPs for their multicast
86           transport would like to deploy BIER technology in some segments of
87           their network.  This draft explains a method to signal mLDP
services 88           through a BIER domain, with minimal disruption and
operational impact 89           to the mLDP domain.

91        2.  Conventions used in this document

93           The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
94           "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this 95           document are to be interpreted as described in [RFC2119].

97        2.1.  Definitions

99           Some of the terminology specified in [RFC8279]is replicated here
and 100           extended by necessary definitions:

102           BIER:

104           Bit Index Explicit Replication, The overall architecture of
105           forwarding multicast using a Bit Position.

107           BFR:

109           Bit Forwarding Router, A router that participates in Bit Index
110           Multipoint Forwarding.  A BFR is identified by a unique BFR
prefix in 111           a BIER domain.

113           BFIR:

115           Bit-Forwarding Ingress Router, The ingress border router that
inserts 116           the Bit Map into the packet.  Each BFIR must have a valid
BFR-id 117           assigned.  BFIR is a term used for data plane packet
forwarding.

119           BFER:

121           Bit-Forwarding Egress Router, A router that participates in Bit
Index 122           Forwarding as leaf.  Each BFER must have a valid BFR-id
assigned. 123           BFER is a term used for data plane packet forwarding.

125           BBR:

127           BIER Boundary router.  The router between the LDP domain and BIER
128           domain.

130           IBBR:

132           Ingress BIER Boundary Router.  The ingress router from a signaling
133           point of view.  It maintains mLDP adjacency toward the LDP domain
and 134           determines if the Multipoint LDP FEC needs to be signaled
across the 135           BIER domain via Targeted LDP.

137           EBBR:

139           Egress BIER Boundary Router.  The egress router in a BIER domain
from 140           signaling point of view.  It terminates the targeted LDP
signaling 141           through the BIER domain.  It also keeps track of all
IBBRs that are 142           part of this P2MP tree

144           BIFT:

146           Bit Index Forwarding Table.

148           BIER sub-domain:

150           A further distinction within a BIER domain identified by its
unique 151           sub-domain identifier.  A BIER sub-domain can support
multiple 152           BitString Lengths.

154           BFR-id:

156           An optional, unique identifier for a BFR within a BIER sub-domain,
157           all BFERs and BFIRs need to be assigned a BFR-id.

159           ILM:

161           MPLS Incoming Label Map.

163        3.  mLDP Signaling Through BIER domain

165                                BBR                   BBR
166                 |---LDP Domain--|-----BIER domain-----|---LDP domain--|
167            S--( A )-----------( B ) ---- ( C ) ---- ( D )-----------( E )--h

169                               EBBR                  IBBR
170            Sig  <----MLDP------|<----targeted LDP----|<---MLDP------
171            (new)

173                              BFIR                  BFER
174                 ------------->|--------BIER-------->|-------------> 
Datapatah 175                                                                  
    (new)

177                               Figure 1: BIER boundary router

179           As per figure 1, point-to-multipoint and multipoint-to-multipoint
180           LSPs established via mLDP [RFC6388] can be signaled through a bier
181           domain via Targeted LDP sessions.  This procedure is explained in
182           [RFC7060] (Using LDP Multipoint Extension on Targeted LDP
Sessions).

184           This document provides details and defines some needed procedures.

186           .

188        3.1.  Ingress BBR procedure

190           In Figure 1, the Ingress BBR (IBBR) is connected to the mLDP
domain 191           on downstream and a BIER domain on the upstream.  To
connect the LDP 192           domains via BIER domain, IBBR needs to establish
a targeted LDP 193           session with EBBR closest to the root of the P2MP
or MP2MP LSP.  To 194           do so IBBR will follow procedures in [RFC7060]
in particular section 195           6 "Targeted mLDP with Multicast Tunneling".

197           The Target LDP session can be established manually via
configuration 198           or via automated mechanism.

200        3.1.1.  Automatic tLDP session Creation

202           tLDP sessions can be signaled automatically from every IBBR to the
203           appropriate EBBR.  When mLDP FEC arrives at the IBBR from LDP
domain, 204           IBBR can automatically start a tLDP session to the EBBR
closest to 205           the root node.  Both IBBR and EBBR should be in
auto-discovery mode 206           and react to the arriving tLDP signaling
packets (i.e. targeted 207           hellos, keep-alives etc...) to establish
the session automatically.

209           The root node address in the mLDP FEC can be used to find the
EBBR. 210           To identify the EBBR, the same procedures as [RFC7060]
section 2.1 211           can be used or the procedures as explained in the 212
          [draft-ietf-bier-pim-signaling] appendix A.

214        3.1.2.  ECMP Method on IBBR

216           If the IBBR finds multiple equal cost EBBRs on the path to the
root, 217           it can use a vendor specific algorithm to choose between
the EBBRs. 218           These algorithms are beyond the scope of this draft. 
As an example 219           the IBBR can use the lowest EBBR IP address to
establish its mLDP 220           signaling to.

222        3.2.  Egress BBR procedure

224           The Egress BBR (EBBR) is connected to the upstream mLDP domain. 
The 225           EBBR should accept the tLDP session generated form the IBBR. 
It 226           should assign a unique "upstream assigned label" for each
arriving 227           FEC generated by the IBBRs.

229           The EBBR should follow the [RFC7060] procedures with the following
230           modifications:

232           *  The label assigned by the EBBR cannot be Implicit Null.  This
is 233              to ensure that the identity of each p2mp and/or mp2mp
tunnel in 234              the BIER domain is uniquely distinguished.

236           *  The label can be assigned from a domain-wide Common Block (DCB)
237              [draft-ietf-bess-mvpn-evpn-aggregation-label]

239           *  The Interface ID TLV, as per [RFC6389] should includes a new
BIER 240              sub-tlv as tunnel identifier.

242           The EBBR will also generate a new label and FEC toward the root in
243           the LDP domain.  The EBBR Should stitch this generated label with
the 244           "upstream assigned label" to complete the P2MP or MP2MP LSP.

246           With the same token the EBBR should track all the arriving FECs
and 247           the IBBRs that are generating these FECs.  The EBBR will use
this 248           information to build the bier header for each set of common
FEC 249           arriving from the IBBRs.

251        3.2.1.  IBBR procedure for arriving upstream assigned label

253           Upon receiving the "upstream assigned label", the IBBR should
create 254           its own stitching instruction between the "upstream
assigned label" 255           and the downstream signaled label.

257        3.2.2.  BIER Interface ID SUB-TLVs

259           As per [RFC6389] when LDP is used for upstream label
assignment,the 260           Interface ID TLV is used for signaling the Tunnel
Identifier and it 261           carries sub-TLVs.  This document defines two
new Interface ID sub- 262           TLVs for BIER.

264           Below is the Interface ID BIER sub-TLV for IPv4 BIER prefix:

266                0                   1                   2                   3
267                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 268              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269          
    |    Type (TBD1)                |               15              | 270      
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271  
            |                      IBBR Prefix IPv4                         |
272              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273          
    |  sub-domain-id|      BFR-id                   | 274              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

276           Below is the Interface ID BIER sub-TLV for IPv6 BIER prefix:

278                0                   1                   2                   3
279                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 280              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281          
    |    Type (TBD2)                |               23              | 282      
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283  
            |                      IBBR Prefix IPv6                         |
284               ~                         ........                           
  ~ 285              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286          
    |  sub-domain-id|      BFR-id                   | 287              
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

289        4.  Datapath Forwarding

291        4.1.  Datapath traffic flow

293           On the BFIR when the MPLS label for P2MP/MP2MP LSP arrives from
294           upstream, a lookup in the ILM table is done and the label is
swapped 295           with the tLDP upstream assigned label.  The BFIR will
note all the 296           BFERs that are interested in specific P2MP/MP2MP LSP
(as per section 297           3.2).  The BFIR will put the corresponding BIER
header with the bit 298           index set for all the IBBRs interested in
this stream.  The BFIR will 299           set the BIERHeader.Proto = MPLS and
will forward the BIER packet into 300           the BIER domain.

302           In the BIER domain, normal BIER forwarding procedure will be
done, as 303           per [RFC8279]

305           The BFERs will receive the BIER packet and will look at the
protocol 306           field of BIER header, indicating MPLS protocol.  The
BFER will remove 307           the BIER header and will do a lookup in the ILM
table for the 308           upstream assigned label and perform its
corresponding action.

310           It should be noted that these procedures are also valid if BFIR is
311           the ILER and/or BFER is the ELER as per [RFC7060]

313        5.  Recursive FEC

315           The procedures above are also valid for mLDP recursive FEC.  The
root 316           used to determine the EBBR is the outer root of the FEC. 
The entire 317           recursive FEC needs to be preserved when it is
forwarded via tLDP and 318           the label request.

320        6.  IANA Consideration

322           IANA maintains a registry of Interface ID Types for use in GMPLS
in 323           the registry "Generalized Multi-Protocol Label Switching
(GMPLS) 324           Signaling Parameters" and sub-registry "Interface_ID
Types" 325           This document defines and requests two new Interface_ID
Type for BIER 326           from the Interface_ID Types space,

328           *  BIER IPv4 prefix TLV (Value TBD)

330           *  BIER IPv6 prefix TLV (Value TBD)

332        7.  Security Considerations

334           While in the BIER domain the security considerations of [RFC8279]
are 335           relevant to this document.

337           The implementation should also take into account the security
338           recommendations of [RFC6389].

340        8.  Acknowledgments

342           Authors would like to acknowledge Jingrong Xie and Nabeel Cocker
for 343           his comments and help on this draft.

345        9.  References

347        9.1.  Normative References

349           [draft-ietf-bess-mvpn-evpn-aggregation-label]
350                      "Z. Zhang, E. Rosen, W. Lin, Z. Li, I. Wijnands, "MVPN/
351                      EVPN Tunnel Aggregation with Common Labels"", 27 April
352                      2018.

354           [draft-ietf-bier-pim-signaling]
355                      "H, Bidgoli, F. Xu, J. Kotalwar, I. Wijnands, M.
Mishra, 356                      Z.  Zhang", 29 July 2020.

358           [RFC2119]  "S. Bradner, "Key words for use in RFCs to Indicate
359                      Requirement Levels"", March 1997.

361           [RFC6388]  "IJ. Wijnands, I. Minei, K. Kompella, B.Thomas "Label
362                      Distribution Protocol Extensions for
Point-to-Multipoint 363                      and Multipoint-to-Multipoint LSP"".

365           [RFC6389]  "R Aggarwal, JL. Le Roux, "MPLS Upstream Label
Assignment 366                      for LDP"", November 2011.

368           [RFC7060]  "M. Napierala, E. Rosen, I. Wijnands", November 2013.

370           [RFC8279]  "I. Wijnands, E. Rosen, A. ADolganow, T. Prygienda, S.
371                      Aldrin", November 2017.

373        9.2.  Informative References

375           [RFC8401]  "Ginsberg, L., Przygienda, T., Aldrin, S., and Z.
Zhang, 376                      "BIER Support via ISIS"", June 2018.

378           [RFC8444]  "Psenak, P., Kumar, N., Wijnands, IJ., Dolganow, A.,
379                      Przygienda, T., Zhang, Z., and S. Aldrin, "OSPF
Extensions 380                      for Bit Index Explicit Replication"", June
2018.

382           [RFC8556]  "Rosen, E., Ed., Sivakumar, M., Wijnands, IJ., Aldrin,
383                      S.,Dolganow, A., and T. Przygienda, "Multicast VPN
Using 384                      Index Explicit Replication (BIER)", April 2018.

386        Authors' Addresses

388           Hooman Bidgoli (editor)
389           Nokia
390           Ottawa
391           Canada
392           Email: hooman.bidgoli@nokia.com

394           Jayant Kotalwar
395           Nokia
396           Montain View,
397           United States of America
398           Email: jayant.kotalwar@nokia.com

400           IJsbrand Wijnands
401           Cisco System
402           Diegem
403           Belgium
404           Email: ice@cisco.com

406           Mankamana Mishra
407           Cisco System
408           Milpitas,
409           United States of America
410           Email: mankamis@cisco.com

412           Zhaohui Zhang
413           Juniper Networks
414           Boston,
415           United States of America
416           Email: zzhang@juniper.com
417           Eddie Leyton
418           Verizon
419           Email: Edward.leyton@verizonwireless.com
Back