draft-ietf-mpls-mldp-in-band-signaling-07.txt		draft-ietf-mpls-mldp-in-band-signaling-08.txt
	Network Working Group IJ. Wijnands, Ed.		Network Working Group IJ. Wijnands, Ed.
	Internet-Draft T. Eckert		Internet-Draft T. Eckert
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: April 25, 2013 N. Leymann		Expires: June 2, 2013 N. Leymann
	Deutsche Telekom		Deutsche Telekom
	M. Napierala		M. Napierala
	AT&T Labs		AT&T Labs
	October 22, 2012		November 29, 2012
	Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-		Multipoint LDP in-band signaling for Point-to-Multipoint and Multipoint-
	to-Multipoint Label Switched Paths		to-Multipoint Label Switched Paths
	draft-ietf-mpls-mldp-in-band-signaling-07		draft-ietf-mpls-mldp-in-band-signaling-08
	Abstract		Abstract
	Consider an IP multicast tree, constructed by Protocol Independent		Consider an IP multicast tree, constructed by Protocol Independent
	Multicast (PIM), needs to pass through an MPLS domain in which		Multicast (PIM), needs to pass through an MPLS domain in which
	Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-		Multipoint LDP (mLDP) Point-to-Multipoint and/or Multipoint-to-
	Multipoint Labels Switched Paths (LSPs) can be created. The part of		Multipoint Labels Switched Paths (LSPs) can be created. The part of
	the IP multicast tree that traverses the MPLS domain can be		the IP multicast tree that traverses the MPLS domain can be
	instantiated as a multipoint LSP. When a PIM Join message is		instantiated as a multipoint LSP. When a PIM Join message is
	received at the border of the MPLS domain, information from that		received at the border of the MPLS domain, information from that
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 25, 2013.		This Internet-Draft will expire on June 2, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format
	it for publication as an RFC or to translate it into languages other
	than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Conventions used in this document . . . . . . . . . . . . 4		1.1. Conventions used in this document . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 5		2. In-band signaling for MP LSPs . . . . . . . . . . . . . . . . 4
	2.1. Transiting Unidirectional IP multicast Shared Trees . . . 7		2.1. Transiting Unidirectional IP multicast Shared Trees . . . 6
	2.2. Transiting IP multicast source trees . . . . . . . . . . . 7		2.2. Transiting IP multicast source trees . . . . . . . . . . . 6
	2.3. Transiting IP multicast bidirectional trees . . . . . . . 8		2.3. Transiting IP multicast bidirectional trees . . . . . . . 7
	3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 8		3. LSP opaque encodings . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8		3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 7
	3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 9		3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
	3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 10		3.3. Transit IPv4 bidir TLV . . . . . . . . . . . . . . . . . . 9
	3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 10		3.4. Transit IPv6 bidir TLV . . . . . . . . . . . . . . . . . . 9
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 11		4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11		5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 12		7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The mLDP (Multipoint LDP) [RFC6388] specification describes		The mLDP (Multipoint LDP) [RFC6388] specification describes
	mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-		mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
	multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are		multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are
	typically used for transporting end-user multicast packets. However,		typically used for transporting end-user multicast packets. However,
	the mLDP specification does not provide any rules for associating		the mLDP specification does not provide any rules for associating
	particular end-user multicast packets with any particular LSP. Other		particular end-user multicast packets with any particular LSP. Other
	documents, like [RFC6513], describe applications in which out-of-band		documents, like [RFC6513], describe applications in which out-of-band
	skipping to change at page 5, line 18		skipping to change at page 4, line 18
	ASM: PIM Any Source Multicast.		ASM: PIM Any Source Multicast.
	mLDP : Multipoint LDP.		mLDP : Multipoint LDP.
	Transit LSP : A P2MP or MP2MP LSP whose FEC element contains the		Transit LSP : A P2MP or MP2MP LSP whose FEC element contains the
	(S,G) or (*,G) identifying a particular IP multicast distribution		(S,G) or (*,G) identifying a particular IP multicast distribution
	tree.		tree.
	In-band signaling : Using the opaque value of a mLDP FEC element to		In-band signaling : Using the opaque value of a mLDP FEC element to
	carry the (S,G) or (*,G) indentifying a particular IP multicast		carry the (S,G) or (*,G) identifying a particular IP multicast
	tree.		tree.
	P2MP LSP: An LSP that has one Ingress LSR and one or more Egress		P2MP LSP: An LSP that has one Ingress LSR and one or more Egress
	LSRs.		LSRs.
	MP2MP LSP: An LSP that connects a set of leaf nodes that may each		MP2MP LSP: An LSP that connects a set of leaf nodes that may each
	independently act as ingress or egress.		independently act as ingress or egress.
	MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.		MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
	skipping to change at page 6, line 35		skipping to change at page 5, line 35
	LSP become part of the IP multicast distribution tree. Note that		LSP become part of the IP multicast distribution tree. Note that
	other methods are possible to determine that an IP multicast tree is		other methods are possible to determine that an IP multicast tree is
	to be transported across an MPLS network using P2MP or MP2MP LSPs,		to be transported across an MPLS network using P2MP or MP2MP LSPs,
	these methods are outside the scope of this document.		these methods are outside the scope of this document.
	In order to establish a multicast tree via a P2MP or MP2MP LSP using		In order to establish a multicast tree via a P2MP or MP2MP LSP using
	"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with		"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with
	the IP address of LSR U as the "Root Node Address", and with the		the IP address of LSR U as the "Root Node Address", and with the
	source and the group encoded into the "opaque value" ([RFC6388],		source and the group encoded into the "opaque value" ([RFC6388],
	section 2.2 and 3.2). Several different opaque value types are		section 2.2 and 3.2). Several different opaque value types are
	defined in this document; LSR D MUST NOT use a particlar opaque value		defined in this document; LSR D MUST NOT use a particular opaque
	type unless it knows (through provisioning, or through some other		value type unless it knows (through provisioning, or through some
	means outside the scope of this document) that LSR U supports the		other means outside the scope of this document) that LSR U supports
	root node procedures for that opaque value type.		the root node procedures for that opaque value type.
	The particular type of FEC Element and opaque value used depends on		The particular type of FEC Element and opaque value used depends on
	the IP address family being used, and on whether the multicast tree		the IP address family being used, and on whether the multicast tree
	being established is a source specific or a bidirectional multicast		being established is a source specific or a bidirectional multicast
	tree.		tree.
	When an LSR receives a label mapping or withdraw whose FEC Element		When an LSR receives a label mapping or withdraw whose FEC Element
	contains one of the opaque value types defined in this document, and		contains one of the opaque value types defined in this document, and
	that LSR is not the one identified by the "Root Node Address" field		that LSR is not the one identified by the "Root Node Address" field
	of that FEC element, the LSR follows the procedures of RFC 6388.		of that FEC element, the LSR follows the procedures of RFC 6388.
	skipping to change at page 8, line 29		skipping to change at page 7, line 29
	Section 3.3 or Section 3.4, depending on the IP version. The subnet		Section 3.3 or Section 3.4, depending on the IP version. The subnet
	mask associated with the bidirectional group is encoded in the		mask associated with the bidirectional group is encoded in the
	Transit TLV. There are two types of bidirectional states in IP		Transit TLV. There are two types of bidirectional states in IP
	multicast, the group specific state and the RP state. The first type		multicast, the group specific state and the RP state. The first type
	is typically created due to receiving a PIM join and has a subnet		is typically created due to receiving a PIM join and has a subnet
	mask of 32 for IPv4 and 128 for IPv6. The latter is typically		mask of 32 for IPv4 and 128 for IPv6. The latter is typically
	created via the static RP mapping and has a variable subnet mask.		created via the static RP mapping and has a variable subnet mask.
	The RP state is used to build a tree to the RP and used for sender		The RP state is used to build a tree to the RP and used for sender
	only branches. Each state (group specific and RP state) will result		only branches. Each state (group specific and RP state) will result
	in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be		in a separate MP2MP LSP. The merging of the two MP2MP LSPs will be
	done by PIM on the root LSR. No speccial procedures are nessesary		done by PIM on the root LSR. No special procedures are necessary for
	for PIM to merge the two LSPs, each LSP is effectively treated as a		PIM to merge the two LSPs, each LSP is effectively treated as a PIM
	PIM enabled interface. Please see [RFC5015] for more details.		enabled interface. Please see [RFC5015] for more details.
	For transporting the packets of a sender only branch we create a		For transporting the packets of a sender only branch we create a
	MP2MP LSP. Other sender only branches will receive these packets and		MP2MP LSP. Other sender only branches will receive these packets and
	will not forward them because there are no receivers. These packets		will not forward them because there are no receivers. These packets
	will be dropped. If that affect is undesireable some other means of		will be dropped. If that affect is undesireable some other means of
	transport has to be established to forward packets to the root of the		transport has to be established to forward packets to the root of the
	tree, like a Multi-Point to Point LSP for example. A technique to		tree, like a Multi-Point to Point LSP for example. A technique to
	unicast packets to the root of a P2MP or MP2MP LSP is documented in		unicast packets to the root of a P2MP or MP2MP LSP is documented in
	[I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1.		[I-D.rosen-l3vpn-mvpn-mspmsi] section 3.2.2.1.
	skipping to change at page 9, line 16		skipping to change at page 8, line 16
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source |		| Type | Length | Source |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| | Group |		| | Group |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 3 (to be assigned by IANA).		Type: 3 (to be assigned by IANA).
	Length: 8 octets		Length: 8 (octet size of Source and Group fields)
	Source: IPv4 multicast source address, 4 octets.		Source: IPv4 multicast source address, 4 octets.
	Group: IPv4 multicast group address, 4 octets.		Group: IPv4 multicast group address, 4 octets.
	3.2. Transit IPv6 Source TLV		3.2. Transit IPv6 Source TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Source ~		| Type | Length | Source ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ | Group ~		~ | Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 4 (to be assigned by IANA).		Type: 4 (to be assigned by IANA).
	Length: 32 octets		Length: 32 (octet size of Source and Group fields)
	Source: IPv6 multicast source address, 16 octets.		Source: IPv6 multicast source address, 16 octets.
	Group: IPv6 multicast group address, 16 octets.		Group: IPv6 multicast group address, 16 octets.
	3.3. Transit IPv4 bidir TLV		3.3. Transit IPv4 bidir TLV
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Mask Len |		| Type | Length | Mask Len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| RP |		| RP |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group |		| Group |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 5 (to be assigned by IANA).		Type: 5 (to be assigned by IANA).
	Length: 9 octets		Length: 9 (octet size of Mask Len, RP and Group fields)
	Mask Len: The number of contiguous one bits that are left justified		Mask Len: The number of contiguous one bits that are left justified
	and used as a mask, 1 octet.		and used as a mask, 1 octet. Maximum value allowed is 32.
	RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4		RP: Rendezvous Point (RP) IPv4 address used for encoded Group, 4
	octets.		octets.
	Group: IPv4 multicast group address, 4 octets.		Group: IPv4 multicast group address, 4 octets.
	3.4. Transit IPv6 bidir TLV		3.4. Transit IPv6 bidir TLV
	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
	skipping to change at page 11, line 9		skipping to change at page 10, line 9
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Group ~		| Group ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ |		~ |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type: 6 (to be assigned by IANA).		Type: 6 (to be assigned by IANA).
	Length: 33 octets		Length: 33 (octet size of Mask Len, RP and Group fields)
	Mask Len: The number of contiguous one bits that are left justified		Mask Len: The number of contiguous one bits that are left justified
	and used as a mask, 1 octet.		and used as a mask, 1 octet. Maximum value allowed is 128.
	RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16		RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16
	octets.		octets.
	Group: IPv6 multicast group address, 16 octets.		Group: IPv6 multicast group address, 16 octets.
	4. Security Considerations		4. Security Considerations
	The same security considerations apply as for the base LDP		The same security considerations apply as for the base LDP
	specification, as described in [RFC5036].		specification, as described in [RFC5036].
	skipping to change at page 11, line 41		skipping to change at page 10, line 41
	Transit IPv6 Source TLV type - 4		Transit IPv6 Source TLV type - 4
	Transit IPv4 Bidir TLV type - 5		Transit IPv4 Bidir TLV type - 5
	Transit IPv6 Bidir TLV type - 6		Transit IPv6 Bidir TLV type - 6
	6. Acknowledgments		6. Acknowledgments
	Thanks to Eric Rosen for his valuable comments on this document.		Thanks to Eric Rosen for his valuable comments on this document.
	Also thanks to Yakov Rekhter, Adrial Farrel, Uwe Joorde, Loa		Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
	Andersson and Arkadiy Gulko for providing comments on this document.		Andersson and Arkadiy Gulko for providing comments on this document.
	7. Contributing authors		7. Contributing authors
	Below is a list of the contributing authors in alphabetical order:		Below is a list of the contributing authors in alphabetical order:
	Toerless Eckert		Toerless Eckert
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA, 95134		San Jose, CA, 95134
End of changes. 16 change blocks.
	51 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/