Diff: draft-ietf-spring-segment-routing-msdc-00.txt - draft-ietf-spring-segment-routing-msdc-01.txt

	< draft-ietf-spring-segment-routing-msdc-00.txt	draft-ietf-spring-segment-routing-msdc-01.txt >

	Network Working Group C. Filsfils, Ed.	Network Working Group C. Filsfils, Ed.
	Internet-Draft S. Previdi, Ed.	Internet-Draft S. Previdi, Ed.
	Intended status: Informational Cisco Systems, Inc.	Intended status: Informational Cisco Systems, Inc.

	Expires: April 14, 2016 J. Mitchell	Expires: October 15, 2016 J. Mitchell
	Unaffiliated	Unaffiliated
	E. Aries	E. Aries
	P. Lapukhov	P. Lapukhov
	Facebook	Facebook

	October 12, 2015	April 13, 2016

	BGP-Prefix Segment in large-scale data centers	BGP-Prefix Segment in large-scale data centers

	draft-ietf-spring-segment-routing-msdc-00	draft-ietf-spring-segment-routing-msdc-01

	Abstract	Abstract

	This document describes the motivation and benefits for applying	This document describes the motivation and benefits for applying
	segment routing in the data-center. It describes the design to	segment routing in the data-center. It describes the design to
	deploy segment routing in the data-center, for both the MPLS and IPv6	deploy segment routing in the data-center, for both the MPLS and IPv6
	dataplanes.	dataplanes.

	Requirements Language	Requirements Language


	skipping to change at page 1, line 44 ¶	skipping to change at page 1, line 44 ¶
	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 http://datatracker.ietf.org/drafts/current/.	Drafts is at http://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 April 14, 2016.	This Internet-Draft will expire on October 15, 2016.

	Copyright Notice	Copyright Notice


	Copyright (c) 2015 IETF Trust and the persons identified as the	Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of	(http://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

	skipping to change at page 3, line 5 ¶	skipping to change at page 3, line 5 ¶
	8.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 17	8.2. Minimizing the FIB table . . . . . . . . . . . . . . . . 17
	8.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 17	8.3. Egress Peer Engineering . . . . . . . . . . . . . . . . . 17
	8.4. Incremental Deployments . . . . . . . . . . . . . . . . . 18	8.4. Incremental Deployments . . . . . . . . . . . . . . . . . 18
	8.5. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 18	8.5. Anycast . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Preferred SRGB Allocation . . . . . . . . . . . . . . . . . . 18	9. Preferred SRGB Allocation . . . . . . . . . . . . . . . . . . 18
	10. Alternative Options . . . . . . . . . . . . . . . . . . . . . 19	10. Alternative Options . . . . . . . . . . . . . . . . . . . . . 19
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
	12. Manageability Considerations . . . . . . . . . . . . . . . . 20	12. Manageability Considerations . . . . . . . . . . . . . . . . 20
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 20	13. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20

	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20	15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
	15.1. Normative References . . . . . . . . . . . . . . . . . . 20	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	15.2. Informative References . . . . . . . . . . . . . . . . . 20	16.1. Normative References . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21	16.2. Informative References . . . . . . . . . . . . . . . . . 21
		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22

	1. Introduction	1. Introduction

	Segment Routing (SR), as described in	Segment Routing (SR), as described in

	[I-D.filsfils-spring-segment-routing] leverages the source routing	[I-D.ietf-spring-segment-routing] leverages the source routing
	paradigm. A node steers a packet through an ordered list of	paradigm. A node steers a packet through an ordered list of
	instructions, called segments. A segment can represent any	instructions, called segments. A segment can represent any
	instruction, topological or service-based. A segment can have a	instruction, topological or service-based. A segment can have a
	local semantic to an SR node or global within an SR domain. SR	local semantic to an SR node or global within an SR domain. SR
	allows to enforce a flow through any topological path and service	allows to enforce a flow through any topological path and service
	chain while maintaining per-flow state only at the ingress node to	chain while maintaining per-flow state only at the ingress node to
	the SR domain. Segment Routing can be applied to the MPLS and IPv6	the SR domain. Segment Routing can be applied to the MPLS and IPv6
	data-planes.	data-planes.

	The use-case use-cases described in this document should be	The use-case use-cases described in this document should be

	skipping to change at page 6, line 38 ¶	skipping to change at page 6, line 38 ¶
	First, we will explain how to apply SR in the DC, for MPLS and IPv6	First, we will explain how to apply SR in the DC, for MPLS and IPv6
	data-planes.	data-planes.

	4. Applying Segment Routing in the DC with MPLS dataplane	4. Applying Segment Routing in the DC with MPLS dataplane

	4.1. BGP Prefix Segment	4.1. BGP Prefix Segment

	A BGP-Prefix Segment is a segment associated with a BGP prefix. A	A BGP-Prefix Segment is a segment associated with a BGP prefix. A
	BGP-Prefix Segment is a network-wide instruction to forward the	BGP-Prefix Segment is a network-wide instruction to forward the
	packet along the ECMP-aware best path to the related prefix	packet along the ECMP-aware best path to the related prefix

	([I-D.keyupate-idr-bgp-prefix-sid]).	([I-D.ietf-idr-bgp-prefix-sid]).

	In this document, we make the network design decision to assume that	In this document, we make the network design decision to assume that
	all the nodes are allocated the same SRGB, e.g. [16000, 23999]. This	all the nodes are allocated the same SRGB, e.g. [16000, 23999]. This
	is important to fulfill the recommendation for operational	is important to fulfill the recommendation for operational

	simplification as explained in [I-D.filsfils-spring-segment-routing].	simplification as explained in [I-D.ietf-spring-segment-routing].

	Note well that the use of a common SRGB in all nodes is not a	Note well that the use of a common SRGB in all nodes is not a
	requirement, one could use a different SRGB at every node. However,	requirement, one could use a different SRGB at every node. However,
	this would make the operation of the DC fabric more complex as the	this would make the operation of the DC fabric more complex as the
	label allocated to the loopback of a remote switch is then different	label allocated to the loopback of a remote switch is then different
	at every node. This also may increase the complexity of the	at every node. This also may increase the complexity of the
	centralized controller.	centralized controller.

	For illustration purpose, when considering an MPLS data-plane, we	For illustration purpose, when considering an MPLS data-plane, we
	assume that the segment index allocated to prefix 192.0.2.x/32 is X.	assume that the segment index allocated to prefix 192.0.2.x/32 is X.

	skipping to change at page 10, line 34 ¶	skipping to change at page 10, line 34 ¶

	4.2.3. Network Design Variation	4.2.3. Network Design Variation

	A network design choice could consist of switching all the traffic	A network design choice could consist of switching all the traffic
	through Tier-1 and Tier-2 as MPLS traffic. In this case, one could	through Tier-1 and Tier-2 as MPLS traffic. In this case, one could
	filter away the IP entries at Nodes 4, 7 and 10. This might be	filter away the IP entries at Nodes 4, 7 and 10. This might be
	beneficial in order to optimize the forwarding table size.	beneficial in order to optimize the forwarding table size.

	A network design choice could consist in allowing the hosts to send	A network design choice could consist in allowing the hosts to send
	MPLS-encapsulated traffic (based on EPE use-case,	MPLS-encapsulated traffic (based on EPE use-case,

	[I-D.filsfils-spring-segment-routing-central-epe]). For example,	[I-D.ietf-spring-segment-routing-central-epe]). For example,
	applications at HostA would send their Z-destined traffic to Node1	applications at HostA would send their Z-destined traffic to Node1
	with an MPLS label stack where the top label is 16011 and the next	with an MPLS label stack where the top label is 16011 and the next
	label is an EPE peer segment at Node11 directing the traffic to Z.	label is an EPE peer segment at Node11 directing the traffic to Z.

	4.2.4. Global BGP Prefix Segment through the fabric	4.2.4. Global BGP Prefix Segment through the fabric

	When the previous design is deployed, the operator enjoys global BGP	When the previous design is deployed, the operator enjoys global BGP
	prefix segment (label) allocation throughout the DC fabric.	prefix segment (label) allocation throughout the DC fabric.

	A few examples follow:	A few examples follow:

	skipping to change at page 13, line 4 ¶	skipping to change at page 13, line 4 ¶

	5. Applying Segment Routing in the DC with IPv6 dataplane	5. Applying Segment Routing in the DC with IPv6 dataplane

	The design described in I-D.ietf-rtgwg-bgp-routing-large-dc	The design described in I-D.ietf-rtgwg-bgp-routing-large-dc
	[I-D.ietf-rtgwg-bgp-routing-large-dc] is reused with one single	[I-D.ietf-rtgwg-bgp-routing-large-dc] is reused with one single
	modification. We highlight it using the example of the reachability	modification. We highlight it using the example of the reachability
	to Node11 via spine switch Node5.	to Node11 via spine switch Node5.

	Spine5 originates 2001:DB8::5/128 with the attached BGP Prefix	Spine5 originates 2001:DB8::5/128 with the attached BGP Prefix
	Attribute adverting the support of the Segment Routing extension	Attribute adverting the support of the Segment Routing extension

	header (SRH, [I-D.previdi-6man-segment-routing-header]) for IPv6	header (SRH, [I-D.ietf-6man-segment-routing-header]) for IPv6 packets
	packets destined to segment 2001:DB8::5.	destined to segment 2001:DB8::5.

	Tor11 originates 2001:DB8::11/128 with the attached BGP Prefix	Tor11 originates 2001:DB8::11/128 with the attached BGP Prefix
	Attribute adverting the support of the Segment Routing extension	Attribute adverting the support of the Segment Routing extension

	header (SRH, [I-D.previdi-6man-segment-routing-header]) for IPv6	header (SRH, [I-D.ietf-6man-segment-routing-header]) for IPv6 packets
	packets destined to segment 2001:DB8::11.	destined to segment 2001:DB8::11.

	The control-plane and data-plane processing of all the other nodes in	The control-plane and data-plane processing of all the other nodes in
	the fabric is unchanged. Specifically, the routes to 2001:DB8::5 and	the fabric is unchanged. Specifically, the routes to 2001:DB8::5 and
	2001:DB8::11 are installed in the FIB along the eBGP best-path to	2001:DB8::11 are installed in the FIB along the eBGP best-path to
	Node5 (spine node) and Node11 (ToR node) respectively.	Node5 (spine node) and Node11 (ToR node) respectively.

	An application on HostA which needs to send traffic to HostZ via only	An application on HostA which needs to send traffic to HostZ via only
	Node5 (spine node) can do so by sending IPv6 packets with a SR	Node5 (spine node) can do so by sending IPv6 packets with a SR
	extension header. The destination address and active segment is set	extension header. The destination address and active segment is set
	to 2001:DB8::5. The next and last segment is set to 2001:DB8::11.	to 2001:DB8::5. The next and last segment is set to 2001:DB8::11.

	skipping to change at page 17, line 41 ¶	skipping to change at page 17, line 41 ¶

	This is easily accomplished by encapsulating the traffic either	This is easily accomplished by encapsulating the traffic either
	directly at the host or at the source ToR switch by pushing the BGP-	directly at the host or at the source ToR switch by pushing the BGP-
	Prefix Segment of the destination ToR for intra-DC traffic or border	Prefix Segment of the destination ToR for intra-DC traffic or border
	switch for inter-DC or DC-to-outside-world traffic.	switch for inter-DC or DC-to-outside-world traffic.

	8.3. Egress Peer Engineering	8.3. Egress Peer Engineering

	It is straightforward to combine the design illustrated in this	It is straightforward to combine the design illustrated in this
	document with the Egress Peer Engineering (EPE) use-case described in	document with the Egress Peer Engineering (EPE) use-case described in

	[I-D.filsfils-spring-segment-routing-central-epe].	[I-D.ietf-spring-segment-routing-central-epe].

	In such case, the operator is able to engineer its outbound traffic	In such case, the operator is able to engineer its outbound traffic
	on a per host-flow basis, without incurring any additional state at	on a per host-flow basis, without incurring any additional state at
	intermediate points in the DC fabric.	intermediate points in the DC fabric.

	For example, the controller only needs to inject a per-flow state on	For example, the controller only needs to inject a per-flow state on
	the HostA to force it to send its traffic destined to a specific	the HostA to force it to send its traffic destined to a specific
	Internet destination D via a selected border switch (say Node12 in	Internet destination D via a selected border switch (say Node12 in
	Figure 1 instead of another border switch Node11) and a specific	Figure 1 instead of another border switch Node11) and a specific
	egress peer of Node12 (say peer AS 9999 of local PeerNode segment	egress peer of Node12 (say peer AS 9999 of local PeerNode segment

	skipping to change at page 18, line 30 ¶	skipping to change at page 18, line 30 ¶

	8.4. Incremental Deployments	8.4. Incremental Deployments

	As explained in Section 4.2.5, this design can be deployed	As explained in Section 4.2.5, this design can be deployed
	incrementally.	incrementally.

	8.5. Anycast	8.5. Anycast

	The design presented in this document preserves the availability and	The design presented in this document preserves the availability and
	load-balancing properties of the base design presented in	load-balancing properties of the base design presented in

	[I-D.filsfils-spring-segment-routing].	[I-D.ietf-spring-segment-routing].

	For example, one could assign an anycast loopback 192.0.2.20/32 and	For example, one could assign an anycast loopback 192.0.2.20/32 and
	associate segment index 20 to it on the border switches 11 and 12 (in	associate segment index 20 to it on the border switches 11 and 12 (in
	addition to their node-specific loopbacks). Doing so, the EPE	addition to their node-specific loopbacks). Doing so, the EPE
	controller could express a default "go-to-the- Internet via any	controller could express a default "go-to-the- Internet via any
	border switch" policy as segment list {16020}. Indeed, from any host	border switch" policy as segment list {16020}. Indeed, from any host
	in the DC fabric or from any ToR switch, 16020 steers the packet	in the DC fabric or from any ToR switch, 16020 steers the packet
	towards the border switches 11 or 12 leveraging ECMP where available	towards the border switches 11 or 12 leveraging ECMP where available
	along the best paths to these switches.	along the best paths to these switches.


	skipping to change at page 20, line 23 ¶	skipping to change at page 20, line 23 ¶
	13. Security Considerations	13. Security Considerations

	TBD	TBD

	14. Acknowledgements	14. Acknowledgements

	The authors would like to thank Benjamin Black, Arjun Sreekantiah,	The authors would like to thank Benjamin Black, Arjun Sreekantiah,
	Keyur Patel and Acee Lindem for their comments and review of this	Keyur Patel and Acee Lindem for their comments and review of this
	document.	document.


	15. References	15. Contributors


	15.1. Normative References	Gaya Nagarajan
		Facebook
		US

		Email: gaya@fb.com

		Dmitry Afanasiev
		Yandex
		RU

		Email: fl0w@yandex-team.ru

		Tim Laberge
		Cisco
		US

		Email: tlaberge@cisco.com

		Edet Nkposong
		Microsoft
		US

		Email: edetn@microsoft.com
		Mohan Nanduri
		Microsoft
		US

		Email: mnanduri@microsoft.com

		James Uttaro
		ATT
		US

		Email: ju1738@att.com

		Saikat Ray
		Unaffiliated
		US

		Email: raysaikat@gmail.com

		16. References

		16.1. Normative References

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.	<http://www.rfc-editor.org/info/rfc2119>.

	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,	BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001,
	<http://www.rfc-editor.org/info/rfc3107>.	<http://www.rfc-editor.org/info/rfc3107>.

	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,	Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,	DOI 10.17487/RFC4271, January 2006,
	<http://www.rfc-editor.org/info/rfc4271>.	<http://www.rfc-editor.org/info/rfc4271>.

	[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,	[RFC7311] Mohapatra, P., Fernando, R., Rosen, E., and J. Uttaro,
	"The Accumulated IGP Metric Attribute for BGP", RFC 7311,	"The Accumulated IGP Metric Attribute for BGP", RFC 7311,
	DOI 10.17487/RFC7311, August 2014,	DOI 10.17487/RFC7311, August 2014,
	<http://www.rfc-editor.org/info/rfc7311>.	<http://www.rfc-editor.org/info/rfc7311>.


	15.2. Informative References	16.2. Informative References

	[GREENBERG09]	[GREENBERG09]
	Greenberg, A., Hamilton, J., Jain, N., Kadula, S., Kim,	Greenberg, A., Hamilton, J., Jain, N., Kadula, S., Kim,
	C., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta,	C., Lahiri, P., Maltz, D., Patel, P., and S. Sengupta,
	"VL2: A Scalable and Flexible Data Center Network", 2009.	"VL2: A Scalable and Flexible Data Center Network", 2009.


	[I-D.filsfils-spring-segment-routing]	[I-D.ietf-6man-segment-routing-header]
	Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,	Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
	Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,	J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment
	Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,	Routing Header (SRH)", draft-ietf-6man-segment-routing-
	"Segment Routing Architecture", draft-filsfils-spring-	header-01 (work in progress), March 2016.
	segment-routing-04 (work in progress), July 2014.


	[I-D.filsfils-spring-segment-routing-central-epe]	[I-D.ietf-idr-bgp-prefix-sid]
	Filsfils, C., Previdi, S., Patel, K., Shaw, S., Ginsburg,	Previdi, S., Filsfils, C., Lindem, A., Patel, K.,
	D., and D. Afanasiev, "Segment Routing Centralized Egress	Sreekantiah, A., Ray, S., and H. Gredler, "Segment Routing
	Peer Engineering", draft-filsfils-spring-segment-routing-	Prefix SID extensions for BGP", draft-ietf-idr-bgp-prefix-
	central-epe-05 (work in progress), August 2015.	sid-02 (work in progress), December 2015.

	[I-D.ietf-mpls-seamless-mpls]	[I-D.ietf-mpls-seamless-mpls]
	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,	Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
	M., and D. Steinberg, "Seamless MPLS Architecture", draft-	M., and D. Steinberg, "Seamless MPLS Architecture", draft-
	ietf-mpls-seamless-mpls-07 (work in progress), June 2014.	ietf-mpls-seamless-mpls-07 (work in progress), June 2014.

	[I-D.ietf-rtgwg-bgp-routing-large-dc]	[I-D.ietf-rtgwg-bgp-routing-large-dc]
	Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for	Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for
	routing in large-scale data centers", draft-ietf-rtgwg-	routing in large-scale data centers", draft-ietf-rtgwg-

	bgp-routing-large-dc-07 (work in progress), August 2015.	bgp-routing-large-dc-09 (work in progress), March 2016.


	[I-D.keyupate-idr-bgp-prefix-sid]	[I-D.ietf-spring-segment-routing]
	Patel, K., Previdi, S., Filsfils, C., Sreekantiah, A.,	Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
	Ray, S., and H. Gredler, "Segment Routing Prefix SID	and R. Shakir, "Segment Routing Architecture", draft-ietf-
	extensions for BGP", draft-keyupate-idr-bgp-prefix-sid-05	spring-segment-routing-07 (work in progress), December
	(work in progress), July 2015.	2015.


	[I-D.previdi-6man-segment-routing-header]	[I-D.ietf-spring-segment-routing-central-epe]
	Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,	Filsfils, C., Previdi, S., Ginsburg, D., and D. Afanasiev,
	J., Kosugi, T., Vyncke, E., and D. Lebrun, "IPv6 Segment	"Segment Routing Centralized BGP Peer Engineering", draft-
	Routing Header (SRH)", draft-previdi-6man-segment-routing-	ietf-spring-segment-routing-central-epe-01 (work in
	header-08 (work in progress), October 2015.	progress), March 2016.

	[KANDULA04]	[KANDULA04]
	Sinha, S., Kandula, S., and D. Katabi, "Harnessing TCP's	Sinha, S., Kandula, S., and D. Katabi, "Harnessing TCP's
	Burstiness with Flowlet Switching", 2004.	Burstiness with Flowlet Switching", 2004.

	Authors' Addresses	Authors' Addresses

	Clarence Filsfils (editor)	Clarence Filsfils (editor)
	Cisco Systems, Inc.	Cisco Systems, Inc.
	Brussels	Brussels
	BE	BE

	Email: cfilsfil@cisco.com	Email: cfilsfil@cisco.com
	Stefano Previdi (editor)	Stefano Previdi (editor)
	Cisco Systems, Inc.	Cisco Systems, Inc.

		Via Del Serafico, 200
	Rome 00142	Rome 00142
	Italy	Italy

	Email: sprevidi@cisco.com	Email: sprevidi@cisco.com

	Jon Mitchell	Jon Mitchell
	Unaffiliated	Unaffiliated

	US

	Email: jrmitche@puck.nether.net	Email: jrmitche@puck.nether.net

	Ebben Aries	Ebben Aries
	Facebook	Facebook
	US	US

	Email: exa@fb.com	Email: exa@fb.com

	Petr Lapukhov	Petr Lapukhov
	Facebook	Facebook
	US	US

	Email: petr@fb.com	Email: petr@fb.com


	Dmitry Afanasiev
	Yandex
	RU

	Email: fl0w@yandex-team.ru

	Tim Laberge
	Microsoft
	US

	Email: tim.laberge@microsoft.com

	Edet Nkposong
	Microsoft
	US

	Email: edetn@microsoft.com
	Mohan Nanduri
	Microsoft
	US

	Email: mnanduri@microsoft.com

	James Uttaro
	ATT
	US

	Email: ju1738@att.com

	Saikat Ray
	Unaffiliated
	US

	Email: raysaikat@gmail.com

End of changes. 25 change blocks.
	45 lines changed or deleted	88 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/