idnits 2.17.1 draft-dawra-bess-srv6-services-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1873 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD1' is mentioned on line 885, but not defined == Missing Reference: 'TBD2' is mentioned on line 886, but not defined == Unused Reference: 'I-D.filsfils-spring-segment-routing-policy' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-segment-routing-header' is defined on line 940, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing' is defined on line 1005, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-21) exists of draft-ietf-bess-evpn-igmp-mld-proxy-02 == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-05 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 -- Obsolete informational reference (is this intentional?): RFC 5549 (Obsoleted by RFC 8950) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group 3 Internet-Draft 4 Intended status: Standards Track G. Dawra, Ed. 5 Expires: September 12, 2019 LinkedIn 6 C. Filsfils 7 D. Dukes 8 P. Brissette 9 S. Sethuram 10 P. Camarilo 11 Cisco Systems 12 J. Leddy 13 Comcast 14 D. Voyer 15 D. Bernier 16 Bell Canada 17 D. Steinberg 18 Steinberg Consulting 19 R. Raszuk 20 Bloomberg LP 21 B. Decraene 22 Orange 23 S. Matsushima 24 SoftBank 25 S. Zhuang 26 Huawei Technologies 27 March 11, 2019 29 SRv6 BGP based Overlay services 30 draft-dawra-bess-srv6-services-00 32 Abstract 34 This draft defines procedures and messages for SRv6-based BGP 35 services including L3VPN, EVPN and Internet services. It builds on 36 RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 37 "BGP MPLS-Based Ethernet VPN" and provides a migration path from 38 MPLS-based VPNs to SRv6 based VPNs. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in RFC8174 [RFC8174]. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on September 12, 2019. 63 Copyright Notice 65 Copyright (c) 2019 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. SRv6 Services TLVs . . . . . . . . . . . . . . . . . . . . . 4 82 2.1. SRv6 Service Sub-TLVs . . . . . . . . . . . . . . . . . . 5 83 2.1.1. SRv6 SID Information Sub-TLV . . . . . . . . . . . . 6 84 2.1.2. SRv6 Service Data Sub-Sub-TLVs . . . . . . . . . . . 7 85 3. BGP based L3 service over SRv6 . . . . . . . . . . . . . . . 7 86 3.1. IPv4 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 8 87 3.2. IPv6 VPN Over SRv6 Core . . . . . . . . . . . . . . . . . 9 88 3.3. Global IPv4 over SRv6 Core . . . . . . . . . . . . . . . 9 89 3.4. Global IPv6 over SRv6 Core . . . . . . . . . . . . . . . 9 90 4. BGP based Ethernet VPN (EVPN) over SRv6 . . . . . . . . . . . 10 91 4.1. Ethernet Auto-discovery route over SRv6 Core . . . . . . 11 92 4.1.1. Per-ES A-D route . . . . . . . . . . . . . . . . . . 11 93 4.1.2. Per-EVI A-D route . . . . . . . . . . . . . . . . . . 12 95 4.2. MAC/IP Advertisement route over SRv6 Core . . . . . . . . 12 96 4.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core . . 13 97 4.4. Ethernet Segment route over SRv6 Core . . . . . . . . . . 15 98 4.5. IP prefix route over SRv6 Core . . . . . . . . . . . . . 15 99 4.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6 100 core . . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 5. Migration from MPLS based Segment Routing to SRv6 Segment 102 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 103 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 104 7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 18 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 106 8.1. BGP Prefix-SID TLV Types registry . . . . . . . . . . . . 19 107 8.2. SRv6 Service Sub-TLV Types registry . . . . . . . . . . . 20 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 109 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 112 11.2. Informative References . . . . . . . . . . . . . . . . . 21 113 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 116 1. Introduction 118 SRv6 refers to Segment Routing instantiated on the IPv6 dataplane [I- 119 D.filsfils-spring-srv6-network-programming][I-D.ietf-6man-segment-rou 120 ting-header]. 122 SRv6 based BGP services refers to the L3 and L2 overlay services with 123 BGP as control plane and SRv6 as dataplane. 125 SRv6 SID refers to a SRv6 Segment Identifier as defined in 126 [I-D.filsfils-spring-srv6-network-programming]. 128 SRv6 Service SID refers to an SRv6 SID that MAY be associated with 129 one of the service specific behavior on the advertising Provider 130 Edge(PE) router, such as (but not limited to), in the case of L3VPN 131 service, END.DT (Table lookup in a VRF) or END.DX (crossconnect to a 132 nexthop) functions as defined in 133 [I-D.filsfils-spring-srv6-network-programming]. 135 To provide SRv6 service with best-effort connectivity, the egress PE 136 signals an SRv6 Service SID with the BGP overlay service route. The 137 ingress PE encapsulates the payload in an outer IPv6 header where the 138 destination address is the SRv6 Service SID provided by the egress 139 PE. The underlay between the PEs only need to support plain IPv6 140 forwarding [RFC2460]. 142 To provide SRv6 service in conjunction with an underlay SLA from the 143 ingress PE to the egress PE, the egress PE colors the overlay service 144 route with a Color extended 145 community[I-D.ietf-idr-segment-routing-te-policy]. The ingress PE 146 encapsulates the payload packet in an outer IPv6 header with an SRH 147 that contains the SR policy associated with the related SLA followed 148 by the SRv6 Service SID associated with the route. The underlay 149 nodes whose SRv6 SID's are part of the SRH must support SRv6 data 150 plane. 152 BGP is used to advertise the reachability of prefixes of a particular 153 service from an egress PE to ingress PE nodes. 155 This document describes how existing BGP messages between PEs may 156 carry SRv6 Service SIDs as a means to interconnect PEs and form VPNs. 158 2. SRv6 Services TLVs 160 This document extends the BGP Prefix-SID attribute 161 [I-D.ietf-idr-bgp-prefix-sid] to carry SRv6 SIDs and associated 162 information. 164 The SRv6 Service TLVs are defined as two new TLVs of the BGP Prefix- 165 SID Attribute to achieve signaling of SRv6 SIDs for L3 and L2 166 services. 168 o SRv6 L3 Service TLV: This TLV encodes Service SID information for 169 SRv6 based L3 services. It corresponds to the equivalent 170 functionality provided by an MPLS Label when received with a Layer 171 3 service route. Some functions which may be encoded, but not 172 limited to, are End.DX4, End.DT4, End.DX6, End.DT6, etc. 174 o SRv6 L2 Service TLV: This TLV encodes Service SID information for 175 SRv6 based L2 services. It corresponds to the equivalent 176 functionality provided by an MPLS Label1 for EVPN Route-Types as 177 defined in[RFC7432]. Some functions which may be encoded, but not 178 limited to, are End.DX2, End.DX2V, End.DT2U, End.DT2M etc. 180 BGP Prefix-SID Attribute [I-D.ietf-idr-bgp-prefix-sid] is referred to 181 as BGP SID Attribute in the rest of the document. 183 When an egress PE is capable of SRv6 data-plane, it SHOULD signal one 184 or more SRv6 Service SIDs enclosed in SRv6 Service TLV(s) within the 185 BGP SID Attribute attached to MP-BGP NLRIs defined in 186 [RFC4760][RFC4659][RFC5549][RFC7432][RFC4364]. 188 The following depicts the SRv6 Service TLVs encoded in the BGP SID 189 attribute: 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | TLV Type | TLV Length | RESERVED | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 // SRv6 Service Sub-TLVs // 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 o TLV Type (1 octet): This field is assigned values from the IANA 200 registry "BGP Prefix-SID TLV Types". It is set to [TBD1] (to be 201 assigned by IANA) for SRv6 L3 Service TLV. It is set to [TBD2] 202 (to be assigned by IANA) for SRv6 L2 Service TLV. 204 o TLV Length (2 octets): Specifies the total length of the TLV 205 Value. 207 o RESERVED (1 octet): This field is reserved; it SHOULD be set to 0 208 by the sender and MUST be ignored by the receiver. 210 o SRv6 Service Sub-TLVs (variable): This field contains SRv6 Service 211 related information and is encoded as an unordered list of Sub- 212 TLVs whose format is described below. 214 2.1. SRv6 Service Sub-TLVs 216 The format of a single SRv6 Service Sub-TLV is depicted below: 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | SRv6 Service | SRv6 Service | SRv6 Service // 222 | Sub-TLV | Sub-TLV | Sub-TL // 223 | Type | Length | value // 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 o SRv6 Service Sub-TLV Type (1 octet): Identifies the type of SRv6 227 service information. It is assigned values from the IANA Registry 228 "SRv6 Service Sub-TLV Types". 230 o SRv6 Service Sub-TLV Length (2 octets): Specifies the total length 231 of the Sub-TLV Value field. 233 o SRv6 Service Sub-TLV Value (variable): Contains data specific to 234 the Sub-TLV Type. In addition to fixed length data, this may also 235 optionally contain other properties of the SRv6 Service encoded as 236 a set of SRv6 Service Data Sub-sub-TLVs whose format is described 237 in another sub-section below. 239 2.1.1. SRv6 SID Information Sub-TLV 241 SRv6 Service Sub-TLV Type 1 is assigned for SRv6 SID Information Sub- 242 TLV. This Sub-TLV contains a single SRv6 SID along with its 243 properties. Its encoding is depicted below: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | SRv6 Service | SRv6 Service | | 249 | Sub-TLV | Sub-TLV | | 250 | Type=1 | Length | RESERVED2 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 // SRv6 SID Value (16 bytes) // 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | SRv6 SID Flags| SRv6 Endpoint Behavior | RESERVED3 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 // SRv6 Service Data Sub-Sub-TLVs // 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 o SRv6 Service Sub-TLV Type (1 octet): This field is set to 1 to 260 represent SRv6 SID Informaton Sub-TLV. 262 o SRv6 Service Sub-TLV Length (2 octets): This field contains the 263 total length of the Value field of the Sub-TLV. 265 o RESERVED2 (1 octet): SHOULD be set to 0 by the sender and MUST be 266 ignored by the receiver. 268 o SRv6 SID Value (16 octets): Encodes an SRv6 SID as defined in 269 [I-D.filsfils-spring-srv6-network-programming] 271 o SRv6 SID Flags (1 octet): Encodes SRv6 SID Flags - none are 272 currently defined. 274 o SRv6 Endpoint Behavior (2 octets): Encodes SRv6 Endpoint behavior 275 defined in [I-D.filsfils-spring-srv6-network-programming]. This 276 field MUST be set to the Reserved value 0xFFFF. 278 o RESERVED3 (1 octet): SHOULD be set to 0 by the sender and MUST be 279 ignored by the receiver. 281 o SRv6 Service Data Sub-TLV Value (variable): This field contains 282 optional properties of the SRv6 SID. It is encoded as a set of 283 SRv6 Service Data Sub-Sub-TLVs. None are applicable at this time. 285 2.1.2. SRv6 Service Data Sub-Sub-TLVs 287 The format of the SRv6 Service Data Sub-Sub-TLV is depicted below: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Service Data | Sub-sub-TLV Length |Sub-sub TLV // 293 | Sub-sub-TLV | | Value // 294 | Type | | // 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 o SRv6 Service Data Sub-Sub-TLV Type (1 octet): Identifies the type 298 of Sub-Sub-TLV. It is assigned values from the IANA Registry 299 "SRv6 Service Data Sub-Sub-TLVs". 301 o SRv6 Service Data Sub-Sub-TLV Length (2 octets): Specifies the 302 total length of the Sub-Sub-TLV Value field. 304 o SRv6 Service Data Sub-Sub-TLV Value (variable): Contains data 305 specific to the Sub-Sub-TLV Type. 307 At this time, no Sub-Sub-TLV Types are defined. 309 3. BGP based L3 service over SRv6 311 BGP egress nodes (egress PEs) advertise a set of reachable prefixes. 312 Standard BGP update propagation schemes[RFC4271], which may make use 313 of route reflectors [RFC4456], are used to propagate these prefixes. 314 BGP ingress nodes (ingress PEs) receive these advertisements and may 315 add the prefix to the RIB in an appropriate VRF. 317 Egress PEs which supports SRv6 based L3 services advertises overlay 318 service prefixes along with a Service SID enclosed in a SRv6 L3 319 Service TLV within the BGP SID attribute. This TLV serves two 320 purposes - first, it indicates that the egress PE is reachable via an 321 SRv6 underlay and the BGP ingress PE receiving this route MAY choose 322 to encapsulate or insert an SRv6 SRH; second ,it indicates the value 323 of the SID to include in the SRH encapsulation. 325 The Service SID thus signaled only has local significance at the 326 egress PE, where it may be allocated or configured on a per-CE or 327 per-VRF basis. In practice, the SID may encode a cross-connect to a 328 specific Address Family table (END.DT) or next-hop/interface (END.DX) 329 as defined in the SRv6 Network Programming Document 330 [I-D.filsfils-spring-srv6-network-programming]. 332 The SRv6 Service SID MAY be routable within the AS of the egress PE 333 and serves the dual purpose of providing reachability between ingress 334 PE and egress PE while also encoding the endpoint behavior. 336 If the BGP speaker supports MPLS based L3VPN services simultaneously, 337 it MAY also populate a valid Label value in the service route NLRI 338 encoding, and allow the BGP ingress PE to decide which encapsulation 339 to use. If the BGP speaker does not support MPLS based L3VPN 340 services the Label value in any service route NLRI encoding MUST be 341 set to Implicit NULL [RFC3032]. 343 At an ingress PE, BGP installs the received prefix in the correct RIB 344 table, recursing via an SR Policy leveraging the received SRv6 345 Service SID. 347 Assuming best-effort connectivity to the egress PE, the SR policy has 348 a path with a SID list made up of a single SID - the SRv6 Service SID 349 received with the related BGP route update. 351 However, when the received route is colored with an extended color 352 commmunity 'C' and Next-Hop 'N', and the ingress PE has a valid SRv6 353 Policy (C, N) associated with SID list [I-D.filsfils- 354 spring-segment-routing-policy], then the effective SR Policy is . 357 Multiple VPN routes MAY resolve recursively via the same SR Policy. 359 3.1. IPv4 VPN Over SRv6 Core 361 IPv4 VPN Over IPv6 Core is defined in [RFC5549]. The MP_REACH_NLRI 362 is encoded as follows for an SRv6 Core: 364 o AFI = 1 366 o SAFI = 128 368 o Length of Next Hop Network Address = 16 (or 32) 370 o Network Address of Next Hop = IPv6 address of the egress PE 372 o NLRI = IPv4-VPN routes 374 o Label = Implicit NULL 376 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 377 function of the SRv6 SID is entirely up to the originator of the 378 advertisement. In practice, the function may likely be End.DX4 or 379 End.DT4. 381 3.2. IPv6 VPN Over SRv6 Core 383 IPv6 VPN over IPv6 Core is defined in [RFC4659]. The MP_REACH_NLRI 384 is encoded as follows for an SRv6 Core: 386 o AFI = 2 388 o SAFI = 128 390 o Length of Next Hop Network Address = 24 (or 48) 392 o Network Address of Next Hop = 8 octets of RD set to 0 followed by 393 IPv6 address of the egress PE 395 o NLRI = IPv6-VPN routes 397 o Label = Implicit NULL 399 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 400 function of the SRv6 SID is entirely up to the originator of the 401 advertisement. In practice, the function may likely be End.DX6 or 402 End.DT6. 404 3.3. Global IPv4 over SRv6 Core 406 IPv4 over IPv6 Core is defined in [RFC5549]. The MP_REACH_NLRI is 407 encoded with: 409 o AFI = 1 411 o SAFI = 1 413 o Length of Next Hop Network Address = 16 (or 32) 415 o Network Address of Next Hop = IPv6 address of Next Hop 417 o NLRI = IPv4 routes 419 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 420 function of the SRv6 SID is entirely up to the originator of the 421 advertisement. In practice, the function may likely be End.DX4/6 or 422 End.DT4. 424 3.4. Global IPv6 over SRv6 Core 426 The MP_REACH_NLRI is encoded with: 428 o AFI = 2 429 o SAFI = 1 431 o Length of Next Hop Network Address = 16 (or 32) 433 o Network Address of Next Hop = IPv6 address of Next Hop 435 o NLRI = IPv6 routes 437 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 438 function of the SRv6 SID is entirely up to the originator of the 439 advertisement. In practice, the function may likely be End.DX4/6 or 440 End.DT6. 442 Also, by utilizing the SRv6 L3 Service TLV to encode the Global SID, 443 a BGP free core is possible by encapsulating all BGP traffic from 444 edge to edge over SRv6. 446 4. BGP based Ethernet VPN (EVPN) over SRv6 448 Ethernet VPN(EVPN), as defined in [RFC7432] provides an extendable 449 method of building an EVPN overlay. It primarily focuses on MPLS 450 based EVPNs but calls out the extensibility to IP based EVPN 451 overlays. [RFC7432] defines 4 Route Types which carry prefixes and 452 MPLS Label fields; the Label fields have specific use for MPLS 453 encapsulation of EVPN traffic. Route Type 5 carrying MPLS label 454 information (and thus encapsulation information) for EVPN is defined 455 in [I-D.ietf-bess-evpn-prefix-advertisement]. Route Types 6, 7 and 8 456 are defined in [I-D.ietf-bess-evpn-igmp-mld-proxy]. 458 o Ethernet Auto-discovery Route (Route Type 1) 460 o MAC/IP Advertisement Route (Route Type 2) 462 o Inclusive Multicast Ethernet Tag Route (Route Type 3) 464 o Ethernet Segment route (Route Type 4) 466 o IP prefix route (Route Type 5) 468 o Selective Multicast Ethernet Tag route (Route Type 6) 470 o IGMP join sync route (Route Type 7) 472 o IGMP leave sync route (Route Type 8) 474 To support SRv6 based EVPN overlays, one or more SRv6 Service SIDs 475 are advertised with Route Type 1,2,3 and 5. The SRv6 Service SID(s) 476 per Route Type are advertised in SRv6 L3/L2 Service TLVs within the 477 BGP SID attribute. Signaling of SRv6 Service SID(s) serves two 478 purposes - first, it indicates that the BGP egress device is 479 reachable via an SRv6 underlay and the BGP ingress device receiving 480 this route MAY choose to encapsulate or insert an SRv6 SRH; second, 481 it indicates the value of the SID(s) to include in the SRH 482 encapsulation. If the BGP egress device does not support MPLS based 483 EVPN services, the MPLS Label fiellds withing EVPN Route Types MUST 484 be set to Implicit NULL. 486 4.1. Ethernet Auto-discovery route over SRv6 Core 488 Ethernet Auto-Discovery (A-D) routes are Route Type 1 defined in 489 [RFC7432]and may be used to achieve split horizon filtering, fast 490 convergence and aliasing. EVPN Route Type 1 is also used in EVPN- 491 VPWS as well as in EVPN flexible cross-connect; mainly used to 492 advertise point-to-point services ID. 494 Multi-homed PEs MAY advertise an Ethernet Auto-Discovery route per 495 Ethernet segment along with the ESI Label extended community defined 496 in [RFC7432]. The extended community label MUST be set to Implicit 497 NULL. PEs may identify other PEs connected to the same Ethernet 498 segment after the EVPN Route Type 4 ES route exchange. All the 499 multi-homed and remote PEs that are part of same EVI may import the 500 Auto-Discovery route. 502 EVPN Route Type 1 is encoded as follows for SRv6 Core: 504 +---------------------------------------+ 505 | RD (8 octets) | 506 +---------------------------------------+ 507 |Ethernet Segment Identifier (10 octets)| 508 +---------------------------------------+ 509 | Ethernet Tag ID (4 octets) | 510 +---------------------------------------+ 511 | MPLS label (3 octets) | 512 +---------------------------------------+ 514 4.1.1. Per-ES A-D route 516 o BGP next-hop: IPv6 address of an egress PE 518 o Ethernet Tag ID: set to 0xFFFF 520 o MPLS Label: always set to zero value 522 o Extended Community: Per ES AD, ESI label extended community 523 A Service SID enclosed in a SRv6 L2 Service TLV within the BGP SID 524 attribute is advertised along with the A-D route. The behavior of 525 the Service SID thus signaled is entirely up to the originator of the 526 advertisement. This is typically used to signal Arg.FE2 SID argument 527 for applicable End.DT2M SIDs. 529 4.1.2. Per-EVI A-D route 531 o BGP next-hop: IPv6 address of an egress PE 533 o Ethernet Tag ID: non-zero for VLAN aware bridging, EVPN VPWS and 534 FXC 536 o MPLS Label: Implicit NULL 538 A Service SID enclosed in a SRv6 L2 Service TLV within the BGP SID 539 attribute is advertised along with the A-D route. The behavior of 540 the Service SID thus signaled is entirely up to the originator of the 541 advertisement. In practice, the behavior would likely be END.DX2, 542 END.DX2V or END.DT2U. 544 4.2. MAC/IP Advertisement route over SRv6 Core 546 EVPN Route Type 2 is used to advertise unicast traffic MAC+IP address 547 reachability through MP-BGP to all other PEs in a given EVPN 548 instance. 550 EVPN Route Type 2 is encoded as follows for SRv6 Core: 552 +---------------------------------------+ 553 | RD (8 octets) | 554 +---------------------------------------+ 555 |Ethernet Segment Identifier (10 octets)| 556 +---------------------------------------+ 557 | Ethernet Tag ID (4 octets) | 558 +---------------------------------------+ 559 | MAC Address Length (1 octet) | 560 +---------------------------------------+ 561 | MAC Address (6 octets) | 562 +---------------------------------------+ 563 | IP Address Length (1 octet) | 564 +---------------------------------------+ 565 | IP Address (0, 4, or 16 octets) | 566 +---------------------------------------+ 567 | MPLS Label1 (3 octets) | 568 +---------------------------------------+ 569 | MPLS Label2 (0 or 3 octets) | 570 +---------------------------------------+ 572 o BGP next-hop: IPv6 address of an egress PE 574 o MPLS Label1: Implicit NULL 576 o MPLS Label2: Implicit NULL 578 Service SIDs enclosed in SRv6 L2 Service TLV and optionally in SRv6 579 L3 Service TLV within the BGP SID attribute is advertised along with 580 the MAC/IP Advertisement route. 582 Described below are different types of Route Type 2 advertisements. 584 o MAC/IP Advertisement route with MAC Only 586 * BGP next-hop: IPv6 address of egress PE 588 * MPLS Label1: Implicit NULL 590 * MPLS Label2: Implicit NULL 592 o A Service SID enclosed in a SRv6 L2 Service TLV within the BGP SID 593 attribute is advertised along with the route. The behavior of the 594 Service SID thus signaled is entirely up to the originator of the 595 advertisement. In practice, the behavior would likely be END.DX2 596 or END.DT2U. 598 o MAC/IP Advertisement route with MAC+IP 600 * BGP next-hop: IPv6 address of egress PE 602 * MPLS Label1: Implicit NULL 604 * MPLS Label2: Implicit NULL 606 o An L2 Service SID enclosed in a SRv6 L2 Service TLV within the BGP 607 SID attribute is advertised along with the route. In addition, an 608 L3 Service SID enclosed in a SRv6 L3 Service TLV within the BGP 609 SID attribute MAY also be advertised along with the route. The 610 behavior of the Service SID(s) thus signaled is entirely up to the 611 originator of the advertisement. In practice, the behavior would 612 likely be END.DX2 or END.DT2U for the L2 Service SID, and 613 END.DT6/4 or END.DX6/4 for the L3 Service SID. 615 4.3. Inclusive Multicast Ethernet Tag Route over SRv6 Core 617 EVPN Route Type 3 is used to advertise multicast traffic reachability 618 information through MP-BGP to all other PEs in a given EVPN instance. 620 EVPN Route Type 3 is encoded as follows for SRv6 core: 622 +---------------------------------------+ 623 | RD (8 octets) | 624 +---------------------------------------+ 625 | Ethernet Tag ID (4 octets) | 626 +---------------------------------------+ 627 | IP Address Length (1 octet) | 628 +---------------------------------------+ 629 | Originating Router's IP Address | 630 | (4 or 16 octets) | 631 +---------------------------------------+ 633 o BGP next-hop: IPv6 address of egress PE 635 PMSI Tunnel Attribute [RFC6514] MAY contain MPLS Implicit NULL label 636 and Tunnel Type would be similar to that defined in EVPN Route Type 6 637 i.e. Ingress replication route. 639 The format of PMSI Tunnel Attribute attribute is encoded as follows 640 for SRv6 Core: 642 +---------------------------------------+ 643 | Flag (1 octet) | 644 +---------------------------------------+ 645 | Tunnel Type (1 octet) | 646 +---------------------------------------+ 647 | MPLS label (3 octet) | 648 +---------------------------------------+ 649 | Tunnel Identifier (variable) | 650 +---------------------------------------+ 652 o Flag: zero value defined per [RFC7432] 654 o Tunnel Type: defined per [RFC6514] 656 o MPLS label: Implicit NULL 658 o Tunnel Identifier: IP address of egress PE 660 A Service SID enclosed in a SRv6 L2 Service TLV within the BGP SID 661 attribute is advertised along with the route. The behavior of the 662 Service SID thus signaled, is entirely up to the originator of the 663 advertisement. In practice, the behavior of the SRv6 SID is as 664 follows: 666 o END.DX2 or END.DT2M function 667 o The ESI Filtering argument (Arg.FE2) of the Service SID carried 668 along with EVPN Route Type 1 route MAY be merged together with the 669 applicable End.DT2M SID of Type 3 route advertised by remote PE by 670 doing a bitwise logical-OR operation to create a single SID on the 671 ingress PE for Split-horizon and other filtering mechanisms. 672 Details of filtering mechanisms are described in [RFC7432]. 674 4.4. Ethernet Segment route over SRv6 Core 676 An Ethernet Segment route i.e. EVPN Route Type 4 is encoded as 677 follows for SRv6 core: 679 +---------------------------------------+ 680 | RD (8 octets) | 681 +---------------------------------------+ 682 | Ethernet Tag ID (4 octets) | 683 +---------------------------------------+ 684 | IP Address Length (1 octet) | 685 +---------------------------------------+ 686 | Originating Router's IP Address | 687 | (4 or 16 octets) | 688 +---------------------------------------+ 690 o BGP next-hop: IPv6 address of egress PE 692 SRv6 Service TLVs within BGP SID attribute are not advertised along 693 with this route. The processing of the route has not changed - it 694 remains as described in [RFC7432]. 696 4.5. IP prefix route over SRv6 Core 698 EVPN Route Type 5 is used to advertise IP address reachability 699 through MP-BGP to all other PEs in a given EVPN instance. IP address 700 may include host IP prefix or any specific subnet. 702 EVPN Route Type 5 is encoded as follows for SRv6 core: 704 +---------------------------------------+ 705 | RD (8 octets) | 706 +---------------------------------------+ 707 |Ethernet Segment Identifier (10 octets)| 708 +---------------------------------------+ 709 | Ethernet Tag ID (4 octets) | 710 +---------------------------------------+ 711 | IP Prefix Length (1 octet) | 712 +---------------------------------------+ 713 | IP Prefix (4 or 16 octets) | 714 +---------------------------------------+ 715 | GW IP Address (4 or 16 octets) | 716 +---------------------------------------+ 717 | MPLS Label (3 octets) | 718 +---------------------------------------+ 720 o BGP next-hop: IPv6 address of egress PE 722 o MPLS Label: Implicit NULL 724 SRv6 Service SID is encoded as part of the SRv6 L3 Service TLV. The 725 function of the SRv6 SID is entirely up to the originator of the 726 advertisement. In practice, the function may likely be End.DT6/4 or 727 End.DX6/4. 729 4.6. EVPN multicast routes (Route Types 6, 7, 8) over SRv6 core 731 These routes do not require the advertisement of SRv6 Service TLVs 732 along with them. Similar to EVPN Route Type 4, the BGP Nexthop is 733 equal to the IPv6 address of egress PE. More details may be added in 734 future revisions of this document. 736 5. Migration from MPLS based Segment Routing to SRv6 Segment Routing 738 Migration from IPv4 to IPv6 is independent of SRv6 BGP endpoints, and 739 the selection of which route to use (received via the IPv4 or the 740 IPv6 session) is a local configurable decision of the ingress PE, and 741 is outside the scope of this document. 743 Migration from MPLS based underlay to an SRv6 underlay with BGP 744 speakers is achieved with a few simple rules at each BGP speaker. 746 At Egress PE: 747 If BGP offers an SRv6 service, then: 748 BGP allocates an SRv6 Service SID for the L3 service 749 and includes it in the BGP SRv6 L3 Service TLV while advertising the 750 overlay prefixes. 751 If BGP offers an MPLS service, then: 752 BGP allocates an MPLS Label for the L3 service and 753 encode it as part of the NLRI as normal for MPLS based address-families; 754 else, the MPLS label value for the L3 service is set to Implicit NULL. 756 At Ingress PE: 757 Selection of either MPLS encapsulation or SRv6 encapsulation is defined 758 by local BGP policy. 760 If BGP supports SRv6 based services and receives overlay routes with 761 BGP SID attribute containing SRv6 L3 Service TLV(s) encoding 762 SRv6 Service SID(s), then: 763 BGP programs the destination prefix in RIB recursive via 764 the related SR Policy. 765 If BGP supports MPLS service, and the MPLS Label value is not 766 Implicit NULL, then: 767 the MPLS label is used as the overlay service label and inserted with the 768 prefix into RIB via the BGP Nexthop. 770 6. Implementation Status 772 The SRv6 Service is available for SRv6 on various Cisco hardware and 773 other software platforms. An end-to-end integration of SRv6 L3VPN, 774 SRv6 Traffic-Engineering and Service Chaining. All of that with 775 data-plane interoperability across 776 different implementations: 778 o Three Cisco Hardware-forwarding platforms: ASR 1K, ASR 9k and NCS 779 5500 781 o Two Cisco network operating systems: IOS XE and IOS XR 783 o Huawei Hardware-forwarding platforms: ATN, CX, ME, NE5000E, 784 NE9000, NG-OLT 786 o Huawei network operating systems: VRPv8 788 o Barefoot Networks Tofino on OCP Wedge-100BF 790 o Linux Kernel officially upstreamed in 4.10 792 o Fd.io 794 7. Error Handling 796 In case of any errors encountered while processing SRv6 Service TLVs, 797 the details of the error SHOULD be logged for further analysis. 799 If multiple instances of SRv6 L3 Service TLV is encountered, all but 800 the first instance MUST be ignored. 802 If multiple instances of SRv6 L2 Service TLV is encountered, all but 803 the first instance MUST be ignored. 805 An SRv6 Service TLV is considered malformed in the following cases: 807 o the TLV Length is less than 1 809 o the TLV Length is inconsistent with the length of BGP SID 810 attribute 812 o atleast one of the constituent Sub-TLVs is malformed 814 An SRv6 Service Sub-TLV is considered malformed in the following 815 cases: 817 o the Sub-TLV Length is inconsistent with the length of the 818 enclosing SRv6 Service TLV 820 An SRv6 SID Information Sub-TLV is considered malformed in the 821 following cases: 823 * the Sub-TLV Length is less than 21 825 * the Sub-TLV Length is inconsistent with the length of the 826 enclosing SRv6 Service TLV 828 * atleast one of the constituent Sub-Sub-TLVs is malformed 830 An SRv6 Service Data Sub-sub-TLV is considered malformed in the 831 following cases: 833 o the Sub-Sub-TLV Length is inconsistent with the length of the 834 enclosing SRv6 service Sub-TLV 836 Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because 837 its Type is unrecognized. 839 Any TLV or Sub-TLV or Sub-Sub-TLV is not considered malformed because 840 of failing any semantic validation of its Value field. 842 The BGP SID attribute is considered malformed if it contains atleast 843 one constituent SRv6 Service TLV that is malformed. In such cases, 844 the attribute MUST be discarded [RFC7606]and not propagated further. 845 Note that if a path whose BGP SID attribute is discarded in this 846 manner is selected as the best path to be installed in the RIB, 847 traffic forwarding for the corresponding prefix may be affected. 848 Implementations MAY choose to make such paths less preferable or even 849 ineligible during the selection of best path for the corresponding 850 prefix. 852 A BGP speaker receiving a path containing BGP SID attribute with one 853 or more SRv6 Service TLVs observes the following rules when 854 advertising the received path to other peers: 856 o if the nexthop is unchanged during advertisement, the SRv6 Service 857 TLVs, including any unrecognized Types of Sub-TLV and Sub-Sub-TLV, 858 SHOULD be propagated further. In addition, all Reserved fields in 859 the TLV or Sub-TLV or Sub-Sub-TLV MUST be propagated unchanged. 861 o if the nexthop is changed during advertisement, any unrecognized 862 Sub-TLVs and Sub-Sub-TLVs MUST NOT be propagated. 864 o if the nexthop is changed during advertisement, the TLVs, Sub-TLVs 865 and Sub-Sub-TLVs SHOULD be re-originated if appropriate, and not 866 merely propagated unchanged. The interpretation of the meaning of 867 re-origination versus propagation is a matter of local 868 implementation. 870 A received VPN NLRI [RFC4364][RFC4659][RFC7432]that has neither a 871 valid MPLS label nor a valid SRv6 Service TLV MUST be considered 872 unreachable i.e. apply the -treat as withdraw- action specified in 873 [RFC7606]. 875 8. IANA Considerations 877 8.1. BGP Prefix-SID TLV Types registry 879 This document defines two new TLV Types of the BGP Prefx-SID 880 attribute. IANA is requested to assign Type values in the registry 881 "BGP Prefix-SID TLV Types" as follows: 883 Value Type Reference 884 -------------------------------------------- 885 [TBD1] SRv6 L3 Service TLV 886 [TBD2] SRv6 L2 Service TLV 888 IANA is also requested to reserve the following Type value. This was 889 used in some implementations of previous versions of this draft. 891 Value Type Reference 892 -------------------------------------------- 893 4 Reserved 895 8.2. SRv6 Service Sub-TLV Types registry 897 IANA is requested to create and maintain a new registry called "SRv6 898 Service Sub-TLV Types". The allocation policy for this registry is: 900 0 : Reserved 901 1-127 : IETF Review 902 128-254 : First Come First Served 903 255 : Reserved 905 The following Sub-TLV Types are defined in this document: 907 Value Type Reference 908 ---------------------------------------------------- 909 1 SRv6 SID Information Sub-TLV 911 9. Security Considerations 913 This document introduces no new security considerations beyond those 914 already specified in [RFC4271] and [RFC8277]. 916 10. Conclusions 918 This document proposes extensions to the BGP to allow advertising 919 certain attributes and functionalities related to SRv6. 921 11. References 923 11.1. Normative References 925 [I-D.filsfils-spring-segment-routing-policy] 926 Filsfils, C., Sivabalan, S., Hegde, S., 927 daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com, 928 b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B., 929 Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste, 930 J., Clad, F., and K. Raza, "Segment Routing Policy 931 Architecture", draft-filsfils-spring-segment-routing- 932 policy-06 (work in progress), May 2018. 934 [I-D.filsfils-spring-srv6-network-programming] 935 Filsfils, C., Camarillo, P., Leddy, J., 936 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 937 Network Programming", draft-filsfils-spring-srv6-network- 938 programming-07 (work in progress), February 2019. 940 [I-D.ietf-6man-segment-routing-header] 941 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 942 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 943 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 944 progress), February 2019. 946 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 947 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 948 December 1998, . 950 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 951 Reflection: An Alternative to Full Mesh Internal BGP 952 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 953 . 955 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 956 Encodings and Procedures for Multicast in MPLS/BGP IP 957 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 958 . 960 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 961 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 962 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 963 2015, . 965 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 966 Patel, "Revised Error Handling for BGP UPDATE Messages", 967 RFC 7606, DOI 10.17487/RFC7606, August 2015, 968 . 970 [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address 971 Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, 972 . 974 11.2. Informative References 976 [I-D.ietf-bess-evpn-igmp-mld-proxy] 977 Sajassi, A., Thoria, S., Patel, K., Yeung, D., Drake, J., 978 and W. Lin, "IGMP and MLD Proxy for EVPN", draft-ietf- 979 bess-evpn-igmp-mld-proxy-02 (work in progress), June 2018. 981 [I-D.ietf-bess-evpn-prefix-advertisement] 982 Rabadan, J., Henderickx, W., Drake, J., Lin, W., and A. 983 Sajassi, "IP Prefix Advertisement in EVPN", draft-ietf- 984 bess-evpn-prefix-advertisement-11 (work in progress), May 985 2018. 987 [I-D.ietf-idr-bgp-prefix-sid] 988 Previdi, S., Filsfils, C., Lindem, A., Sreekantiah, A., 989 and H. Gredler, "Segment Routing Prefix SID extensions for 990 BGP", draft-ietf-idr-bgp-prefix-sid-27 (work in progress), 991 June 2018. 993 [I-D.ietf-idr-segment-routing-te-policy] 994 Previdi, S., Filsfils, C., Jain, D., Mattes, P., Rosen, 995 E., and S. Lin, "Advertising Segment Routing Policies in 996 BGP", draft-ietf-idr-segment-routing-te-policy-05 (work in 997 progress), November 2018. 999 [I-D.ietf-isis-segment-routing-extensions] 1000 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 1001 Gredler, H., and B. Decraene, "IS-IS Extensions for 1002 Segment Routing", draft-ietf-isis-segment-routing- 1003 extensions-22 (work in progress), December 2018. 1005 [I-D.ietf-spring-segment-routing] 1006 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 1007 Litkowski, S., and R. Shakir, "Segment Routing 1008 Architecture", draft-ietf-spring-segment-routing-15 (work 1009 in progress), January 2018. 1011 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1012 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1013 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 1014 . 1016 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 1017 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 1018 DOI 10.17487/RFC4271, January 2006, 1019 . 1021 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1022 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 1023 2006, . 1025 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1026 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1027 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 1028 . 1030 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1031 "Multiprotocol Extensions for BGP-4", RFC 4760, 1032 DOI 10.17487/RFC4760, January 2007, 1033 . 1035 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 1036 Layer Reachability Information with an IPv6 Next Hop", 1037 RFC 5549, DOI 10.17487/RFC5549, May 2009, 1038 . 1040 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1041 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1042 May 2017, . 1044 Appendix A. Contributors 1046 Bart Peirens 1047 Proximus 1048 Belgium 1050 Email: bart.peirens@proximus.com 1052 Authors' Addresses 1054 Gaurav Dawra (editor) 1055 LinkedIn 1056 USA 1058 Email: gdawra.ietf@gmail.com 1060 Clarence Filsfils 1061 Cisco Systems 1062 Belgium 1064 Email: cfilsfil@cisco.com 1066 Darren Dukes 1067 Cisco Systems 1068 Canada 1070 Email: ddukes@cisco.com 1071 Patrice Brissette 1072 Cisco Systems 1073 Canada 1075 Email: pbrisset@cisco.com 1077 Shyam Sethuram 1078 Cisco Systems 1079 USA 1081 Email: shsethur@cisco.com 1083 Pablo Camarilo 1084 Cisco Systems 1085 Spain 1087 Email: pcamaril@cisco.com 1089 Jonn Leddy 1090 Comcast 1091 USA 1093 Email: john_leddy@cable.comcast.com 1095 Daniel Voyer 1096 Bell Canada 1097 Canada 1099 Email: daniel.voyer@bell.ca 1101 Daniel Bernier 1102 Bell Canada 1103 Canada 1105 Email: daniel.bernier@bell.ca 1107 Dirk Steinberg 1108 Steinberg Consulting 1109 Germany 1111 Email: dws@steinberg.net 1112 Robert Raszuk 1113 Bloomberg LP 1114 USA 1116 Email: robert@raszuk.net 1118 Bruno Decraene 1119 Orange 1120 France 1122 Email: bruno.decraene@orange.com 1124 Satoru Matsushima 1125 SoftBank 1126 1-9-1,Higashi-Shimbashi,Minato-Ku 1127 Japan 105-7322 1129 Email: satoru.matsushima@g.softbank.co.jp 1131 Shunwan Zhuang 1132 Huawei Technologies 1133 China 1135 Email: zhuangshunwan@huawei.com