< draft-dong-pce-discovery-proto-bgp-04.txt		draft-dong-pce-discovery-proto-bgp-05.txt >
	Network Working Group J. Dong		Network Working Group J. Dong
	Internet-Draft M. Chen		Internet-Draft M. Chen
	Intended status: Standards Track D. Dhody		Intended status: Standards Track D. Dhody
	Expires: September 10, 2016 Huawei Technologies		Expires: December 26, 2016 Huawei Technologies
	J. Tantsura		J. Tantsura
	Ericsson		Individual
	March 9, 2016		K. Kumaki
			KDDI Corporation
			T. Murai
			Furukawa Network Solution Corp.
			June 24, 2016
	BGP Extensions for Path Computation Element (PCE) Discovery		BGP Extensions for Path Computation Element (PCE) Discovery
	draft-dong-pce-discovery-proto-bgp-04		draft-dong-pce-discovery-proto-bgp-05
	Abstract		Abstract
	In networks where Path Computation Element (PCE) is used for		In networks where Path Computation Element (PCE) is used for
	centralized path computation, it is desirable for the Path		centralized path computation, it is desirable for the Path
	Computation Clients (PCCs) to automatically discover a set of PCEs		Computation Clients (PCCs) to automatically discover a set of PCEs
	and select the suitable ones to establish the PCEP session. RFC 5088		and select the suitable ones to establish the PCEP session. RFC 5088
	and RFC 5089 define the PCE discovery mechanisms based on Interior		and RFC 5089 define the PCE discovery mechanisms based on Interior
	Gateway Protocols (IGP). This document describes several scenarios		Gateway Protocols (IGP). This document describes several scenarios
	in which the IGP based PCE discovery mechanisms cannot be used		in which the IGP based PCE discovery mechanisms cannot be used
	skipping to change at page 1, line 49 ¶		skipping to change at page 2, line 7 ¶
	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 September 10, 2016.		This Internet-Draft will expire on December 26, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 33 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4		2. Carrying PCE Discovery Information in BGP . . . . . . . . . . 4
	2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4		2.1. PCE Address Information . . . . . . . . . . . . . . . . . 4
	2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5		2.2. PCE Discovery TLVs . . . . . . . . . . . . . . . . . . . 5
	3. Operational Considerations . . . . . . . . . . . . . . . . . 6		3. Operational Considerations . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		8.2. Informative References . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	In network scenarios where Path Computation Element (PCE) is used for		In network scenarios where Path Computation Element (PCE) is used for
	centralized path computation, it is desirable for the Path		centralized path computation, it is desirable for the Path
	Computation Clients (PCCs) to automatically discover a set of PCEs		Computation Clients (PCCs) to automatically discover a set of PCEs
	and select the suitable ones to establish the PCEP session.		and select the suitable ones to establish the PCEP session.
	[RFC5088] and [RFC5089] define the PCE discovery mechanisms based on		[RFC5088] and [RFC5089] define the PCE discovery mechanisms based on
	Interior Gateway Protocols (IGP).		Interior Gateway Protocols (IGP).
	skipping to change at page 3, line 22 ¶		skipping to change at page 3, line 28 ¶
	case these cooperating PCEs should be known to each other in advance.		case these cooperating PCEs should be known to each other in advance.
	In this case the PCEs belongs to different AS and do not participate		In this case the PCEs belongs to different AS and do not participate
	in a common IGP, the IGP based discovery mechanisms are not		in a common IGP, the IGP based discovery mechanisms are not
	applicable.		applicable.
	Another example is the hierarchical PCE scenario [RFC6805], in which		Another example is the hierarchical PCE scenario [RFC6805], in which
	the child PCEs need to know the information of the parent PCEs. This		the child PCEs need to know the information of the parent PCEs. This
	cannot be achieved via IGP based discovery, as the child PCEs and the		cannot be achieved via IGP based discovery, as the child PCEs and the
	parent PCE are usually in different domains.		parent PCE are usually in different domains.
			In some BGP IP-VPN networks, an end-to-end TE LSP between the CEs
			(Customer Edges) of a particular VPN is required [RFC5824]. In this
			case, CEs need the information of the PCE which can perform the CE to
			CE path computation for that VPN. Since the PCE may locate in a VPN
			site different from the site of the requesting CE, the IGP based
			discovery mechanism is not directly applicable, and some BGP based
			discovery mechanism is required to distribute the per-VPN PCE
			information to the VPN sites.
	Since BGP has been extended for north-bound distribution of routing		Since BGP has been extended for north-bound distribution of routing
	and Label Switched Path (LSP) information to PCE		and Label Switched Path (LSP) information to PCE [RFC7752]
	[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-te-lsp-distribution] and		[I-D.ietf-idr-te-lsp-distribution] and [I-D.ietf-idr-te-pm-bgp], PCEs
	[I-D.ietf-idr-te-pm-bgp], PCEs can obtain the routing information		can obtain the routing information without participating in IGP. In
	without participating in IGP. In this scenario, a new BGP based PCE		this scenario, a new BGP based PCE discovery mechanism is needed.
	discovery mechanism is needed.
	This document proposes to extend BGP for PCE discovery in the above		This document proposes to extend BGP for PCE discovery in the above
	scenarios. In networks where BGP-LS is used for the north-bound		scenarios. In networks where BGP-LS is used for the north-bound
	routing information distribution to PCE, the BGP based PCE discovery		routing information distribution to PCE, the BGP based PCE discovery
	can make use of the existing BGP sessions and mechanisms to achieve		can make use of the existing BGP sessions and mechanisms to achieve
	automatic PCE discovery. Further IGP may be used to redistribute		automatic PCE discovery. Further IGP may be used to redistribute
	remote PCE information, the detailed mechanism is out of the scope of		remote PCE information, the detailed mechanism is out of the scope of
	this document. Thus the BGP based PCE discovery is complementary to		this document. Thus the BGP based PCE discovery is complementary to
	the existing IGP based mechanisms.		the existing IGP based mechanisms.
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	elements and distributed to PCE, while the PCE discovery information		elements and distributed to PCE, while the PCE discovery information
	is advertised from PCE to PCCs, or among different PCEs. The PCCs		is advertised from PCE to PCCs, or among different PCEs. The PCCs
	maybe co-located with the BGP speakers as shown in Figure 1.		maybe co-located with the BGP speakers as shown in Figure 1.
	2. Carrying PCE Discovery Information in BGP		2. Carrying PCE Discovery Information in BGP
	2.1. PCE Address Information		2.1. PCE Address Information
	The PCE discovery information is advertised in BGP UPDATE messages		The PCE discovery information is advertised in BGP UPDATE messages
	using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].		using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760].
	The AFI and SAFI defined in [I-D.ietf-idr-ls-distribution] are re-		The AFI and SAFI defined in [RFC7752] are re-used. For the PCEs in
	used, and a new NLRI Type is defined for PCE discovery information as		public network, the AFI / SAFI pair is 16388 / 71, while for the PCEs
	below:		of a particular VPN, the AFI / SAFI pair is set to 16388 / 72.
			A new NLRI Type is defined for PCE discovery information as below:
	o Type = TBD: PCE Discovery NLRI		o Type = TBD: PCE Discovery NLRI
	The format of PCE Discovery NLRI is shown in the following figure:		The format of PCE Discovery NLRI is shown in the following figure:
	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
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Protocol-ID |		| Protocol-ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. PCE Discovery NLRI		Figure 2. PCE Discovery NLRI
	The 'Protocol-ID' field SHOULD be set to the appropriate value which		The 'Protocol-ID' field SHOULD be set to the appropriate value which
	indicates the source of the PCE discovery information. If BGP		indicates the source of the PCE discovery information. If BGP
	speaker and PCE are co-located, the Protocol-ID SHOULD be set to		speaker and PCE are co-located, the Protocol-ID SHOULD be set to
	"Direct". In other cases, it is RECOMMENDED that the Protocol-ID		"Direct". In other cases, it is RECOMMENDED that the Protocol-ID
	value be set to "Static configuration".		value be set to "Static configuration".
	As defined in [I-D.ietf-idr-ls-distribution], the 64-Bit 'Identifier'		As defined in [RFC7752], the 64-Bit 'Identifier' field is used to
	field is used to identify the "routing universe" where the PCE		identify the "routing universe" where the PCE belongs.
	belongs.
	2.2. PCE Discovery TLVs		2.2. PCE Discovery TLVs
	The detailed PCE discovery information is carried in the BGP-LS		The detailed PCE discovery information is carried in the BGP-LS
	attribute [I-D.ietf-idr-ls-distribution] with a new "PCE Discovery		attribute [RFC7752] with a new "PCE Discovery TLV", which contains a
	TLV", which contains a set of sub-TLVs for specific PCE discovery		set of sub-TLVs for specific PCE discovery information. The PCE
	information. The PCE Discovery TLV and sub-TLVs SHOULD only be used		Discovery TLV and sub-TLVs SHOULD only be used with the PCE Discovery
	with the PCE Discovery NLRI.		NLRI.
	The format of the PCE Discovery TLV is shown as below:		The format of the PCE Discovery TLV is shown as below:
	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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ PCE Discovery Sub-TLVs (variable) ~		~ PCE Discovery Sub-TLVs (variable) ~
	skipping to change at page 7, line 12 ¶		skipping to change at page 7, line 12 ¶
	The registry will be initialized as shown in section 2.2 of this		The registry will be initialized as shown in section 2.2 of this
	document.		document.
	5. Security Considerations		5. Security Considerations
	Procedures and protocol extensions defined in this document do not		Procedures and protocol extensions defined in this document do not
	affect the BGP security model. See the 'Security Considerations'		affect the BGP security model. See the 'Security Considerations'
	section of [RFC4271] for a discussion of BGP security. Also refer to		section of [RFC4271] for a discussion of BGP security. Also refer to
	[RFC4272] and [RFC6952] for analysis of security issues for BGP.		[RFC4272] and [RFC6952] for analysis of security issues for BGP.
	6. Acknowledgements		6. Contributors
	The authors would like to thank Zhenbin Li, Hannes Gredler, Jan		The following individuals gave significant contributions to this
	Medved, Adrian Farrel and Julien Meuric for the valuable discussion		document:
	and comments.
	7. References		Takuya Miyasaka
			KDDI Corporation
			ta-miyasaka@kddi.com
	7.1. Normative References		7. Acknowledgements
	[I-D.ietf-idr-ls-distribution]		The authors would like to thank Zhenbin Li, Hannes Gredler, Jan
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.		Medved, Adrian Farrel, Julien Meuric and Jonathan Hardwick for the
	Ray, "North-Bound Distribution of Link-State and TE		valuable discussion and comments.
	Information using BGP", draft-ietf-idr-ls-distribution-13
	(work in progress), October 2015.		8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<http://www.rfc-editor.org/info/rfc4271>.		<http://www.rfc-editor.org/info/rfc4271>.
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 10 ¶
	[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.		[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
	Zhang, "OSPF Protocol Extensions for Path Computation		Zhang, "OSPF Protocol Extensions for Path Computation
	Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,		Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088,
	January 2008, <http://www.rfc-editor.org/info/rfc5088>.		January 2008, <http://www.rfc-editor.org/info/rfc5088>.
	[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.		[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
	Zhang, "IS-IS Protocol Extensions for Path Computation		Zhang, "IS-IS Protocol Extensions for Path Computation
	Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,		Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089,
	January 2008, <http://www.rfc-editor.org/info/rfc5089>.		January 2008, <http://www.rfc-editor.org/info/rfc5089>.
	7.2. Informative References		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
			S. Ray, "North-Bound Distribution of Link-State and
			Traffic Engineering (TE) Information Using BGP", RFC 7752,
			DOI 10.17487/RFC7752, March 2016,
			<http://www.rfc-editor.org/info/rfc7752>.
			8.2. Informative References
	[I-D.ietf-idr-te-lsp-distribution]		[I-D.ietf-idr-te-lsp-distribution]
	Dong, J., Chen, M., Gredler, H., Previdi, S., and J.		Dong, J., Chen, M., Gredler, H., Previdi, S., and J.
	Tantsura, "Distribution of MPLS Traffic Engineering (TE)		Tantsura, "Distribution of MPLS Traffic Engineering (TE)
	LSP State using BGP", draft-ietf-idr-te-lsp-		LSP State using BGP", draft-ietf-idr-te-lsp-
	distribution-04 (work in progress), December 2015.		distribution-04 (work in progress), December 2015.
	[I-D.ietf-idr-te-pm-bgp]		[I-D.ietf-idr-te-pm-bgp]
	Wu, Q., Previdi, S., Gredler, H., Ray, S., and J.		Previdi, S., Wu, Q., Gredler, H., Ray, S.,
	Tantsura, "BGP attribute for North-Bound Distribution of		Tantsura, j., Filsfils, C., and L. Ginsberg,
	Traffic Engineering (TE) performance Metrics", draft-ietf-		"BGP-LS Advertisement of IGP Traffic Engineering
	idr-te-pm-bgp-02 (work in progress), January 2015.		Performance Metric Extensions", draft-ietf-idr-te-pm-
			bgp-03 (work in progress), May 2016.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, DOI 10.17487/RFC4272, January 2006,		RFC 4272, DOI 10.17487/RFC4272, January 2006,
	<http://www.rfc-editor.org/info/rfc4272>.		<http://www.rfc-editor.org/info/rfc4272>.
	[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation		[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation
	Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,		Element (PCE) Discovery", RFC 4674, DOI 10.17487/RFC4674,
	October 2006, <http://www.rfc-editor.org/info/rfc4674>.		October 2006, <http://www.rfc-editor.org/info/rfc4674>.
	[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,		[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
	"A Backward-Recursive PCE-Based Computation (BRPC)		"A Backward-Recursive PCE-Based Computation (BRPC)
	Procedure to Compute Shortest Constrained Inter-Domain		Procedure to Compute Shortest Constrained Inter-Domain
	Traffic Engineering Label Switched Paths", RFC 5441,		Traffic Engineering Label Switched Paths", RFC 5441,
	DOI 10.17487/RFC5441, April 2009,		DOI 10.17487/RFC5441, April 2009,
	<http://www.rfc-editor.org/info/rfc5441>.		<http://www.rfc-editor.org/info/rfc5441>.
			[RFC5824] Kumaki, K., Ed., Zhang, R., and Y. Kamite, "Requirements
			for Supporting Customer Resource ReSerVation Protocol
			(RSVP) and RSVP Traffic Engineering (RSVP-TE) over a BGP/
			MPLS IP-VPN", RFC 5824, DOI 10.17487/RFC5824, April 2010,
			<http://www.rfc-editor.org/info/rfc5824>.
	[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the		[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
	Path Computation Element Architecture to the Determination		Path Computation Element Architecture to the Determination
	of a Sequence of Domains in MPLS and GMPLS", RFC 6805,		of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
	DOI 10.17487/RFC6805, November 2012,		DOI 10.17487/RFC6805, November 2012,
	<http://www.rfc-editor.org/info/rfc6805>.		<http://www.rfc-editor.org/info/rfc6805>.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
	skipping to change at page 9, line 29 ¶		skipping to change at page 9, line 44 ¶
	Dhruv Dhody		Dhruv Dhody
	Huawei Technologies		Huawei Technologies
	Divyashree Techno Park, Whitefield		Divyashree Techno Park, Whitefield
	Bangalore, Karnataka 560066		Bangalore, Karnataka 560066
	India		India
	Email: dhruv.ietf@gmail.com		Email: dhruv.ietf@gmail.com
	Jeff Tantsura		Jeff Tantsura
	Ericsson		Individual
	300 Holger Way
	San Jose, CA 95134
	US		US
	Email: jeff.tantsura@ericsson.com		Email: jefftant.ietf@gmail.com
			Kenji Kumaki
			KDDI Corporation
			Garden Air Tower, Iidabashi, Chiyoda-ku
			Tokyo 102-8460
			Japan
			Email: ke-kumaki@kddi.com
			Tomoki Murai
			Furukawa Network Solution Corp.
			5-1-9, Higashi-Yawata, Hiratsuka
			Kanagawa 254-0016
			Japan
			Email: murai@fnsc.co.jp
End of changes. 20 change blocks.
	44 lines changed or deleted		72 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/