draft-ietf-bess-mvpn-msdp-sa-interoperation-00.txt		draft-ietf-bess-mvpn-msdp-sa-interoperation-01.txt
	BESS Z. Zhang		BESS Z. Zhang
	Internet-Draft L. Giuliano		Internet-Draft L. Giuliano
	Updates: 6514 (if approved) Juniper Networks		Updates: 6514 (if approved) Juniper Networks
	Intended status: Standards Track March 22, 2018		Intended status: Standards Track April 25, 2018
	Expires: September 23, 2018		Expires: October 27, 2018
	MVPN and MSDP SA Interoperation		MVPN and MSDP SA Interoperation
	draft-ietf-bess-mvpn-msdp-sa-interoperation-00		draft-ietf-bess-mvpn-msdp-sa-interoperation-01
	Abstract		Abstract
	This document specifies the procedures for interoperation between		This document specifies the procedures for interoperation between
	MVPN Source Active routes and customer MSDP Source Active routes,		MVPN Source Active routes and customer MSDP Source Active routes,
	which is useful for MVPN provider networks offering services to		which is useful for MVPN provider networks offering services to
	customers with an existing MSDP infrastructure. Without the		customers with an existing MSDP infrastructure. Without the
	procedures described in this document, VPN-specific MSDP sessions are		procedures described in this document, VPN-specific MSDP sessions are
	required among the PEs that are customer MSDP peers.		required among the PEs that are customer MSDP peers.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 23, 2018.		This Internet-Draft will expire on October 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 21 ¶		skipping to change at page 2, line 21 ¶
	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.
	Table of Contents		Table of Contents
	1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2.1. MVPN RPT-SPT Mode . . . . . . . . . . . . . . . . . . . . 4		2.1. MVPN RPT-SPT Mode . . . . . . . . . . . . . . . . . . . . 4
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Assignment . . . . . . . . . . . . . . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Normative References . . . . . . . . . . . . . . . . . . 5		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	6.2. Informative References . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
			7.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Terminologies		1. Terminologies
	Familiarity with MVPN and MSDP protocols and procedures is assumed.		Familiarity with MVPN and MSDP protocols and procedures is assumed.
	Some terminologies are listed below for convenience.		Some terminologies are listed below for convenience.
	o ASM: Any source multicast.		o ASM: Any source multicast.
	o SPT: Source-specific Shortest-path Tree.		o SPT: Source-specific Shortest-path Tree.
	skipping to change at page 3, line 19 ¶		skipping to change at page 3, line 20 ¶
	similar to MSDP Source-Active messages [RFC3618]. One or more of the		similar to MSDP Source-Active messages [RFC3618]. One or more of the
	PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM		PEs, say PE1, either act as a C-RP and learn of (C-S,C-G) via PIM
	Register messages, or have MSDP sessions with some MSDP peers and		Register messages, or have MSDP sessions with some MSDP peers and
	learn (C-S,C-G) via MSDP SA messages. In either case, PE1 will then		learn (C-S,C-G) via MSDP SA messages. In either case, PE1 will then
	originate MVPN SA routes for other PEs to learn the (C-S,C-G).		originate MVPN SA routes for other PEs to learn the (C-S,C-G).
	[RFC6514] only specifies that a PE receiving the MVPN SA routes, say		[RFC6514] only specifies that a PE receiving the MVPN SA routes, say
	PE2, will advertise (C-S,C-G) C-multicast routes if it has		PE2, will advertise (C-S,C-G) C-multicast routes if it has
	corresponding (C-*,C-G) state learnt from its CE. PE2 may also have		corresponding (C-*,C-G) state learnt from its CE. PE2 may also have
	MSDP sessions with other C-RPs at its site, but [RFC6514] does not		MSDP sessions with other C-RPs at its site, but [RFC6514] does not
	specify that it advertise MSDP SA messages to those MSDP peers for		specify that it advertises MSDP SA messages to those MSDP peers for
	the (C-S,C-G) that it learns via MVPN SA routes. PE2 would need to		the (C-S,C-G) that it learns via MVPN SA routes. PE2 would need to
	have an MSDP session with PE1 (that advertised the MVPN SA messages)		have an MSDP session with PE1 (that advertised the MVPN SA messages)
	to learn the sources via MSDP SA messages, for it to advertise the		to learn the sources via MSDP SA messages, for it to advertise the
	MSDP SA to its local peers. To make things worse, unless blocked by		MSDP SA to its local peers. To make things worse, unless blocked by
	policy control, PE2 would in turn advertise MVPN SA routes because of		policy control, PE2 would in turn advertise MVPN SA routes because of
	those MSDP SA messages that it receives from PE1, which are redundant		those MSDP SA messages that it receives from PE1, which are redundant
	and unnecessary. Also notice that the PE1-PE2 MSDP session is VPN-		and unnecessary. Also notice that the PE1-PE2 MSDP session is VPN-
	specific, while the BGP sessions over which the MVPN routes are		specific, while the BGP sessions over which the MVPN routes are
	advertised are not.		advertised are not.
	skipping to change at page 3, line 44 ¶		skipping to change at page 3, line 45 ¶
	o MSDP SA refreshes are replaced with BGP hard state.		o MSDP SA refreshes are replaced with BGP hard state.
	o Route Reflectors can be used instead of having peer-to-peer		o Route Reflectors can be used instead of having peer-to-peer
	sessions.		sessions.
	o VPN extranet mechanisms can be used to propagate (C-S,C-G)		o VPN extranet mechanisms can be used to propagate (C-S,C-G)
	information across VPNs with flexible policy control.		information across VPNs with flexible policy control.
	While MSDP Source Active routes contain the source, group and RP		While MSDP Source Active routes contain the source, group and RP
	address of a given multicast flow, MVPN Source Active routes only		addresses of a given multicast flow, MVPN Source Active routes only
	contain the source and group. MSDP requires the RP address		contain the source and group. MSDP requires the RP address
	information in order to perform peer-RPF. Therefore, this document		information in order to perform peer-RPF. Therefore, this document
	describes how to convey the RP address information into the MVPN		describes how to convey the RP address information into the MVPN
	Source Active route using an Extended Community so this information		Source Active route using an Extended Community so this information
	can be shared with an existing MSDP infrastructure.		can be shared with an existing MSDP infrastructure.
	The procedures apply to Global Table Multicast (GTM) [RFC7716] as		The procedures apply to Global Table Multicast (GTM) [RFC7716] as
	well.		well.
	2.1. MVPN RPT-SPT Mode		2.1. MVPN RPT-SPT Mode
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	(C-S,C-G) as a received MSDP SA message (and advertise corresponding		(C-S,C-G) as a received MSDP SA message (and advertise corresponding
	MSDP message). In that case, if the selected best MVPN SA route does		MSDP message). In that case, if the selected best MVPN SA route does
	not have the "MVPN SA RP-address EC" but another route for the same		not have the "MVPN SA RP-address EC" but another route for the same
	(C-S, C-G) does, then the best route with the EC SHOULD be chosen.		(C-S, C-G) does, then the best route with the EC SHOULD be chosen.
	As a result, when/if the best MVPN SA route with the EC changes, a		As a result, when/if the best MVPN SA route with the EC changes, a
	new MSDP SA message is advertised if the RP address determined		new MSDP SA message is advertised if the RP address determined
	according to the newly selected MVPN SA route is different from		according to the newly selected MVPN SA route is different from
	before. The previously advertised MSDP SA message with the older RP		before. The previously advertised MSDP SA message with the older RP
	address will be timed out.		address will be timed out.
	4. IANA Considerations		4. Security Considerations
			RFC6514 specifies the procedure for a PE to generate an MVPN SA upon
			discovering a (C-S,C-G) flow (e.g. via a received MSDP SA message) in
			a VPN. This document extends this capability in the reverse
			direction - upon receiving an MVPN SA route in a VPN generate
			corresponding MSDP SA and advertise to MSDP peers in the same VPN.
			As such, the capabilities specified in this document introduce no
			additional security considerations beyond those already specified in
			RFC6514 and RFC3618. Moreover, the capabilities specified in this
			document actually eliminate the control message amplification that
			exists today where VPN-specific MSDP sessions are required among the
			PEs that are customer MSDP peers, which lead to redundant messages
			(MSDP SAs and MVPN SAs) being carried in parallel between PEs.
			5. IANA Assignment
	This document introduces a new Transitive IPv4 Address Specific		This document introduces a new Transitive IPv4 Address Specific
	Extended Community "MVPN SA RP-address Extended Community". An IANA		Extended Community "MVPN SA RP-address Extended Community". IANA has
	request will be submitted for a subcode of 0x20 (pending approval and		registered subcode 0x20 in the Transitive IPv4-Address-Specific
	subject to change) in the Transitive IPv4-Address-Specific Extended		Extended Community Sub-Types registry for this EC.
	Community Sub-Types registry.
	5. Acknowledgements		6. Acknowledgements
	The authors thank Eric Rosen and Vinod Kumar for their review,		The authors thank Eric Rosen and Vinod Kumar for their review,
	comments, questions and suggestions for this document. The authors		comments, questions and suggestions for this document. The authors
	also thank Yajun Liu for her review and comments.		also thank Yajun Liu for her review and comments.
	6. References		7. References
	6.1. Normative References		7.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source		[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
	Discovery Protocol (MSDP)", RFC 3618,		Discovery Protocol (MSDP)", RFC 3618,
	DOI 10.17487/RFC3618, October 2003,		DOI 10.17487/RFC3618, October 2003,
	<https://www.rfc-editor.org/info/rfc3618>.		<https://www.rfc-editor.org/info/rfc3618>.
	[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP		[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
	Encodings and Procedures for Multicast in MPLS/BGP IP		Encodings and Procedures for Multicast in MPLS/BGP IP
	VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,		VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
	<https://www.rfc-editor.org/info/rfc6514>.		<https://www.rfc-editor.org/info/rfc6514>.
	6.2. Informative References		7.2. Informative References
	[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,		[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K.,
	and D. Pacella, "Global Table Multicast with BGP Multicast		and D. Pacella, "Global Table Multicast with BGP Multicast
	VPN (BGP-MVPN) Procedures", RFC 7716,		VPN (BGP-MVPN) Procedures", RFC 7716,
	DOI 10.17487/RFC7716, December 2015,		DOI 10.17487/RFC7716, December 2015,
	<https://www.rfc-editor.org/info/rfc7716>.		<https://www.rfc-editor.org/info/rfc7716>.
	Authors' Addresses		Authors' Addresses
	Zhaohui Zhang		Zhaohui Zhang
End of changes. 12 change blocks.
	20 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/