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

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

Request for posting confirmation emailed to previous authors: Eddie Leyton , Hooman Bidgoli , IJsbrand Wijnands , Jayant Kotalwar , Mankamana Mishra , Zhaohui Zhang , bier-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Eddie Leyton , Hooman Bidgoli , IJsbrand Wijnands , Jayant Kotalwar , Mankamana Mishra , Zhaohui Zhang , bier-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Eddie Leyton , Hooman Bidgoli , IJsbrand Wijnands , Jayant Kotalwar , Mankamana Mishra , Zhaohui Zhang , bier-chairs@ietf.org