< draft-ouldbrahim-bgpgmpls-ovpn-01.txt		draft-ouldbrahim-bgpgmpls-ovpn-02.txt >
	Provider Provisioned VPN WG Hamid Ould-Brahim		Provider Provisioned VPN WG Hamid Ould-Brahim
	Internet Draft Nortel Networks		Internet Draft Nortel Networks
	Expiration Date: January 2002		Expiration Date: May 2002
	Yakov Rekhter		Yakov Rekhter
	Juniper Networks		Juniper Networks
	- Editors		- Editors
	Don Fedyk		Don Fedyk
	Peter Ashwood-Smith		Peter Ashwood-Smith
	Nortel Networks		Nortel Networks
	Eric C. Rosen		Eric C. Rosen
	skipping to change at page 2, line ? ¶		skipping to change at page 2, line ? ¶
	John Drake		John Drake
	Calient Networks		Calient Networks
	Yong Xue		Yong Xue
	UUNET/WorldCom		UUNET/WorldCom
	Riad Hartani		Riad Hartani
	Caspian Networks		Caspian Networks
	July 2001		Dimitri Papadimitrio
			Alcatel
	BGP/GMPLS Optical VPNs		November 2001
	draft-ouldbrahim-bgpgmpls-ovpn-01.txt		BGP/GMPLS Optical/TDM VPNs
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026 [RFC-2026], except		with all provisions of Section 10 of RFC2026 [RFC-2026], except
	that the right to produce derivative works is not granted.		that the right to produce derivative works is not granted.
	Internet-Drafts are working documents of the Internet		Internet-Drafts are working documents of the Internet
	Engineering Task Force (IETF), its areas, and its working		Engineering Task Force (IETF), its areas, and its working
	groups. Note that other groups may also distribute working
	documents as Internet-Drafts.
	Ould-Brahim, et. al 1		Ould-Brahim, et. al 1
	draft-ouldbrahim-bgpgmpls-ovpn-01.txt July 2001		draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
			groups. Note that other groups may also distribute working
			documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other		months and may be updated, replaced, or obsoleted by other
	documents at any time. It is inappropriate to use Internet-		documents at any time. It is inappropriate to use Internet-
	Drafts as reference material or to cite them other than as		Drafts as reference material or to cite them other than as
	"work in progress."		"work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed		The list of Internet-Draft Shadow Directories can be accessed
	at http://www.ietf.org/shadow.html.		at http://www.ietf.org/shadow.html.
	Abstract		Abstract
	Consider a service provider network that offers Optical Virtual		Consider a service provider network that offers Optical/TDM
	Private Network (OVPN) service. An important goal in the OVPN		Virtual Private Network service. An important goal of such
	service is the ability to support what is known as "single end		service is the ability to support what is known as "single end
	provisioning", where addition of a new port to a given OVPN		provisioning", where addition of a new port to a given
	would involve configuration/provisioning changes only on the		Optical/TDM VPN would involve configuration changes only on the
	devices connected to that port. Another important goal in the		devices connected to that port. Another important goal in the
	OVPN service is the ability to establish/terminate an optical		Optical/TDM VPN service is the ability to establish/terminate
	connection between a pair of (existing) ports within an OVPN		an optical connection between a pair of (existing) ports within
	without involving configuration/provisioning changes in any of		an Optical/TDM VPN without involving configuration changes in
	the provider devices.		any of the provider devices.
	In this document we describe a set of mechanisms that		In this document we describe a set of mechanisms that
	accomplishes these goals.		accomplishes these goals.
	Obsoletes draft-fedyk-bgpvpon-auto-00.txt
	1. Sub-IP Summary ID		1. Sub-IP Summary ID
	This ID targets the PPVPN working group as it deals with a VPN		This ID targets the PPVPN working group as it deals with a VPN
	solution similar to port-based VPNs. It describes an approach		solution similar to port-based VPNs. It describes an approach
	to allow service providers to offer optical VPN service. A pair		to allow service providers to offer optical VPN service. A pair
	of client devices (a router, a SONET/SDH cross-connect, or an		of client devices (a router, a SONET/SDH cross-connect, or an
	Ethernet switch) could be connected through the service		Ethernet switch) could be connected through the service
	provider network via an optical connection. It is this optical		provider network via an optical connection. It is this optical
	connection that forms the basic unit of service that the		connection that forms the basic unit of service that the
	service provider network offers.		service provider network offers.
	RELATED DOCUMENTS		RELATED DOCUMENTS
	draft-ouldbrahim-ovpn-requirements-00.txt. Others can be found		draft-ouldbrahim-ovpn-requirements-00.txt. Others can be found
	in the "references" section.		in the "references" section.
	WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK		WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	Fits the PPVPN box.		Fits the PPVPN box.
	WHY IS IT TARGETED AT THIS WG		WHY IS IT TARGETED AT THIS WG
	This WG is looking at port based VPN over an IP/MPLS		This WG is looking at port based VPN over an IP/MPLS
	infrastructure. This work is exactly a port-based optical VPN		infrastructure. This work is exactly a port-based optical VPN
	using IP related building blocks.		using IP related building blocks.
	JUSTIFICATION		JUSTIFICATION
	The current PPVPN chairs have already discussed this work and		The current PPVPN chairs have already discussed this work and
	are considering expanding the PPVPN charter to include OVPN as		are considering expanding the PPVPN charter to include OVPN as
	part of PPVPN mandate.		part of PPVPN mandate.
	2. Optical VPN Reference Model		2. Optical/TDM VPN Reference Model
	Consider a service provider network that consists of devices		Consider a service provider network that consists of devices
	such as Optical Network Element (ONE) which may be Optical		such as Optical Network Element (ONE) which may be Optical
	Cross Connects (OXCs). We partition these devices into P		Cross Connects (OXCs). Following the framework suggested in
	(provider) ONEs and PE (provider edge) ONEs. The P ONEs are		[PPVPN-FRAMEWORK], we partition these devices into P (provider)
	connected only to the ONEs within the provider's network. The		ONEs and PE (provider edge) ONEs. The P ONEs are connected only
	PE ONEs are connected to the ONEs within the provider network,		to the ONEs within the provider's network. The PE ONEs are
	as well as to the devices outside of the provider network.		connected to the ONEs within the provider network, as well as
	We'll refer to such other devices as Client Edge Devices (CEs).		to the devices outside of the provider network. We'll refer to
	An example of a CE would be a router, or a SONET/SDH cross-		such other devices as Client Edge Devices (CEs). An example of
	connect, or an Ethernet switch.		a CE would be a router, or a SONET/SDH cross-connect, or an
			Ethernet switch.
			While the rest of this document mostly focuses on the scenarios
			where the service provider network consists of ONEs and ports
			are connected via optical connections, the mechanisms described
			in this document could be applied in an environment, where the
			service provider network consists of SONET/SDH cross connects
			and CE ports being either SONET/SDH or Ethernet.
	+---+ +---+		+---+ +---+
	| P |....| P |		| P |....| P |
	+---+ +---+		+---+ +---+
	PE / \ PE		PE / \ PE
	+-----+ +-----+ +--+		+-----+ +-----+ +--+
	| | | |----| |		| | | |----| |
	+--+ | | | | |CE|		+--+ | | | | |CE|
	|CE|----+-----+ | |----| |		|CE|----+-----+ | |----| |
	+--+\ | | | +--+		+--+\ | | | +--+
	\ +-----+ | |		\ +-----+ | |
	\ | | | | +--+		\ | | | | +--+
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	\| | | |----|CE|		\| | | |----|CE|
	+-----+ +-----+ +--+		+-----+ +-----+ +--+
	\ /		\ /
	+---+ +---+		+---+ +---+
	| P |....| P |		| P |....| P |
	+---+ +---+		+---+ +---+
	Figure 1 Optical VPN Reference Model		Figure 1 Optical VPN Reference Model
	A CE is connected to a PE ONE via one or more links, where each		A CE is connected to a PE ONE via one or more links, where each
	link may consists of one or more channels or sub-channels		link may consists of one or more channels or sub-channels
	(e.g., wavelength or wavelength and timeslot respectively).		(e.g., wavelength or wavelength and timeslot respectively). In
			the context of this document a link is a logical construct that
			is used to represent grouping on a per VPN basis of physical
			resources used to connect a CE to a PE ONE.
	For purpose of this discussion we assume that all the channels		For purpose of this discussion we assume that all the channels
	within a given link have shared similar characteristics (e.g.,		within a given link have shared similar characteristics (e.g.,
	bandwidth, encoding, etc_), and can be interchanged from the		bandwidth, encoding, etc_), and can be interchanged from the
	CEs point of view. Channels on different links of a CE need not		CEs point of view. Channels on different links of a CE need not
	have the same characteristics.		have the same characteristics.
	There may be more than one link between a given CE PE ONE pair.		There may be more than one link between a given CE PE ONE pair.
	A CE may be connected to more than one PE ONE (with at least		A CE may be connected to more than one PE ONE (with at least
	one port per each PE ONE). And, of course, a PE ONE may have		one port per each PE ONE). And, of course, a PE ONE may have
	more than one CE connected to it.		more than one CE connected to it.
	If a CE is connected to a PE ONE via multiple links and all		If a CE is connected to a PE ONE via multiple links and all
	these links belong to the same VPN, then for the purpose of		these links belong to the same VPN, then for the purpose of
	OVPN these links could be treated as a single link using the		OVPN these links could be treated as a single link using the
	link bundling constructs [LINK-BUNDLING].		link bundling constructs [LINK-BUNDLING].
	In general a link may have only data bearing channels, or only		In general a link may have only data bearing channels, or only
	control bearing channels, or both. For the purpose of this		control bearing channels, or both. For the purpose of this
	discussion we assume that for a given CE - PE ONE pair at least		discussion we assume that for a given CE - PE ONE pair at least
	one of the links between them has at least one control bearing		one of the links between them has at least one data bearing
	channel and at least one data bearing channel.		channel, and at least one control bearing channel, or there is
			an IP connectivity between the CE and the PE that could be used
			for exchanging control information (more on this in Section 4).
	A link has two end-points - one on CE and one on PE ONE. In the		A link has two end-points - one on CE and one on PE ONE. In the
	context of this document we'll refer to the former as "CE		context of this document we'll refer to the former as "CE
	port", and to the latter as "PE ONE port". From the above it		port", and to the latter as "PE ONE port". From the above it
	follows that a CE is connected to a PE ONE via one or more		follows that a CE is connected to a PE ONE via one or more
	ports, where each port may consists of one or more channels or		ports, where each port may consists of one or more channels or
	sub-channels (e.g., wavelength or wavelength and timeslot		sub-channels (e.g., wavelength or wavelength and timeslot
	respectively), and all the channels within a given port have		respectively), and all the channels within a given port have
	shared similar characteristics (e.g., bandwidth, encoding,		shared similar characteristics (e.g., bandwidth, encoding,
	etc_), and can be interchanged from the CEs point of view.		etc_), and can be interchanged from the CEs point of view.
	Channels on different ports of a CE need not have the same		Channels on different ports of a CE need not have the same
	characteristics.		characteristics. Just like links, in the context of this
			document ports are logical construct that
	Note that in the context of this document both ports and links		draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	are logical constructs, and are used to represent grouping of
	physical resources per OVPN basis that are used to connect a CE		are used to represent grouping of physical resources on a per
	to a PE ONE. At any given point in time, a given port on a PE		OVPN basis that are used to connect a CE to a PE ONE.
	ONE is associated with at most one OVPN. This association is
	established and maintained by the service provider provisioning		At any given point in time, a given port on a PE ONE is
	system.		associated with at most one OVPN, or to be more precise with at
			most one Port Information Table (although different ports on a
			given PE ONE could be associated with different OVPNs, or to be
			more precise with different Port Information Tables) This
			association is established and maintained by the service
			provider provisioning system.
	A pair of CEs could be connected through the service provider		A pair of CEs could be connected through the service provider
	network via an optical connection. It is precisely this optical		network via an optical connection. It is precisely this optical
	connection that forms the basic unit of service that the		connection that forms the basic unit of the OVPN service that
	service provider network offers. If a port by which a CE is		the service provider network offers. If a port by which a CE is
	connected to a PE ONE consists of multiple channels (e.g.,		connected to a PE ONE consists of multiple channels (e.g.,
	multiple wavelengths), the CE could establish optical		multiple wavelengths), the CE could establish optical
	connection to multiple other CEs over this single port.		connection to multiple other CEs over this single port.
	An important goal in the OVPN service is the ability to support		An important goal in the OVPN service is the ability to support
	what is known as "single end provisioning", where addition of a		what is known as "single end provisioning", where addition of a
	new port to a given OVPN would involve		new port to a given OVPN would involve configuration changes
	configuration/provisioning changes only on the PE ONE that has		only on the PE ONE that has this port and on the CE that is
	this port and on the CE that is connected to the PE ONE via		connected to the PE ONE via this port. Another important goal
	this port. Another important goal in the OVPN service is the		in the OVPN service is the ability to establish/terminate an
	ability to establish/terminate an optical connection between a		optical connection between a pair of (existing) ports within an
	pair of (existing) ports within an OVPN without involving		OVPN without involving configuration changes in any of the
	configuration/provisioning changes in any of the provider's		provider's ONEs. The mechanisms outlined in this document aim
	ONEs. The mechanisms outlined in this document aim at achieving		at achieving these goals. Specifically, as part of the Optical
	these goals. Specifically, as part of the Optical VPN service		VPN service offering, these mechanisms (1) enable the service
	offering, these mechanisms (1) enable the service provider to		provider to restrict the set of ports that a given port could
	restrict the set of ports that a given port could be connected		be connected to, (2) enable the service provider to provide a CE
	to, (2) enable the service provider to provide a CE with the		with the information about the ports that the CE could be
	information about the ports that the CE could be connected, (3)		connected, (3) enable a CE to establish the actual connections
	enable a CE to establish the actual connections to a subset of		to a subset of ports provided by (2). Finally, the mechanisms
	ports provided by (2). Finally, the mechanisms allow different		allow different OVPN topologies to be supported ranging from
	OVPN topologies to be supported ranging from hub-and-spoke to		hub-and-spoke to complete mesh.
	complete mesh.
	The service provider does not initiate the creation of an		The service provider does not initiate the creation of an
	optical circuit between a pair of PE ONE ports. This is done		optical circuit between a pair of PE ONE ports. This is done
	rather by the CEs, which attach to the ports. However, the SP,		rather by the CEs, which attach to the ports. However, the SP,
	by using the mechanisms outlined in this document, restricts		by using the mechanisms outlined in this document, restricts
	the set of other PE ONE ports which may be the remote endpoints		the set of other PE ONE ports which may be the remote endpoints
	of optical circuits that have the given port as the local		of optical circuits that have the given port as the local
	endpoint. Subject to these restrictions, the CE-to-CE		endpoint. Subject to these restrictions, the CE-to-CE
	connectivity is under the control of the CEs themselves. In		connectivity is under the control of the CEs themselves. In
	other words, SP allows an OVPN to have a certain set of		other words, SP allows an OVPN to have a certain set of
	topologies, and CE-initiated signaling is used to choose a		topologies (expressed as a port-to-port connectivity matrix),
	particular topology from that set.		and CE-initiated signaling is used to choose a particular
			topology from that set.
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	Since this model involves minimal provisioning changes when		Since this model involves minimal provisioning changes when
	changing the connectivity among the ports within a OVPN on the		changing the connectivity among the ports within a OVPN on the
	providers network and the OVPNs themselves are controlled by		providers network and the OVPNs themselves are controlled by
	the CEs, the tariff structure may be on a port basis or		the CEs, the tariff structure may be on a port basis or
	alternatively tariffs could be triggered on the basis of		alternatively tariffs could be triggered on the basis of
	signaling mechanisms.		signaling mechanisms.
	Finally, it is assumed that CE-to-CE optical connectivity is		Finally, it is assumed that CE-to-CE optical connectivity is
	based on GMPLS [GMPLS].		based on GMPLS [GMPLS].
	3. Overview of operations		3. Overview of operations
	This document assumes that within a given OVPN each port on a		This document assumes that within a given OVPN each port on a
	CE that connects the CE to a PE ONE has an identifier that is		CE that connects the CE to a PE ONE has an identifier that is
	unique within that OVPN (but need not be unique across several		unique within that OVPN (but need not be unique across several
	OVPNs). One way to accomplish this is to assign each port an IP		OVPNs). One way to accomplish this is to assign each port an IP
	address that is unique within a given OVPN, and use this		address that is unique within a given OVPN, and use this
	address as a port identifier. Another way to accomplish this is		address as a port identifier. Another way to accomplish this is
	to assigned each port an interface index that is unique within		to assigned each port on a CE an index that is unique within
	a given CE, assign each CE an IP address that is unique within		that CE, assign each CE an IP address that is unique within a
	a given OVPN, and then use a tuple <interface index, CE IP		given OVPN, and then use a tuple <port index, CE IP address> as
	address> as a port identifier.		a port identifier.
	This document assumes that within a service provider network,		This document assumes that within a service provider network,
	each port on a PE ONE has an identifier that is unique within		each port on a PE ONE has an identifier that is unique within
	that network. One way to accomplish this would be to assign		that network. One way to accomplish this would be to assign
	each port on a PE ONE an interface index, assign each PE ONE an		each port on a PE ONE an index that is unique within that PE
	IP address that is unique within the service provider network		ONE, assign each PE ONE an IP address that is unique within the
	(in the case of multi-provider operations, the address has to		service provider network (in the case of multi-provider
	be unique across all the providers involved), and then use a		operations, the address has to be unique across all the
	tuple <interface index, PE ONE IP address> as a port identifier		providers involved), and then use a tuple <port index, PE ONE
	within the provider network.		IP address> as a port identifier within the provider network.
	PE ONE PE ONE		PE ONE PE ONE
	+---------+ +--------------+		+---------+ +--------------+
	+--------+ | +------+| | +----------+ | +--------+		+--------+ | +------+| | +----------+ | +--------+
	| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |		| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
	| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |		| CE1 |--| |PIT || BGP route | | PIT | |-| CE2 |
	+--------+ | | ||<----------->| | | | +--------+		+--------+ | | ||<----------->| | | | +--------+
	| +------+| Distribution| +----------+ |		| +------+| Distribution| +----------+ |
	| | | |		| | | |
	+--------+ | +------+| -------- | +----------+ | +--------+		+--------+ | +------+| -------- | +----------+ | +--------+
	| VPN-B | | |VPN-B || ( Optical ) | | VPN-B | | | VPN-B |		| VPN-B | | |VPN-B || ( Optical ) | | VPN-B | | | VPN-B |
	| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |		| CE1 |--| |PIT ||-( GMPLS )-| | PIT | |-| CE2 |
	+--------+ | | || (Backbone ) | | | | +--------+		+--------+ | | || (Backbone ) | | | | +--------+
	| +------+| --------- | +----------+ |		| +------+| --------- | +----------+ |
	| | | |		| | | |
	+--------+ | +-----+ | | +----------+ | +--------+		+--------+ | +-----+ | | +----------+ | +--------+
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |		| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
	| CE1 |--| |PIT | | | | PIT | |-| CE2 |		| CE1 |--| |PIT | | | | PIT | |-| CE2 |
	+--------+ | | | | | | | | +--------+		+--------+ | | | | | | | | +--------+
	| +-----+ | | +----------+ |		| +-----+ | | +----------+ |
	+---------+ +--------------+		+---------+ +--------------+
	Figure 2 OVPN Components		Figure 2 OVPN Components
	As a result each link connecting the CE to the PE ONE is		As a result, each link connecting the CE to the PE ONE is
	associated with a CE port that has a unique identifier within a		associated with a CE port that has a unique identifier within a
	given OVPN, and with a PE port that has a unique identifier		given OVPN, and with a PE port that has a unique identifier
	within the service provider network. We'll refer to the former		within the service provider network. We'll refer to the former
	as the customer port identifier (CPI), and to the latter as the		as the customer port identifier (CPI), and to the latter as the
	provider port identifier (PPI).		provider port identifier (PPI).
	This document assumes that in addition to PPI, each port on PE		This document assumes that in addition to PPI, each port on PE
	ONE has also an identifier that is unique within the OVPN of		ONE has also an identifier that is unique within the OVPN of
	the CE connected to that port. One way to accomplish this is		that port. One way to accomplish this is to assign each port
	to assign each port an IP address that is unique within a given		an IP address that is unique within a given OVPN, and use this
	OVPN, and use this address as a port identifier. Another way to		address as a port identifier. Another way to accomplish this is
	accomplish this is to assigned each port an interface index		to assigned each port an index that is unique within a given PE
	that is unique within a given PE ONE, assign each PE ONE an IP		ONE, assign each PE ONE an IP address that is unique within a
	address that is unique within a given OVPN (but need not be		given OVPN (but need not be unique within the service provider
	unique within the service provider network), and then use a		network), and then use a tuple <port index, PE ONE IP address>
	tuple <interface index, PE ONE IP address> acts as a port		acts as a port identifier. We'll refer to such port identifier
	identifier. We'll refer to such port identifier as VPN-PPI.		as VPN-PPI. Note that PE ONE IP address used for VPN-PPI need
	Note that PE ONE IP address used for VPN-PPI need not be the		not be the same as PE ONE IP address used for PPI. If for a
	same as PE ONE IP address used for PPI, and moreover, a given		given port on a PE its PPI and VPN-PPI are both unnumbered,
	PE ONE may have multiple PE ONE addresses used for VPN-PPI, one		then they both could use exactly the same port index.
	per OVPN. Subject to the constraints outlined in the next
	paragraph, PPI could be used as VPN-PPI.		Note that IP addresses used for CPIs, PPIs and VPN-PPIs could
			be either IPv4 or IPv6 addresses.
	For a given link connecting a CE to a PE ONE, if CPI is an IP		For a given link connecting a CE to a PE ONE, if CPI is an IP
	address, then VPN-PPI has to be an IP address as well. And if		address, then VPN-PPI has to be an IP address as well. And if
	CPI is an <interface index, CPI IP address>, then VPN-PPI has		CPI is an <port index, CPI IP address>, then VPN-PPI has to be
	to be an <interface index, PE ONE IP address>. However, for a		an <port index, PE ONE IP address>. However, for a given port
	given port on PE ONE, whether VPN-PPI of that port is an IP		on PE ONE, whether VPN-PPI of that port is an IP address or an
	address or an <interface index, PE ONE IP address> is		<port index, PE ONE IP address> is independent of whether PPI
	independent of whether PPI of that port is an IP address or an		of that port is an IP address or an <port index, PE ONE IP
	<interface index, PE ONE IP address>.		address>.
			This document assumes that assignment of PPIs is controlled
			solely by the service provider (without any coordination with
			the OVPN customers), while assignment of CPIs and VPN-PPIs is
			controlled solely by the OVPN that the CPIs and VPN-PPIs belong
			to. And, of course, each OVPN could assign its CPIs and VPN-
			PPIs on its own, without any coordination with other OVPNs.
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	Each PE ONE maintains a Port Information Table (PIT) for each		Each PE ONE maintains a Port Information Table (PIT) for each
	OVPN that has at least one port on that PE ONE. A PIT contains		OVPN that has at least one port on that PE ONE. A PIT contains
	a list of <CPI, PPI> tuples for all the ports within its OVPN.		a list of <CPI, PPI> tuples for all the ports within its OVPN.
	A PIT on a given PE ONE is populated from two sources: the		A PIT on a given PE ONE is populated from two sources: the
	information related to the CEs (optionally received from the		information related to the CEs' ports attached to the ports on
	CEs) attached to the ports on that PE ONEs, and the information		that PE ONEs (this information could be optionally received
	received from other PE ONEs. We'll refer to the former as the		from the CEs), and the information received from other PE ONEs.
	"local" information, and to the latter as the "remote"		We'll refer to the former as the "local" information, and to
	information.		the latter as the "remote" information.
	The local information is propagated to other PE ONEs by using		The local information is propagated to other PE ONEs by using
	BGP with multi-protocol extensions. To restrict the flow of		BGP with multi-protocol extensions. To restrict the flow of
	this information to only the PITs within a given OVPN, we use		this information to only the PITs within a given OVPN, we use
	BGP route filtering based on the Route Target Extended		BGP route filtering based on the Route Target Extended
	Community [BGP-COMM], as follows.		Community [BGP-COMM], as follows.
	Each PIT on a PE ONE is configured with one or more Route		Each PIT on a PE ONE is configured with one or more Route
	Target Communities, called "export Route Targets", that are		Target Communities, called "export Route Targets", that are
	used for tagging the local information when it is exported into		used for tagging the local information when it is exported into
	skipping to change at page 8, line 27 ¶		skipping to change at page 9, line 4 ¶
	In order to establish an optical connection, a CE needs to		In order to establish an optical connection, a CE needs to
	identify all other CEs in the CE's OVPN it wants to connect to.		identify all other CEs in the CE's OVPN it wants to connect to.
	A CE may already have obtained the CE list through		A CE may already have obtained the CE list through
	configuration or through some other schemes (such schemes are		configuration or through some other schemes (such schemes are
	outside the scope of this draft).		outside the scope of this draft).
	It is also desirable, that the service provider, as a value		It is also desirable, that the service provider, as a value
	added service, may provide a CE with a list of all other CEs in		added service, may provide a CE with a list of all other CEs in
	the CE's OVPN. This is accomplished by passing the information		the CE's OVPN. This is accomplished by passing the information
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	stored in the PE ONE PITs to the attached CE. This document		stored in the PE ONE PITs to the attached CE. This document
	assumes that this is accomplished by using BGP Multi-protocol		assumes that this is accomplished by using BGP Multi-protocol
	extensions (however this draft doesn't preclude other		extensions (however this draft doesn't preclude other
	mechanisms to be used). Although optional, this draft		mechanisms to be used). Although optional, this draft
	recommends the PE to signal to the attached CEs the remote CPIs		recommends the PE to signal to the attached CEs the remote CPIs
	it learnt from the remote CEs part of the same OVPN. A CE may		it learnt from the remote CEs part of the same OVPN. A CE may
	decide to initiate an optical connection request to a remote CE		decide to initiate an optical connection request to a remote CE
	only when it learn the CPI of the remote CE from the PE. This		only when it learn the CPI of the remote CE from the PE. This
	has the benefit to avoid rejecting connection request while the		has the benefit to avoid rejecting connection request while the
	PE is populating the PITs.		PE is populating the PITs.
	Once a CE obtains the information about the CPIs of other ports		Once a CE obtains the information about the CPIs of other ports
	within the same OVPN, which we'll refer to as "target ports",		within the same OVPN, which we'll refer to as "target ports",
	the CE uses a (subset of) GMPLS signaling to request the		the CE uses a (subset of) GMPLS signaling, as described in
	provider network to establish an optical connection to a target		Section 4, to request the provider network to establish an
	port. Note that this draft assumes that GMPLS is only used to		optical connection to a target port. Note that this draft
	establish optical connections between client devices.		assumes that GMPLS is only used to establish optical
			connections between client devices.
	The request originated by the CE contains the CPI of the port		The request originated by the CE contains the CPI of the port
	on the CE that CE wants to use for the optical connection, and		on the CE that CE wants to use for the optical connection, and
	the CPI of the target port. When the PE ONE attached to the CE		the CPI of the target port. When the PE ONE attached to the CE
	that originated the request receives the request, the PE ONE		that originated the request receives the request, the PE ONE
	identifies the appropriate PIT, and then uses the information		identifies the appropriate PIT, and then uses the information
	in that PIT to find out the PPI associated with the CPI of the		in that PIT to find out the PPI associated with the CPI of the
	target port carried in the request. The PPI should be		target port carried in the request. The PPI should be
	sufficient for the PE ONE to establish an optical connection.		sufficient for the PE ONE to establish an optical connection.
	Ultimately the request reaches the CE associated with the		Ultimately the request reaches the CE associated with the
	skipping to change at page 9, line 26 ¶		skipping to change at page 10, line 4 ¶
	bandwidth within the port, etc. This information could be		bandwidth within the port, etc. This information could be
	further augmented with the information about certain		further augmented with the information about certain
	capabilities of the Service Provider network (e.g., support		capabilities of the Service Provider network (e.g., support
	RSOH DCC transparency, arbitrary concatenation, etc_). This		RSOH DCC transparency, arbitrary concatenation, etc_). This
	information is used to ensure that ports at each end of an		information is used to ensure that ports at each end of an
	optical connection have compatible characteristics, and that		optical connection have compatible characteristics, and that
	there are sufficient unallocated resources to establish an		there are sufficient unallocated resources to establish an
	optical connection. Distribution of this information (including		optical connection. Distribution of this information (including
	the mechanisms for distributing this information) is identical		the mechanisms for distributing this information) is identical
	to the distribution of the <CPI, PPI> information. Distributing		to the distribution of the <CPI, PPI> information. Distributing
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	changes to this information due to establishing/terminating of		changes to this information due to establishing/terminating of
	optical connections is identical to the distribution of the		optical connections is identical to the distribution of the
	<CPI, PPI> information, except that thresholds should be used		<CPI, PPI> information, except that thresholds should be used
	to contain the volume of control traffic caused by such		to contain the volume of control traffic caused by such
	distribution.		distribution.
	It may happen that for a given pair of ports within an OVPN,		It may happen that for a given pair of ports within an OVPN,
	each of the CEs connected to these ports would concurrently try		each of the CEs connected to these ports would concurrently try
	to establish an optical connection to the other CE. If having a		to establish an optical connection to the other CE. If having a
	pair of optical connections between a pair of ports is viewed		pair of optical connections between a pair of ports is viewed
	as undesirable, the a way to resolve this is have CE with the		as undesirable, the a way to resolve this is have CE with the
	lower value of CPI is required to terminate the optical		lower value of CPI is required to terminate the optical
	connection originated by the CE. This option could be		connection originated by the CE. This option could be
	controlled by configuration on the CE devices.		controlled by configuration on the CE devices.
	4. Encoding		4. Signaling between CE and PE (Simple UNI -SUNI)
			Signaling between CE and PE uses a (proper) subset of GMPLS
			signaling [GMPLS].
			For the purpose of GMPLS signaling between CE and PE, this
			document assumes that there is an IP control channel between
			the CE and the PE. This channel could be either a single IP
			hop, or an IP private network, or even an IP VPN. We'll refer
			to the CE's address of this channel as the CE Control Channel
			Address (CE-CC-Addr), and to the PE's address of this channel
			as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr
			and PE-CC-Addr are required to be unique within the OVPN they
			belong to, but are not required to be unique across multiple
			OVPNs. Assignment of CE-CC-Addr and PE-CC-Addr are controlled
			by the OVPN these addresses belong to.
			Multiple ports on a CE could share the same control channel
			only as long as all these ports belong to the same OVPN.
			Likewise, multiple ports on a PE could share the same control
			channel only as long as all these ports belong to the same
			OVPN.
			When a CE sends an RSVP Path message to a PE, the source IP
			address in the IP packet that carries the message is set to the
			appropriate CE-CC-Addr, and the destination IP address in the
			packet is set to the appropriate PE-CC-Addr. When the PE sends
			back to the CE the corresponding Resv message, the source IP
			address in the IP packet that carries the message is set to the
			PE-CC-Addr, and the destination IP address is set to the CE-CC-
			Addr.
			Likewise, when a PE sends an RSVP Path message to a CE, the
			source IP address in the IP packet that carries the message is
			set to the appropriate PE-CC-Addr, and the destination IP
			address in the packet is set to the appropriate CE-CC-Addr.
			When the CE sends back to the PE the corresponding Resv
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
			message, the source IP address in the IP packet that carries
			the message is set to the CE-CC-Addr, and the destination IP
			address is set to the PE-CC-Addr.
			In addition to being used for IP addresses in the IP packet
			that carries RSVP messages between CE and PE, CE-CC-Addr and
			PE-CC-Addr are also used in the Next/Previous Hop Address field
			of the IF_ID RSVP_HOP object that is carried between CEs and
			PEs.
			In the case where a link between CE and PE is a numbered non-
			bundled link, the CPI and VPN-PPI of that link are used for the
			Type 1 or 2 TLVs of the IF_ID RSVP HOP object that is carried
			between the CE and PE. In the case where a link between CE and
			PE is an unnumbered non-bundled link, the CPI and VPN-PPI of
			that link are used for the IP Address field of the Type 3 TLV.
			In the case where a link between CE and PE is a bundled link,
			the CPI and VPN-PPI of that link are used for the IP Address
			field of the Type 3 TLVs.
			When a CE originates a Path message to establish a connection
			from a particular port on that CE to a particular target port
			the CE uses the CPI of its port in the Sender Template object.
			If the CPI of the target port is an IP address, then the CE
			uses it in the Session object. And if the CPI of the target
			port is a <port index, IP address> tuple, then the CE uses the
			IP address part of the tuple in the Session object, and the
			whole tuple as the Unnumbered Interface ID subobject in the
			ERO. When the Path message arrives at the ingress PE, the PE
			selects the PIT associated with the OVPN, and then uses this
			PIT to map CPIs carried in the Session and the Sender Template
			objects to the appropriate PPIs. Once the mapping is done, the
			ingress PE replaces CPIs with these PPIs. As a result, the
			Session and the Sender Template objects that are carried in the
			GMPLS signaling within the service provider network carry PPIs,
			and not CPIs. At the egress PE, the PE performs the reverse
			mapping _ it maps PPIs carried in the Session and the Sender
			Template object into the appropriate CPIs, and then sends the
			Path message to the CE that has the target port.
			5. Encoding
	This section specifies encoding of various information defined		This section specifies encoding of various information defined
	in this document.		in this document.
	4.1 Encoding of CPI and channel characteristics in GMPLS Signaling		5.1 Encoding of channel characteristics in GMPLS Signaling
	[TBD]		[TBD]
	4.2 Encoding of CPI, PPI, and channel characteristics in BGP		5.2 Encoding of CPI, PPI, and channel characteristics in BGP
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
			5.2.1 Encoding of CPI and PPI information in BGP
	4.2.1 Encoding of CPI and PPI information in BGP
	The <CPI, PPI> mapping is carried using the Multiprotocol		The <CPI, PPI> mapping is carried using the Multiprotocol
	Extensions BGP [RFC2858]. [RFC2858] defines the format of two		Extensions BGP [RFC2858]. [RFC2858] defines the format of two
	BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be		BGP attributes, MP_REACH_NLRI and MP_UNREACH_NLRI that can be
	used to announce and withdraw the announcement of reachability		used to announce and withdraw the announcement of reachability
	information. We introduce a new address family identifier (AFI)		information. We introduce a new address family identifier (AFI)
	for OVPN (to be assigned by the IANA), a new subsequent address		for OVPN (to be assigned by the IANA), a new subsequent address
	family identifier (to be assigned by the IANA), and also a new		family identifier (to be assigned by the IANA), and also a new
	NLRI format for carrying the CPI and PPI information.		NLRI format for carrying the CPI and PPI information.
	One or more <PPI, CPI> tuples could be carried in the above		One or more <PPI, CPI> tuples could be carried in the above
	skipping to change at page 10, line 52 ¶		skipping to change at page 13, line 5 ¶
	the		the
	<PPI, CPI> Information tuple in octets.		<PPI, CPI> Information tuple in octets.
	PPI AFI:		PPI AFI:
	A two octets field whose value indicates address		A two octets field whose value indicates address
	family identifier of PPI		family identifier of PPI
	PPI Length:		PPI Length:
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	A one octet field whose value indicates the length of		A one octet field whose value indicates the length of
	of the PPI field		of the PPI field
	PPI field:		PPI field:
	A variable length field that contains the value of		A variable length field that contains the value of
	the PPI (either an address or <interface index,		the PPI (either an address or <port index,
	address> tuple		address> tuple
	CPI AFI field:		CPI AFI field:
	A two octets field whose value indicates address		A two octets field whose value indicates address
	family of the CPI.		family of the CPI.
	CPI Length:		CPI Length:
	A once octet field whose value indicates the		A once octet field whose value indicates the
	length of the CPI field.		length of the CPI field.
	CPI (variable):		CPI (variable):
	A variable length field that contains the CPI		A variable length field that contains the CPI
	value (either an address or <interface index, address>		value (either an address or <port index, address>
	tuple.		tuple.
	4.2.2 Encoding channel characteristics in BGP		5.2.2 Encoding channel characteristics in BGP
	[TBD]		[TBD]
	5. Other issues		6. One vs more than one OVPN
	While the above text assumes that the service provider network		The solution described in this document requires each customer
	consists of ONEs and ports are connected via optical		port to be in at most one OVPN, or to be more precise requires
	connections, the mechanisms described in this document could be		each customer port connected to a given PE to be associated
	applied in an environment, where the service provider network		with at most one PIT on that PE. It has been asserted that this
	consists of SONET/SDH cross connects and CE ports being either		requirement is too restrictive, as it doesn't allow to realize
	SONET/SDH or Ethernet.		certain connectivity scenarios. To understand why this
			assertion is incorrect we'd like to make several observations.
			First, the solution described in this document allows control
			connectivity between customers' ports at the granularity of
			individual ports. This is because each local port on a PE could
			have its own PIT, and the granularity of the information that
			is used to populate this PIT could be as fine as a single
			remote port (port on some other PE).
			Second, ports that are present in a given PIT need not have the
			same administrative control. For example, some ports in a given
			PIT may belong to the same organization (have the same
			administrative control) as the local ports associated with that
			PIT, while some other ports in exactly the same PIT may belong
			to organizations different from the one associated with the
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
			local ports. In that sense, a single PIT could combine both an
			Intranet and an Extranet.
			As a result, it should be abundantly obvious to the informed
			reader that the solution described in this document allows to
			realize any arbitrary inter-port connectivity matrix.
			Therefore, no other solution could be less restrictive than
			then one described in this document.
			7. Exchanging VPN-ID between CE and PE
			The solution described in this document assumes that an
			association of a particular port on a CE with a particular OVPN
			(or to be more precise with a particular PIT on a PE) is done
			by the OVPN service provider, as part of the provisioning the
			port on the PE (associating the PE's port with a particular
			PIT, and connecting the CE's port with the PE's port). Once
			this association is established, the CE could request
			establishment of an optical connection to any customer's port
			present in the PIT. Important to note that in order to select a
			particular port within the PIT for the purpose of establishing
			a connection to that port the only information that the CE
			needs to identify that port is the CPI of that port. Also
			important to note that the CPI is either an IP address, or a
			combination of <port index, IP address>, but it doesn't include
			any such thing as VPN-ID.
			Therefore, the solution described in this document doesn't
			involve exchanging VPN-IDs between CE and PE in (GMPLS)
			signaling. Moreover, the lack of exchanging VPN-ID in signaling
			has no adverse effect on the ability to support any arbitrary
			inter-port connectivity matrix, and more generally on the
			flexibility of the solution described here.
			8. Other issues
	Since the protocol used to populate a PIT with remote		Since the protocol used to populate a PIT with remote
	information is BGP, since BGP works across multiple routing		information is BGP, since BGP works across multiple routing
	domains, and since GMPLS signaling isn't restricted to a single		domains, and since GMPLS signaling isn't restricted to a single
	routing domain, it follows that the mechanisms described in		routing domain, it follows that the mechanisms described in
	this document could support an environment that consists of		this document could support an environment that consists of
	multiple routing domains.		multiple routing domains.
	The mechanisms described in this document allow for a wide		The mechanisms described in this document allow for a wide
	range of choices with respect to addresses used for CPI, PPI,		range of choices with respect to addresses used for CPI, PPI,
	and VPN-PPI. For example, one could use either IPv4 addresses,		and VPN-PPI. For example, one could use either IPv4 addresses,
	or IPv6 addresses, or NSAPs. Different OVPN customers of a		or IPv6 addresses, or NSAPs. Different OVPN customers of a
	given service provider may use different types of addresses.		given service provider may use different types of addresses.
	Moreover, different OVPNs attaching to the same PE ONE may use		Moreover, different OVPNs attaching to the same PE ONE may use
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	different addressing schemes. The types of addresses used for		different addressing schemes. The types of addresses used for
	PPIs within a given service provider network are independent		PPIs within a given service provider network are independent
	from the type of addresses used for CPI and VPN-PPI by the OVPN		from the type of addresses used for CPI and VPN-PPI by the OVPN
	customers of that provider.		customers of that provider.
	6. Security Considerations		While in the context of this document a CE is a device that
			uses the Optical/TDM VPN service, such a device, in turn, could
			be used to offer VPN services (e.g., RFC2547, Virtual Routers,
			Layer 2 VPNs) to other devices (thus becoming a PE with respect
			to these devices). Moreover, a CE device that uses the Optical
			VPN service could, in turn be used to offer Optical/TDM
			services to other devices (thus becoming a PE ONE with respect
			to these devices).
	[TBD]		9. Security Considerations
	7. References		Since association of a particular port with a particular OVPN
			(or to be more precise with a particular PIT) is done by the
			service provider as part of the service provisioning process
			(and thus can't be altered via signaling between CE and PE),
			and since signaling between CE and PE is assumed to be over a
			private network (and thus can't be spoofed by entities outside
			the private network), the solution described in this document
			doesn't require authentication in signaling.
			10. References
	[BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities		[BGP-COMM] Ramachandra, Tappan, "BGP Extended Communities
	Attribute", February 2000, work in progress.		Attribute", February 2000, work in progress.
	[Framework] Rajagopalan, B. et al., "IP over Optical Networks:		[Framework] Rajagopalan, B. et al., "IP over Optical Networks:
	A Framework ", November 2000, work in progress.		A Framework ", November 2000, work in progress.
	[GMPLS] Ashwood-Smith, P., Berger, L. et al., "Generalized MPLS		[GMPLS] Ashwood-Smith, P., Berger, L. et al., "Generalized MPLS
	-Signaling Functional Description", November 2000, work in		-Signaling Functional Description", November 2000, work in
	progress.		progress.
	[LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link		[LINK-BUNDLING] Kompella, K., Rekhter, Y., Berger, L., "Link
	Bundling in MPLS Traffic Engineering", work in progress.		Bundling in MPLS Traffic Engineering", work in progress.
	[OVPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service		[OVPN-REQ] Ould-Brahim, H., Rekhter, Y., et al., "Service
	Requirements for Optical Virtual Private Networks", work in		Requirements for Optical Virtual Private Networks", work in
	progress, July 2001.		progress, July 2001.
			[PPVPN-FRAMEWORK] Callon, R., Suzuki, M., Gleeson, B., Malis,
			A., Muthukrishnanm K, Rosen, E., Sargor, C., Yu, J., _A
			Framework for Provider Provisioned Virtual Private
			Networks_, draft-ietf-ppvpn-framework-01.txt
			draft-ouldbrahim-bgpgmpls-ovpn-02.txt November 2001
	[RFC-2858] Bates, Chandra, Katz, and Rekhter, "Multiprotocol		[RFC-2858] Bates, Chandra, Katz, and Rekhter, "Multiprotocol
	Extensions for BGP4", RFC2858, June 2000.		Extensions for BGP4", RFC2858, June 2000.
	[RFC-2026] Bradner, S., "The Internet Standards Process --		[RFC-2026] Bradner, S., "The Internet Standards Process --
	Revision 3", RFC2026, October 1996.		Revision 3", RFC2026, October 1996.
	[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997.		Requirement Levels", RFC 2119, March 1997.
	[VPN-BGP] Ould-Brahim H., Gleeson B., Ashwood-Smith P., Rosen		[VPN-BGP] Ould-Brahim H., Gleeson B., Ashwood-Smith P., Rosen
	E., Rekhter Y., Declerq J., Fang L., Hartani R., "Using BGP		E., Rekhter Y., Declerq J., Fang L., Hartani R., "Using BGP
	as an Auto-Discovery Mechanism for Network-based VPNs", work		as an Auto-Discovery Mechanism for Network-based VPNs", work
	in progress, July 2001.		in progress, July 2001.
	8. Acknowledgments.		11. Acknowledgments.
	The authors would like to thank Osama Aboul-Magd, Dimitri		The authors would like to thank Osama Aboul-Magd, Penno
	Papadimitriou, Penno Reinaldo, Erning Ye, and Bryan Gleeson for		Reinaldo, Erning Ye, Bryan Gleeson, and Dave Allan for
	reviewing the draft and providing comments.		reviewing the draft and providing comments.
	9. Author's Addresses		12. Author's Addresses
	Hamid Ould-Brahim		Hamid Ould-Brahim
	Nortel Networks		Nortel Networks
	P O Box 3511 Station C		P O Box 3511 Station C
	Ottawa ON K1Y 4H7 Canada		Ottawa ON K1Y 4H7 Canada
	Phone: +1 (613) 765 3418		Phone: +1 (613) 765 3418
	Email: hbrahim@nortelnetworks.com		Email: hbrahim@nortelnetworks.com
			Yakov Rekhter
			Juniper Networks
			1194 N. Mathilda Avenue
			Sunnyvale, CA 94089
			Email: yakov@juniper.net
	Don Fedyk		Don Fedyk
	Nortel Networks		Nortel Networks
	600 Technology Park		600 Technology Park
	Billerica, Massachusetts		Billerica, Massachusetts
	01821 U.S.A.		01821 U.S.A
	Phone: +1 (978) 288 3041		Phone: +1 (978) 288 3041
	Email: dwfedyk@nortelnetworks.com		Email: dfedyk2nortelnetworks.com
	Peter Ashwood-Smith		Peter Ashwood-Smith
	Nortel Networks		Nortel Networks
	P.O. Box 3511 Station C,		P.O. Box 3511 Station C,
	Ottawa, ON K1Y 4H7, Canada		Ottawa, ON K1Y 4H7, Canada
	Phone: +1 613 763 4534		Phone: +1 613 763 4534
	Email: petera@nortelnetworks.com		Email: petera@nortelnetworks.com
	Yakov Rekhter
	Juniper Networks
	1194 N. Mathilda Avenue
	Sunnyvale, CA 94089
	Email: yakov@juniper.net
	Eric C. Rosen		Eric C. Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	250 Apollo drive		250 Apollo drive
	Chelmsford, MA, 01824		Chelmsford, MA, 01824
	E-mail: erosen@cisco.com		E-mail: erosen@cisco.com
	Eric Mannie		Eric Mannie
	Ebone (GTS)		Ebone (GTS)
	Terhulpsesteenweg 6A		Terhulpsesteenweg 6A
	1560 Hoeilaart		1560 Hoeilaart
	skipping to change at page 14, line ? ¶		skipping to change at page 17, line 34 ¶
	Phone: +32 2 658 56 52		Phone: +32 2 658 56 52
	Email: eric.mannie@gts.com		Email: eric.mannie@gts.com
	Luyuan Fang		Luyuan Fang
	AT&T		AT&T
	200 Laurel Avenue		200 Laurel Avenue
	Middletown, NJ 07748		Middletown, NJ 07748
	Email: Luyuanfang@att.com		Email: Luyuanfang@att.com
	Phone: +1 (732) 420 1920		Phone: +1 (732) 420 1920
	Ould-Brahim, et. al 13
	draft-ouldbrahim-bgpgmpls-ovpn-01.txt July 2001
	John Drake		John Drake
	Calient Networks		Calient Networks
	5853 Rue Ferrari		5853 Rue Ferrari
	San Jose, CA 95138		San Jose, CA 95138
	USA		USA
	Phone: +1 408 972 3720		Phone: +1 408 972 3720
	Email: jdrake@calient.net		Email: jdrake@calient.net
	Yong Xue		Yong Xue
	UUNET/WorldCom		UUNET/WorldCom
	skipping to change at page 15, line 5 ¶		skipping to change at page 18, line 6 ¶
	(703)-886-5358		(703)-886-5358
	yxue@uu.net		yxue@uu.net
	Riad Hartani		Riad Hartani
	Caspian Networks		Caspian Networks
	170 Baytech Drive		170 Baytech Drive
	San Jose, CA 95143		San Jose, CA 95143
	Phone: 408 382 5216		Phone: 408 382 5216
	Email: riad@caspiannetworks.com		Email: riad@caspiannetworks.com
			Dimitri Papadimitrio
			Alcatel
			Francis Wellesplein 1,
			B-2018 Antwerpen, Belgium
			Phone: +32 3 240-8491
			Email: Dimitri.Papadimitriou@alcatel.be
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2000). All Rights Reserved.
	This document and translations of it may be copied and		This document and translations of it may be copied and
	furnished to others, and derivative works that comment on or		furnished to others, and derivative works that comment on or
	otherwise explain it or assist in its implementation may be		otherwise explain it or assist in its implementation may be
	prepared, copied, published and distributed, in whole or in		prepared, copied, published and distributed, in whole or in
	part, without restriction of any kind, provided that the above		part, without restriction of any kind, provided that the above
	copyright notice and this paragraph are included on all such		copyright notice and this paragraph are included on all such
	copies and derivative works. However, this document itself may		copies and derivative works. However, this document itself may
End of changes. 56 change blocks.
	130 lines changed or deleted		348 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/