< draft-muthukrishnan-mpls-corevpn-arch-02.txt		draft-muthukrishnan-mpls-corevpn-arch-03.txt >
	Internet Engineering Task Force Karthik Muthukrishnan		Internet Engineering Task Force Karthik Muthukrishnan
	INTERNET-DRAFT Andrew Malis		INTERNET-DRAFT Andrew Malis
	Expires November 1, 2000 Lucent Technologies		Expires December 22, 2000 Lucent Technologies
	<draft-muthukrishnan-mpls-corevpn-arch-02.txt> May 1, 2000		<draft-muthukrishnan-mpls-corevpn-arch-03.txt> June 22, 2000
	A Core MPLS IP VPN Architecture		A Core MPLS IP VPN Architecture
	1. Status of this Memo		1. Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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 draft is not a product of any working group and was written and
			presented to the IETF well before the formation of any working group
			related to Core VPNs.
	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 at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	2. Acronyms		2. Acronyms
	ARP Address Resolution Protocol		ARP Address Resolution Protocol
	CE Customer Edge router		CE Customer Edge router
	skipping to change at page 11, line 40 ¶		skipping to change at page 11, line 40 ¶
	Configuring private LSPs for VPNs allows the SP to offer		Configuring private LSPs for VPNs allows the SP to offer
	differentiated services to paying customers. These private LSPs could		differentiated services to paying customers. These private LSPs could
	be associated with any available L2 QOS class or Diff-Serv		be associated with any available L2 QOS class or Diff-Serv
	codepoints. In a VPN, multiple private LSPs with different service		codepoints. In a VPN, multiple private LSPs with different service
	classes could be configured with flow profiles for sorting the		classes could be configured with flow profiles for sorting the
	packets among the LSPs. This feature, together with the ability to		packets among the LSPs. This feature, together with the ability to
	size the virtual routers, allows the SP to offer truly differentiated		size the virtual routers, allows the SP to offer truly differentiated
	services to the VPN customer.		services to the VPN customer.
	14. Virtual Router Security Considerations		14. Security Considerations
	14.1 Routing Security		14.1 Routing Security
	The use of standard routing protocols such as OSPF and BGP in their		The use of standard routing protocols such as OSPF and BGP in their
	unmodified form means that all the encryption and security methods		unmodified form means that all the encryption and security methods
	(such as MD5 authentication of neighbors) are fully available in VRs.		(such as MD5 authentication of neighbors) are fully available in VRs.
	Making sure that routes are not accidentally leaked from one VPN to		Making sure that routes are not accidentally leaked from one VPN to
	another is an implementation issue. One way to achieve this is to		another is an implementation issue. One way to achieve this is to
	maintain separate routing and forwarding databases.		maintain separate routing and forwarding databases.
End of changes. 3 change blocks.
	3 lines changed or deleted		7 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/