Multicast VPN Using Bit Index Explicit Replication (BIER)
draft-ietf-bier-mvpn-11

[Ballot comment]
IMPORTANT:
This document really needs to minimally acknowledge in the security considerations that it is using "VPN" in 4364 sense and not in the sense that it provides actual privacy against network attackers in the Internet Threat Model. It may be hidden somewhere in the references, but I think this document ought to state it explicitly. I'm balloting No-Objection rather than DISCUSS because I think this is easily addressed and trust the ADs to handle it.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-bier-mvpn-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the temporary registration:

Value: 0x0B
Meaning: BIER

will be made permanent and have its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-22):

From: The IESG
To: IETF-Announce
CC: bier@ietf.org, nabeel.cocker@nokia.com, Nabeel Cocker , draft-ietf-bier-mvpn@ietf.org, akatlas@gmail.com, bier-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast VPN Using BIER) to Proposed Standard


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'Multicast VPN Using BIER'
  as Proposed Standard

This document was previously intended to be published as Experimental,
but now that the WG is rechartering to be Standards Track, it is in line with the
proposed new charter to publish this document as Proposed Standard.  Please
let the IESG know if the status difference is a concern.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-mvpn/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bier-mvpn/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8296: Encapsulation for Bit Index Explicit Replication (BIER) in MPLS and Non-MPLS Networks (Experimental - IETF stream)
    rfc8279: Multicast Using Bit Index Explicit Replication (BIER) (Experimental - IETF stream)

Both of these normative references are part of a Status Update to promote them to
Proposed Standard at the same telechat.

[Ballot comment]
-1, last paragraph: There are a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.

[Ballot comment]
One of the most readable documents on MVPN that I can remember reading. Thanks for that.

When reading Section 2.2, I found myself wondering why you'd choose the optional explicit tracking mechanism, but found this text

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

in Section 2.2.2. I wonder if it's worth moving that text to the end of Section 2.2, so the reader goes into 2.2.1 and 2.2.2 understanding the advantage of the optional mechanism?

[Ballot comment]
[I am balloting No Objection, and not DISCUSS [1], because I think this comment is very easy to address.]

The reference to draft-ietf-bess-mvpn-expl-track (EXPLICIT_TRACKING) should be Normative because of the use of the LIR-pF flag in this document.

[1] https://www.ietf.org/iesg/statement/discuss-criteria.html#stand-disc

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-bier-mvpn-09. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at:

https://www.iana.org/assignments/bgp-parameters/

the following temporary registration:

Value: 0x0B
Meaning: BIER (TEMPORARY - registered 2017-06-29, expires 2018-06-29)

will be made permanent and its reference changed to [ RFC-to-be ].

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-01-31):

From: The IESG
To: IETF-Announce
CC: bier@ietf.org, nabeel.cocker@nokia.com, Nabeel Cocker , draft-ietf-bier-mvpn@ietf.org, akatlas@gmail.com, bier-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Multicast VPN Using BIER) to Experimental RFC


The IESG has received a request from the Bit Indexed Explicit Replication WG
(bier) to consider the following document: - 'Multicast VPN Using BIER'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-01-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bier-mvpn/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bier-mvpn/ballot/


No IPR declarations have been submitted directly on this I-D.

(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               .

684   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
685               Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
686               2006, .

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               .

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, .

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               .

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               .

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               .

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               .

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