< draft-ietf-6man-segment-routing-header-09.txt   draft-ietf-6man-segment-routing-header-10.txt >
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils, Ed.
Expires: September 6, 2018 K. Raza Expires: September 18, 2018 Cisco Systems, Inc.
D. Dukes
Cisco Systems, Inc.
J. Leddy J. Leddy
B. Field
Comcast Comcast
D. Voyer
D. Bernier
Bell Canada
S. Matsushima S. Matsushima
Softbank Softbank
I. Leung D. Voyer, Ed.
Rogers Communications Bell Canada
J. Linkova March 17, 2018
Google
E. Aries
Facebook
T. Kosugi
NTT
E. Vyncke
Cisco Systems, Inc.
D. Lebrun
Universite Catholique de Louvain
D. Steinberg
Steinberg Consulting
R. Raszuk
Bloomberg
March 5, 2018
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-09 draft-ietf-6man-segment-routing-header-10
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction, header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain. maintaining per-flow state only at the ingress node to the SR domain.
skipping to change at page 2, line 28 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on September 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 4 1. Segment Routing Documents . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Data Planes supporting Segment Routing . . . . . . . . . 4 2.1. Data Planes supporting Segment Routing . . . . . . . . . 4
2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 5 2.2. SRv6 Segment . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5 2.3. Segment Routing (SR) Domain . . . . . . . . . . . . . . . 5
2.3.1. SR Domain in a Service Provider Network . . . . . . . 6 2.3.1. SR Domain in a Service Provider Network . . . . . . . 6
2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7 2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7
3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 9 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 8
3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11
3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12
3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13
3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 13
3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14
3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15 3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15
3.2. SRH and RFC8200 behavior . . . . . . . . . . . . . . . . 16 3.2. SRH and RFC8200 behavior . . . . . . . . . . . . . . . . 15
4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16 4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 17 4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 16
4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 18 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 17
5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 19 5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 18
5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 19
5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20 5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. Source routing threats . . . . . . . . . . . . . . . 21 6.1.1. Source routing threats . . . . . . . . . . . . . . . 21
6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 21 6.1.2. Applicability of RFC 5095 to SRH . . . . . . . . . . 21
6.1.3. Service stealing threat . . . . . . . . . . . . . . . 22 6.1.3. Service stealing threat . . . . . . . . . . . . . . . 22
6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 22 6.1.4. Topology disclosure . . . . . . . . . . . . . . . . . 22
6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 23 6.1.5. ICMP Generation . . . . . . . . . . . . . . . . . . . 22
6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 23 6.2. Security fields in SRH . . . . . . . . . . . . . . . . . 23
6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 24 6.2.1. Selecting a hash algorithm . . . . . . . . . . . . . 24
6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 25 6.2.2. Performance impact of HMAC . . . . . . . . . . . . . 24
6.2.3. Pre-shared key management . . . . . . . . . . . . . . 25 6.2.3. Pre-shared key management . . . . . . . . . . . . . . 25
6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 26 6.3. Deployment Models . . . . . . . . . . . . . . . . . . . . 26
6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 26 6.3.1. Nodes within the SR domain . . . . . . . . . . . . . 26
6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 26 6.3.2. Nodes outside of the SR domain . . . . . . . . . . . 26
6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 27 6.3.3. SR path exposure . . . . . . . . . . . . . . . . . . 27
6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 27 6.3.4. Impact of BCP-38 . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
7.1. Segment Routing Header TLVs Register . . . . . . . . . . 28 7.1. Segment Routing Header TLVs Register . . . . . . . . . . 28
8. Manageability Considerations . . . . . . . . . . . . . . . . 29 8. Manageability Considerations . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Segment Routing Documents 1. Segment Routing Documents
Segment Routing terminology is defined in Segment Routing terminology is defined in
[I-D.ietf-spring-segment-routing]. [I-D.ietf-spring-segment-routing].
The network programming paradigm The network programming paradigm
[I-D.filsfils-spring-srv6-network-programming] defines the basic [I-D.filsfils-spring-srv6-network-programming] defines the basic
functions associated to an SRv6 SID. functions associated to an SRv6 SID.
skipping to change at page 8, line 37 skipping to change at page 7, line 47
Each node may originate packets with an SRH which contains, in the Each node may originate packets with an SRH which contains, in the
segment list of the SRH or in the DA, segments identifying other segment list of the SRH or in the DA, segments identifying other
overlay nodes. This implies that packets with an SRH may traverse overlay nodes. This implies that packets with an SRH may traverse
operator's networks but, obviously, these SRHs cannot contain an operator's networks but, obviously, these SRHs cannot contain an
address/segment of the transit operators 1, 2 and 3. The SRH address/segment of the transit operators 1, 2 and 3. The SRH
originated by the overlay can only contain address/segment under the originated by the overlay can only contain address/segment under the
administration of the overlay (e.g. address/segments supported by A1, administration of the overlay (e.g. address/segments supported by A1,
A2, A3, B1, B2, B3, C1,C2 or C3). A2, A3, B1, B2, B3, C1,C2 or C3).
In this model, the operator network nodes are transit nodes and, In this model, the operator network nodes are transit nodes and, as
according to [RFC8200], MUST NOT inspect the routing extension header specified in [RFC8200], MUST NOT inspect the routing extension header
since they are not the DA of the packet. since they are not the DA of the packet.
It is a common practice in operators networks to filter out, at It is a common practice in operators networks to filter out, at
ingress, any packet whose DA is the address of an internal node and ingress, any packet whose DA is the address of an internal node and
it is also possible that an operator would filter out any packet it is also possible that an operator would filter out any packet
destined to an internal address and having an extension header in it. destined to an internal address and having an extension header in it.
This common practice does not impact the SR-enabled traffic between This common practice does not impact the SR-enabled traffic between
the overlay nodes as the intermediate transit networks never see a the overlay nodes as the intermediate transit networks never see a
destination address belonging to their infrastructure. These SR- destination address belonging to their infrastructure. These SR-
skipping to change at page 19, line 36 skipping to change at page 19, line 11
Local path computation. Local path computation.
Local configuration. Local configuration.
Interaction with a centralized controller delivering the path. Interaction with a centralized controller delivering the path.
Any other mechanism. Any other mechanism.
The following are the steps of the creation of the SRH: The following are the steps of the creation of the SRH:
Next Header and Hdr Ext Len fields are set according to [RFC8200]. Next Header and Hdr Ext Len fields are set as specified in
[RFC8200].
Routing Type field is set as TBD (to be allocated by IANA, Routing Type field is set as TBD (to be allocated by IANA,
suggested value 4). suggested value 4).
The DA of the packet is set with the value of the first segment. The DA of the packet is set with the value of the first segment.
). ).
The first element of the segment list is the last segment (the The first element of the segment list is the last segment (the
final DA of the packet). The second element is the penultimate final DA of the packet). The second element is the penultimate
segment and so on. segment and so on.
skipping to change at page 20, line 18 skipping to change at page 19, line 43
The packet is sent out towards the packet's DA (the first The packet is sent out towards the packet's DA (the first
segment). segment).
HMAC TLV may be set according to Section 6. HMAC TLV may be set according to Section 6.
If the segment list contains a single segment and there is no need If the segment list contains a single segment and there is no need
for information in flag or TLV, then the SRH MAY be omitted. for information in flag or TLV, then the SRH MAY be omitted.
5.2. Transit Node 5.2. Transit Node
According to [RFC8200], the only node who is allowed to inspect the As specified in [RFC8200], the only node who is allowed to inspect
Routing Extension Header (and therefore the SRH), is the node the Routing Extension Header (and therefore the SRH), is the node
corresponding to the DA of the packet. Any other transit node MUST corresponding to the DA of the packet. Any other transit node MUST
NOT inspect the underneath routing header and MUST forward the packet NOT inspect the underneath routing header and MUST forward the packet
towards the DA and according to the IPv6 routing table. towards the DA and according to the IPv6 routing table.
In the example case described in Section 2.3.2, when SR capable nodes In the example case described in Section 2.3.2, when SR capable nodes
are connected through an overlay spanning multiple third-party are connected through an overlay spanning multiple third-party
infrastructure, it is safe to send SRH packets (i.e.: packet having a infrastructure, it is safe to send SRH packets (i.e.: packet having a
Segment Routing Header) between each other overlay/SR-capable nodes Segment Routing Header) between each other overlay/SR-capable nodes
as long as the segment list does not include any of the transit as long as the segment list does not include any of the transit
provider nodes. In addition, as a generic security measure, any provider nodes. In addition, as a generic security measure, any
skipping to change at page 21, line 15 skipping to change at page 20, line 40
o inspected and acted upon when reaching the destination address of o inspected and acted upon when reaching the destination address of
the IP header per RFC 8200 [RFC8200]. the IP header per RFC 8200 [RFC8200].
Per RFC8200 [RFC8200], routers on the path that simply forward an Per RFC8200 [RFC8200], routers on the path that simply forward an
IPv6 packet (i.e. the IPv6 destination address is none of theirs) IPv6 packet (i.e. the IPv6 destination address is none of theirs)
will never inspect and process the content of the SRH. Routers whose will never inspect and process the content of the SRH. Routers whose
one interface IPv6 address equals the destination address field of one interface IPv6 address equals the destination address field of
the IPv6 packet MUST parse the SRH and, if supported and if the local the IPv6 packet MUST parse the SRH and, if supported and if the local
configuration allows it, MUST act accordingly to the SRH content. configuration allows it, MUST act accordingly to the SRH content.
According to RFC8200 [RFC8200], the default behavior of a non SR- As specified in RFC8200 [RFC8200], the default behavior of a non SR-
capable router upon receipt of an IPv6 packet with SRH destined to an capable router upon receipt of an IPv6 packet with SRH destined to an
address of its, is to: address of its, is to:
o ignore the SRH completely if the Segment Left field is 0 and o ignore the SRH completely if the Segment Left field is 0 and
proceed to process the next header in the IPv6 packet; proceed to process the next header in the IPv6 packet;
o discard the IPv6 packet if Segment Left field is greater than 0, o discard the IPv6 packet if Segment Left field is greater than 0,
it MAY send a Parameter Problem ICMP message back to the Source it MAY send a Parameter Problem ICMP message back to the Source
Address. Address.
skipping to change at page 29, line 11 skipping to change at page 28, line 38
4 Padding TLV This document 4 Padding TLV This document
5 HMAC TLV This document 5 HMAC TLV This document
6 NSH Carrier TLV This document 6 NSH Carrier TLV This document
8. Manageability Considerations 8. Manageability Considerations
TBD TBD
9. Contributors 9. Contributors
Dave Barach, John Brzozowski, Pierre Francois, Nagendra Kumar, Mark Kamran Raza, Darren Dukes, Brian Field, Daniel Bernier, Ida Leung,
Townsley, Christian Martin, Roberta Maglione, James Connolly, Aloys Jen Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun,
Augustin contributed to the content of this document. Dirk Steinberg, Robert Raszuk, Dave Barach, John Brzozowski, Pierre
Francois, Nagendra Kumar, Mark Townsley, Christian Martin, Roberta
Maglione, James Connolly, Aloys Augustin contributed to the content
of this document.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Ole Troan, Bob Hinden, Fred Baker, The authors would like to thank Ole Troan, Bob Hinden, Fred Baker,
Brian Carpenter, Alexandru Petrescu and Punit Kumar Jaiswal for their Brian Carpenter, Alexandru Petrescu, Punit Kumar Jaiswal, and David
comments to this document. Lebrun for their comments to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[FIPS180-4] [FIPS180-4]
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
180-4 Secure Hash Standard (SHS)", March 2012, 180-4 Secure Hash Standard (SHS)", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
skipping to change at page 30, line 23 skipping to change at page 30, line 15
[I-D.dawra-bgp-srv6-vpn] [I-D.dawra-bgp-srv6-vpn]
(Unknown), (., Dawra, G., Filsfils, C., Dukes, D., (Unknown), (., Dawra, G., Filsfils, C., Dukes, D.,
Brissette, P., Camarillo, P., Leddy, J., Brissette, P., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d.,
Steinberg, D., Raszuk, R., Decraene, B., and S. Steinberg, D., Raszuk, R., Decraene, B., and S.
Matsushima, "BGP Signaling of IPv6-Segment-Routing-based Matsushima, "BGP Signaling of IPv6-Segment-Routing-based
VPN Networks", draft-dawra-bgp-srv6-vpn-00 (work in VPN Networks", draft-dawra-bgp-srv6-vpn-00 (work in
progress), March 2017. progress), March 2017.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d., Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d.,
daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and
Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W., M. Sharif, "SRv6 Network Programming", draft-filsfils-
Bashandy, A., Raza, K., Dukes, D., Clad, F., and P. spring-srv6-network-programming-04 (work in progress),
Camarillo, "SRv6 Network Programming", draft-filsfils- March 2018.
spring-srv6-network-programming-03 (work in progress),
December 2017.
[I-D.ietf-isis-l2bundles] [I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017. May 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
skipping to change at page 32, line 34 skipping to change at page 32, line 24
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <https://www.rfc-editor.org/info/rfc7855>. 2016, <https://www.rfc-editor.org/info/rfc7855>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi
Individual Individual
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Clarence Filsfils Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Kamran Raza
Cisco Systems, Inc.
Email: skraza@cisco.com
"Darren Dukes
Cisco Systems, Inc.
Email: ddukes@cisco.com
John Leddy John Leddy
Comcast Comcast
4100 East Dry Creek Road 4100 East Dry Creek Road
Centennial, CO 80122 Centennial, CO 80122
US US
Email: John_Leddy@comcast.com Email: John_Leddy@comcast.com
Brian Field
Comcast
4100 East Dry Creek Road
Centennial, CO 80122
US
Email: Brian_Field@cable.comcast.com
Daniel Voyer
Bell Canada
Email: daniel.voyer@bell.ca
Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
Satoru Matsushima Satoru Matsushima
Softbank Softbank
Email: satoru.matsushima@g.softbank.co.jp Email: satoru.matsushima@g.softbank.co.jp
Ida Leung Daniel Voyer (editor)
Rogers Communications Bell Canada
8200 Dixie Road
Brampton, ON L6T 0C1
CA
Email: Ida.Leung@rci.rogers.com
Jen Linkova
Google
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: furry@google.com
Ebben Aries
Facebook
US
Email: exa@fb.com
Tomoya Kosugi
NTT
3-9-11, Midori-Cho Musashino-Shi,
Tokyo 180-8585
JP
Email: kosugi.tomoya@lab.ntt.co.jp
Eric Vyncke
Cisco Systems, Inc.
De Kleetlaann 6A
Diegem 1831
Belgium
Email: evyncke@cisco.com
David Lebrun
Universite Catholique de Louvain
Place Ste Barbe, 2
Louvain-la-Neuve, 1348
Belgium
Email: david.lebrun@uclouvain.be
Dirk Steinberg
Steinberg Consulting
Email: dws@dirksteinberg.de
Robert Raszuk
Bloomberg
Email: robert@raszuk.net Email: daniel.voyer@bell.ca
 End of changes. 32 change blocks. 
146 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/