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