< draft-keyupate-bgp-services-00.txt		draft-keyupate-bgp-services-01.txt >
	Network Working Group K. Patel		Network Working Group K. Patel
	Internet-Draft J. Medved		Internet-Draft J. Medved
	Intended status: Standards Track R. Fernando		Intended status: Standards Track R. Fernando
	Expires: April 18, 2013 B. Pithawala		Expires: April 02, 2013 B. Pithawala
	Cisco Systems		Cisco Systems
	October 15, 2012		October 2012
	Service Advertisement using BGP		Service Advertisement using BGP
	draft-keyupate-bgp-services-00.txt		draft-keyupate-bgp-services-01.txt
	Abstract		Abstract
	A variety of services, such as NATs, firewalls, or caches, can be		A variety of services, such as NATs, firewalls, or caches, can be
	embedded in a service provider network or instantiated in data		embedded in a service provider network or instantiated in data
	centers attached to the network. This document proposes extensions		centers attached to the network. This document proposes extensions
	to BGP that facilitate discovery of such service instances by		to BGP that facilitate discovery of such service instances by
	interested clients and allows dissemination of service information,		interested clients and allows dissemination of service information,
	such as services capabilities or capacities, thoughtout the network		such as services capabilities or capacities, throughout the network
	domain. The proposed extensions allow for optimal routing of		domain. The proposed extensions allow for optimal routing of
	requests to service instances that can optimally serve them.		requests to service instances that can optimally serve them.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 18, 2013.		This Internet-Draft will expire on April 02, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 3, line 7 ¶		skipping to change at page 2, line 29 ¶
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Service Advertisement & Discovery . . . . . . . . . . . . . . 6		2. Service Advertisement & Discovery . . . . . . . . . . . . . . 5
	2.1. The Service Advertisement Attribute . . . . . . . . . . . 6		2.1. The Service Advertisement Attribute . . . . . . . . . . . 5
	3. Distribution of Service Data . . . . . . . . . . . . . . . . . 7		3. Distribution of Service Data . . . . . . . . . . . . . . . . . 6
	3.1. Capability Advertisement for Service AFI . . . . . . . . . 8		3.1. Capability Advertisement for Service AFI . . . . . . . . . 6
	3.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 8		3.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 6
	3.3. NLRI Format for Service AFI . . . . . . . . . . . . . . . 8		3.3. NLRI Format for Service AFI . . . . . . . . . . . . . . . 6
	3.4. The Service Attribute . . . . . . . . . . . . . . . . . . 9		3.4. The Service Attribute . . . . . . . . . . . . . . . . . . 7
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. Announcing BGP Service Discovery Attribute . . . . . . . . 9		4.1. Announcing BGP Service Discovery Attribute . . . . . . . . 7
	4.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 10		4.2. BGP Service AFI . . . . . . . . . . . . . . . . . . . . . 8
	5. Service Example . . . . . . . . . . . . . . . . . . . . . . . 10		5. Service Example . . . . . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The current BGP specification does NOT provide any generic mechanism		The current BGP specification does NOT provide any generic mechanism
	to advertise service instances within a BGP enabled network. The		to advertise service instances within a BGP enabled network. The
	current BGP specification also does NOT provide a mechanism to carry		current BGP specification also does NOT provide a mechanism to carry
	opaque service data within a BGP enabled network. This draft defines		opaque service data within a BGP enabled network. This draft defines
	several extensions to BGP that allows both the advertisement and the		several extensions to BGP that allows both the advertisement and the
	discovery of service instances and the distribution of service		discovery of service instances and the distribution of service
	related data within a BGP network.		related data within a BGP network.
	Service advertisement and discovery is facilitated by distributing		Service advertisement and discovery is facilitated by distributing
	Service Advertiser location information throughout the network. This		Service Advertiser location information throughout the network. This
	document proposes a new optional transitive attribute - the Service		document proposes a new optional transitive attribute - the Service
	Advertisement Attribute that carries addresses of BGP Speakers,		Advertisement Attribute that carries addresses of BGP Speakers,
	thereby faciliating the service advertisements and service discovery.		thereby facilitating the service advertisements and service
	Entities interested in receiving service information will peer with		discovery. Entities interested in receiving service information will
	one or more service-advertising BGP Speakers and receive service data		peer with one or more service-advertising BGP Speakers and receive
	directly from them.		service data directly from them.
	This draft also defines a new BGP Capability known as BGP Service AFI		This draft also defines a new BGP Capability known as BGP Service AFI
	Capability, a new BGP AFI and its NLRI format to carry opaque Service		Capability, a new BGP AFI and its NLRI format to carry opaque Service
	data within a BGP enabled network. BGP Service AFI leaverages		data within a BGP enabled network. BGP Service AFI leverages
	existing BGP machninery of message annoucements, processing of		existing BGP machinery of message announcements, processing of
	received messages, loop detection, policy application and other vital		received messages, loop detection, policy application and other vital
	protocol framework to transport Service information. Routers enabled		protocol framework to transport Service information. Routers enabled
	with Service AFI are expected to store Service information possibly		with Service AFI are expected to store Service information possibly
	as an opaque data.		as an opaque data.
	In addition to the service information discovery and dissemination		In addition to the service information discovery and dissemination
	mechanism, Pub/Sub APIs MAY be required for registration of service		mechanism, Pub/Sub APIs MAY be required for registration of service
	instances with the network entities. The definition of such Pub/Sub		instances with the network entities. The definition of such Pub/Sub
	APIs are outside the scope of this document.		APIs are outside the scope of this document.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	1.2. Terminology		1.2. Terminology
	This document uses the following terminology:		This document uses the following terminology:
	Service Instance: A Service application running on an end device or		Service Instance: A Service application running on an end device or
	on a network device. Service applications are bloadly classified		on a network device. Service applications are broadly classified
	into two categories: Network Services and Application Services.		into two categories: Network Services and Application Services.
	Service consumer: An end device or a network device that is a		Service consumer: An end device or a network device that is a
	interested in a particular Service.		interested in a particular Service.
	Gateway: An network device that is responsible for doing a service		Gateway: An network device that is responsible for doing a service
	conversion across different protocols.		conversion across different protocols.
	Originator: An end device or a network device originating a		Originator: An end device or a network device originating a
	particular service.		particular service.
	1.3. Overview		1.3. Overview
	In today's networks, both the services provided in the network (NATs,		In today's networks, both the services provided in the network (NATs,
	Firewalls, etc.) and the service overlays (services provided in		Firewalls, etc.) and the service overlays (services provided in
	enterprise or cloud data centers) are dynamic in nature. New service		enterprise or cloud data centers) are dynamic in nature. New service
	instances are instantiated on demand, instances that are not		instances are instantiated on demand, instances that are not
	sufficiently utilized are deleted and their resources are redeployed;		sufficiently utilized are deleted and their resources are redeployed;
	load and traffic patterns change frequently and abruptly; more and		load and traffic patterns change frequently and abruptly; more and
	skipping to change at page 6, line 5 ¶		skipping to change at page 4, line 34 ¶
	providers networks		providers networks
	o It can be used to distribute information within an AS domain or		o It can be used to distribute information within an AS domain or
	between AS domains		between AS domains
	o Leverage its security		o Leverage its security
	o Rich policy capabilities allow the operator to control the		o Rich policy capabilities allow the operator to control the
	distribution of service information		distribution of service information
	+----------+ +----------+ +----------+ +----------+		+----------+ +----------+ +----------+ +----------+
	| Service | | Service | | Service | | Service |		| Service | | Service | | Service | | Service |
	| Provider | | Provider | | Consumer | | Consumer |		| Provider | | Provider | | Consumer | | Consumer |
	+----+-----+ +----+-----+ +----------+ +----------+		+----+-----+ +----+-----+ +----------+ +----------+
	| | ^ ^		| | ^ ^
	| V | |		| V | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | Gateway | | Gateway | |		| | Gateway | | Gateway | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| | ^ |		| | ^ |
	V V _______ | |		V V _______ | |
	+-----------------+ / \ +-----------------+		+-----------------+ / \ +-----------------+
	| BGP Speaker |------>* Network *------>| BGP Speaker |		| BGP Speaker |------>* Network *------>| BGP Speaker |
	+-----------------+ \_______/ +-----------------+		+-----------------+ \_______/ +-----------------+
	Figure 1: Service discovery and metadata exchange		Figure 1: Service discovery and metadata exchange
	Figure 1 shows a typical service network where services consumers		Figure 1 shows a typical service network where services consumers
	interact with each other over a network. As shown in the figure, a		interact with each other over a network. As shown in the figure, a
	Service Provider may inject service information into BGP either		Service Provider may inject service information into BGP either
	directly or through a Gateway. BGP then distributes the Service		directly or through a Gateway. BGP then distributes the Service
	information within its network. Service information may also be		information within its network. Service information may also be
	distributed across the AS domains. A Service consumer receives		distributed across the AS domains. A Service consumer receives
	Information about available services either directly by listening to		Information about available services either directly by listening to
	BGP updates or through a Gateway. Gateways may provide different		BGP updates or through a Gateway. Gateways may provide different
	APIs to Service Providers/Consumers, for example ReST, XMPP, or		APIs to Service Providers/Consumers, for example ReST, XMPP, or
	Websockets.		Websockets.
	A Gateway translates between an application-friendly data format /		A Gateway translates between an application-friendly data format /
	API on the Service Provider/Consumer Side, and a BGP-specific format		API on the Service Provider/Consumer Side, and a BGP-specific format
	on the BGP Speaker side. The BGP-specific format would use BGP		on the BGP Speaker side. The BGP-specific format would use BGP
	protocol (i.e the Gaetway appears as a peer to the BGP Speaker) or an		protocol (i.e the Gateway appears as a peer to the BGP Speaker) or an
	API that can inject/retrieve data directly from BGP internal		API that can inject/retrieve data directly from BGP internal
	databases, such as IRS.		databases, such as IRS.
	2. Service Advertisement & Discovery		2. Service Advertisement & Discovery
	2.1. The Service Advertisement Attribute		2.1. The Service Advertisement Attribute
	The Service Advertisement attribute is a new BGP optional transitive		The Service Advertisement attribute is a new BGP optional transitive
	attribute. The attribute type code for the Service Advertisement		attribute. The attribute type code for the Service Advertisement
	attribute is to be assigned by IANA. The value field of the Service		attribute is to be assigned by IANA. The value field of the Service
	Advertisement attribute is defined as set of one or more Service		Advertisement attribute is defined as set of one or more Service
	Tuples.		Tuples.
	A Service Tuple within the Service Advertisement Attribute is defined		A Service Tuple within the Service Advertisement Attribute is defined
	as follows:		as follows:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Service ID ~		| Service Type ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Service ID (Cont'd) |		~ Service Type (Cont'd) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Orig-ID Type | Orig-ID Len | Originator-ID ~		| Orig-ID Type | Orig-ID Len | Originator-ID ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Originator-ID ~		~ Originator-ID ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Service Tuple format		Figure 2: Service Tuple format
	The fields are as follows:		The fields are as follows:
	Service ID: Eight octets encoding the Service ID. The Service ID		Service Type: Eight octets encoding the Service Type. The Service
	code point space will have to be maintained by IANA. Only type 1		Type code point space will have to be maintained by IANA. Only
	is defined in this document. Service ID from 4294967296 onwards		type 1 is defined in this document.
	are reserved for private use only.
	Originator-ID Type: One octet encoding the Originator-ID Type. Type		Originator-ID Type: One octet encoding the Originator-ID Type. Type
	value of 0 indicates an IPv4 address type, Type value of 1		value of 0 indicates an IPv4 address type, Type value of 1
	indicates an IPv6 address type, and Type value of 2 indicates an		indicates an IPv6 address type, and Type value of 2 indicates an
	AS number type.		AS number type.
	Originator-ID Length: One octet encoding the Originator-ID address		Originator-ID Length: One octet encoding the Originator-ID address
	length. Orignator-ID is not present in the Service Tuple if the		length. Originator-ID is not present in the Service Tuple if the
	Originator-ID Length is 0.		Originator-ID Length is 0.
	Originator-ID: Optional, contains the IP address of the router		Originator-ID: Optional, contains the IP address of the router
	Originating the Service Tuple. If the advertising router's IP		Originating the Service Tuple. If the advertising router's IP
	address is not present, then the Originator of the Service		address is not present, then the Originator of the Service
	Advertisement attribute is the first AS aka rightmost AS in the		Advertisement attribute is the first AS aka rightmost AS in the
	final segment of an ASPATH attribute if that segment is of type		final segment of an ASPATH attribute if that segment is of type
	AS_SEQUENCE, or the distinguished value "NONE" if the final		AS_SEQUENCE, or the distinguished value "NONE" if the final
	segment of the AS_PATH attribute is of any type other than		segment of the AS_PATH attribute is of any type other than
	AS_SEQUENCE. Originator ID length of 4 octets indicate an IPv4		AS_SEQUENCE. Originator ID length of 4 octets indicate an IPv4
	Address and 16 octets indicates an IPv6 address		Address and 16 octets indicates an IPv6 address
	The service attribute applies to all prefixes carried in an UPDATE		The service attribute applies to all prefixes carried in an UPDATE
	message - either in IPv4 NLRI or in MP_REACH/MP_UNREACH attributes.		message - either in IPv4 NLRI or in MP_REACH/MP_UNREACH attributes.
	3. Distribution of Service Data		3. Distribution of Service Data
	3.1. Capability Advertisement for Service AFI		3.1. Capability Advertisement for Service AFI
	The BGP Service AFI Capability is a new BGP capability, that can be		The BGP Service AFI Capability is a new BGP capability, that can be
	used by a BGP speaker to indicate its support for BGP Service AFI		used by a BGP speaker to indicate its support for BGP Service AFI
	Advertisements. A BGP speaker willing to exchange this capability		Advertisements. A BGP speaker willing to exchange this capability
	MUST advertise this information in the OPEN message using BGP		MUST advertise this information in the OPEN message using BGP
	Capability code 1 [RFC4760]. The AFI value is set to BGP Service AFI		Capability code 1 [RFC4760]. The AFI value is set to BGP Service AFI
	value to be assigned by IANA. The SAFI value is set to UNICAST		value to be assigned by IANA. The SAFI value is set to UNICAST value.
	value.
	3.2. BGP Service AFI		3.2. BGP Service AFI
	This document introduces a new AFI known as a BGP Service AFI with a		This document introduces a new AFI known as a BGP Service AFI with a
	value to be assigned by IANA. The purpose of this AFI would be to		value to be assigned by IANA. The purpose of this AFI would be to
	exchange Service specific information within a BGP network. The SAFI		exchange Service specific information within a BGP network. The SAFI
	value is set to UNICAST value as defined in IANA SAFI registry.		value is set to UNICAST value as defined in IANA SAFI registry.
	3.3. NLRI Format for Service AFI		3.3. NLRI Format for Service AFI
	BGP Service AFI NLRI is advertised in BGP UPDATE messages using the		BGP Service AFI NLRI is advertised in BGP UPDATE messages using the
	MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The AFI used		MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The AFI used
	to identify this NRLI is BGP Service AFI with a value to be assigned		to identify this NRLI is BGP Service AFI with a value to be assigned
	by IANA. The SAFI value is set to UNICAST value as defined in IANA		by IANA. The SAFI value is set to UNICAST value as defined in IANA
	SAFI registry.		SAFI registry.
	The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as		The Next Hop field of MP_REACH_NLRI attribute shall be interpreted as
	an IPv4 address whenever the length of the Next Hop address is 4		an IPv4 address whenever the length of the Next Hop address is 4
	octets, and as an IPv6 address whenever the length of the Next Hop		octets, and as an IPv6 address whenever the length of the Next Hop
	address is 16 octets.		address is 16 octets.
	The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix		The NLRI field in the MP_REACH_NLRI and MP_UNREACH_NLRI is a prefix
	with the maximum length of 276 octets. The NLRI field of the		with the maximum length of 255 octets. The NLRI field of the
	MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1-octet NLRI length		MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as a 1-octet NLRI length
	field in bytes followed by a variable-length NLRI value. The NLRI		field in bytes followed by a variable-length NLRI value. The NLRI
	length is expressed in octets.		length is expressed in octets.
	+--------------------------------+		+--------------------------------+
	| length (1 octet) |		| Length (1 octet) |
	+--------------------------------+		+--------------------------------+
	| NLRI value (variable) |		| NLRI value (variable) |
	+--------------------------------+		+--------------------------------+
	Figure 3: Service NLRI		Figure 3: Service NLRI
	The Length field indicates the length of NLRI value in octets.		The Length field indicates the length of NLRI value in octets.
	The NLRI Format is as follows:		The NLRI Format is as follows:
	+--------------------------------+		+--------------------------------+
	| AS Number (4 octets) |		| AS Number (4 octets) |
	+--------------------------------+		+--------------------------------+
	| Originator ID (16 octets) |		| Originator ID (16 octets) |
	+--------------------------------+		+--------------------------------+
	~ Service ID ~		| Service Type (8 octets) |
	~ Variable (up to 235 Octets) ~		+--------------------------------+
	+--------------------------------+		~ Service ID ~
			~ Variable (up to 227 Octets) ~
			+--------------------------------+
	Figure 4: Service NLRI format		Figure 4: Service NLRI format
	The fields in the Service NLRI are as follows:		The fields in the Service NLRI are as follows:
	AS Number: Four octets encoding the AS Number of an Autonomous		AS Number: Four octets encoding the AS Number of an Autonomous System
	System originating the prefix. The AS Number value will be the		originating the prefix. The AS Number value will be the value
	value assigned by IANA.		assigned by IANA.
	Originator ID: 16 Octets encoding the Originator ID value.		Originator ID: 16 Octets encoding the Originator ID value.
	Service ID: Upto 235 octets encoding the Service ID value.		Service ID: up to 227 octets encoding the Service ID value.
	3.4. The Service Attribute		3.4. The Service Attribute
	The Service attribute is a new BGP optional transitive attribute.		The Service attribute is a new BGP optional transitive attribute.
	The attribute type code for the Service attribute is to be assigned		The attribute type code for the Service attribute is to be assigned
	by IANA. The Service attribute carries BGP Service AFI NLRI specific		by IANA. The Service attribute carries BGP Service AFI NLRI specific
	information. The value field of the Service attribute contains		information. The value field of the Service attribute is defined as
	service specific data opaque to BGP.		set of one or more Service Tuples.
	4. Operation		4. Operation
	4.1. Announcing BGP Service Discovery Attribute		4.1. Announcing BGP Service Discovery Attribute
	The Service Discovery attribute is used to announce/withdraw new		The Service Discovery attribute is used to announce/withdraw new
	Service instances within a network. The Service Discovery attribute		Service instances within a network. The Service Discovery attribute
	is a new optional transitive attribute that can be applied to any		is a new optional transitive attribute that can be applied to any AFI
	AFI/SAFI within BGP; thereby facilitating service instance discovery		/SAFI within BGP; thereby facilitating service instance discovery on
	on an existing network. The attribute is not related to the AFI/SAFI		an existing network. The attribute is not related to the AFI/SAFI to
	to which it is attached, and it does not impact the BGP selection		which it is attached, and it does not impact the BGP selection
	algorithm. The AFI/SAFI is used merely as a distribution mechanism		algorithm. The AFI/SAFI is used merely as a distribution mechanism
	for Service Advertiser information carried in the attribute.		for Service Advertiser information carried in the attribute.
	A BGP Speaker MUST aggregate all the Service attribute Tuple		A BGP Speaker MUST aggregate all the Service attribute Tuple
	information received from all the paths (including the non-bestpaths)		information received from all the paths (including the non-bestpaths)
	for a given NLRI and announce the aggregated Service information		for a given NLRI and announce the aggregated Service information
	along with the bestpath in case where all the BGP paths [ADDPATHS]		along with the bestpath in case where all the BGP paths [ADDPATHS]
	are not being announced. A BGP Speaker MUST announce BGP Service		are not being announced. A BGP Speaker MUST announce BGP Service
	attribute along with its own path whenever all the paths [ADDPATHS]		attribute along with its own path whenever all the paths [ADDPATHS]
	are announced. These rules ensure that Service Discovery attributes		are announced. These rules ensure that Service Discovery attributes
	skipping to change at page 10, line 39 ¶		skipping to change at page 8, line 53 ¶
	to have a separate session to transport its opaque data and thereby		to have a separate session to transport its opaque data and thereby
	not affect the performance of existing routing AFI/SAFIs within BGP.		not affect the performance of existing routing AFI/SAFIs within BGP.
	5. Service Example		5. Service Example
	It is assumed that service-specific attributes and NLRIs will be		It is assumed that service-specific attributes and NLRIs will be
	defined in their own documents. Each service needs to advertise its		defined in their own documents. Each service needs to advertise its
	reachability, capacities and capabilities. This section provides an		reachability, capacities and capabilities. This section provides an
	example of a service - a simple caching service.		example of a service - a simple caching service.
	It is assumed that the Service ID will be allocated by IANA for the		It is assumed that the Service Type will be allocated by IANA for the
	simple caching service.		simple caching service.
	The simple caching service will only advertise service availability		The simple caching service will only advertise service availability
	during service discovery using the Service Advertisement Attribute		during service discovery using the Service Advertisement Attribute
	(Section 2.1). A simple cache service instance is identified by its		(Section 2.1). A simple cache service instance is identified by its
	IPv4 and IPv6 addresses. The Service ID in the Service NLRI		IPv4 and IPv6 addresses. The Service ID in the Service NLRI (Figure
	(Figure 3) is defined as follows:		3) is defined as follows:
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Service IPv4 address |		| Service IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Service IPv6 Address |		| Service IPv6 Address |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: Service ID for simple cache service		Figure 5: Service ID for simple cache service
	A simple cache service instance advertises its capacities and		A simple cache service instance advertises its capacities and
	capabilities as TLVs in the service Attribute (Section 3.4). The TLV		capabilities as TLVs in the service Attribute (Section 3.4). The TLV
	data is opaque to the BGP speaker. The TLVs are as follows:		data is opaque to the BGP speaker. The TLVs are as follows:
	Load: Identifies the current load of the cache; the bigger the load,		Load: Identifies the current load of the cache; the bigger the load,
	the less prefered is this instance of the service. Load is an		the less preferred is this instance of the service. Load is an
	interger in the range 0-100. which shows the percentage of the		integer in the range 0-100. which shows the percentage of the
	capacity of the service instance is currently being used by		capacity of the service instance is currently being used by
	clients.		clients.
	Supported media types: This TLVs lists all media types that can be		Supported media types: This TLVs lists all media types that can be
	served from this cache instance. There is a sub-TLV for each		served from this cache instance. There is a sub-TLV for each
	media type.		media type.
	Protocols: This TLVs lists all protocol types that can be used to		Protocols: This TLVs lists all protocol types that can be used to
	serve content from this cache instance. There is a sub-TLV for		serve content from this cache instance. There is a sub-TLV for
	each protocol type.		each protocol type.
	Simple cache service instance advertisements are injected into BGP by		Simple cache service instance advertisements are injected into BGP by
	simple cache instances throguh a gateway or a proxy providing an XMPP		simple cache instances through a gateway or a proxy providing an XMPP
	or RESTful API. Simple cache service instance advertisements are		or RESTful API. Simple cache service instance advertisements are
	received by a service router, which directs client requests to the		received by a service router, which directs client requests to the
	most appropriate instance of the cache.		most appropriate instance of the cache.
	6. IANA Considerations		6. Acknowledgements
			The authors would like to thank David Ward and Stefano Previdi for
			their review and comments.
			7. IANA Considerations
			8. Security Considerations
			This extension to BGP does not change the underlying security issues
			inherent in the existing [RFC4724] and [RFC4271]
			9. IANA Considerations
	This document requests a code point from the registry of Address		This document requests a code point from the registry of Address
	Family Numbers.		Family Numbers.
	This document requests a code point from the BGP Path Attributes		This document requests a code point from the BGP Path Attributes
	registry.		registry.
	This document requests creation of a new registry for service type		This document requests creation of a new registry for service type
	codepoints. Allocations within the registry will require		codepoints. Allocations within the registry will require
	documentation of the proposed use of the allocated value and approval		documentation of the proposed use of the allocated value and approval
	by the Designated Expert assigned by the IESG (see [RFC5226]).		by the Designated Expert assigned by the IESG (see [RFC5226]).
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	7. Security Considerations		10. Contributors
	This extension to BGP does not change the underlying security issues
	inherent in the existing [RFC4724] and [RFC4271]
	8. Acknowledgements
	The authors would like to thank .... for the review and comments.
	9. Contributors
	The following individuals contributed content and ideas to this		The following individuals contributed content and ideas to this
	document:		document:
	David Ward		11. References
	10. References
	10.1. Normative References		11.1. Normative References
	[I-D.ietf-idr-bgp-multisession]		[I-D.ietf-idr-bgp-multisession]
	Scudder, J., Appanna, C., and I. Varlashkin, "Multisession		Scudder, J., Appanna, C., and I. Varlashkin, "Multisession
	BGP", draft-ietf-idr-bgp-multisession-07 (work in		BGP", Internet-Draft draft-ietf-idr-bgp-multisession-07,
	progress), September 2012.		September 2012.
	[RFC1998] Chen, E. and T. Bates, "An Application of the BGP		[RFC1998] Chen, E. and T. Bates, "An Application of the BGP
	Community Attribute in Multi-home Routing", RFC 1998,		Community Attribute in Multi-home Routing", RFC 1998,
	August 1996.		August 1996.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,		[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
	September 2000.		September 2000.
	skipping to change at page 13, line 16 ¶		skipping to change at page 11, line 10 ¶
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, February 2006.		Communities Attribute", RFC 4360, February 2006.
	[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.		[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
	Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,		Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
	January 2007.		January 2007.
	[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,		[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
	"Multiprotocol Extensions for BGP-4", RFC 4760,		"Multiprotocol Extensions for BGP-4", RFC 4760, January
	January 2007.		2007.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	10.2. Informative References		11.2. Informative References
	[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease		[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease
	Notification Message", RFC 4486, April 2006.		Notification Message", RFC 4486, April 2006.
	Authors' Addresses		Authors' Addresses
	Keyur Patel		Keyur Patel
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: keyupate@cisco.com		Email: keyupate@cisco.com
	Jan Medved		Jan Medved
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: jmedved@cisco.com		Email: jmedved@cisco.com
	Rex Fernando		Rex Fernando
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: bpithaw@cisco.com		Email: bpithaw@cisco.com
	Burjiz Pithawala		Burjiz Pithawala
	Cisco Systems		Cisco Systems
	170 W. Tasman Drive		170 W. Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: bpithaw@cisco.com		Email: bpithaw@cisco.com
End of changes. 60 change blocks.
	138 lines changed or deleted		139 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/