draft-ietf-bess-mvpn-msdp-sa-interoperation-03.txt		draft-ietf-bess-mvpn-msdp-sa-interoperation-04.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 September 2, 2019		Intended status: Standards Track October 16, 2019
	Expires: March 5, 2020		Expires: April 18, 2020
	MVPN and MSDP SA Interoperation		MVPN and MSDP SA Interoperation
	draft-ietf-bess-mvpn-msdp-sa-interoperation-03		draft-ietf-bess-mvpn-msdp-sa-interoperation-04
	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,		Multicast Virtual Private Network (MVPN) Source Active routes and
	which is useful for MVPN provider networks offering services to		customer Multicast Source Discovery Protocol (MSDP) Source Active
	customers with an existing MSDP infrastructure. Without the		routes, which is useful for MVPN provider networks offering services
			to 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. This document
			updates RFC6514.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in RFC2119.		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 March 5, 2020.		This Internet-Draft will expire on April 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	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.
	Table of Contents		Table of Contents
	1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. MVPN RPT-SPT Mode . . . . . . . . . . . . . . . . . . . . 4		2.1. MVPN RPT-SPT Mode . . . . . . . . . . . . . . . . . . . . 4
	3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 5		4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	5. IANA Assignment . . . . . . . . . . . . . . . . . . . . . . . 5		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	7.1. Normative References . . . . . . . . . . . . . . . . . . 6		7.1. Normative References . . . . . . . . . . . . . . . . . . 6
	7.2. Informative 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.
	skipping to change at page 4, line 11 ¶		skipping to change at page 4, line 16 ¶
	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
	For comparison, another method of supporting customer ASM is		For comparison, another method of supporting customer ASM is
	generally referred to "rpt-spt" mode. Section "13. Switching from a		generally referred to as "rpt-spt" mode. Section "13. Switching
	Shared C-Tree to a Source C-Tree" of [RFC6514] specifies the MVPN SA		from a Shared C-Tree to a Source C-Tree" of [RFC6514] specifies the
	procedures for that mode, but those SA routes are replacement for		MVPN SA procedures for that mode, but those SA routes are a
	PIM-ASM assert and (s,g,rpt) prune mechanisms, not for source		replacement for PIM-ASM assert and (s,g,rpt) prune mechanisms, not
	discovery purpose. MVPN/MSDP SA interoperation for the "rpt-spt"		for source discovery purposes. MVPN/MSDP SA interoperation for the
	mode is outside of the scope of this document. In the rest of the		"rpt-spt" mode is outside of the scope of this document. In the rest
	document, the "spt-only" mode is assumed.		of the document, the "spt-only" mode is assumed.
	3. Specification		3. Specification
	The MVPN PEs that act as customer RPs or have one or more MSDP		The MVPN PEs that act as customer RPs or have one or more MSDP
	sessions in a VPN (or the global table in case of GTM) are treated as		sessions in a VPN (or the global table in case of GTM) are treated as
	an MSDP mesh group for that VPN (or the global table). In the rest		an MSDP mesh group for that VPN (or the global table). In the rest
	of the document, it is referred to as the PE mesh group. It MUST not		of the document, it is referred to as the PE mesh group. It MUST NOT
	include other MSDP speakers, and is integrated into the rest of MSDP		include other MSDP speakers, and is integrated into the rest of MSDP
	infrastructure for the VPN (or the global table) following normal		infrastructure for the VPN (or the global table) following normal
	MSDP rules and practices.		MSDP rules and practices.
	When an MVPN PE advertises an MVPN SA route following procedures in		When an MVPN PE advertises an MVPN SA route following procedures in
	[RFC6514] for the "spt-only" mode, it SHOULD attach an "MVPN SA RP-		[RFC6514] for the "spt-only" mode, it SHOULD attach an "MVPN SA RP-
	address Extended Community". This is a Transitive IPv4-Address-		address Extended Community". This is a Transitive IPv4-Address-
	Specific Extended Community. The Local Administrative field is set		Specific Extended Community. The Local Administrative field is set
	to zero and the Global Administrative field is set to an RP address		to zero and the Global Administrative field is set to an RP address
	determined as the following:		determined as the following:
	o If the (C-S,C-G) is learnt as result of PIM Register mechanism,		o If the (C-S,C-G) is learnt as result of PIM Register mechanism,
	the local RP address for the C-G is used.		the local RP address for the C-G is used.
	o If the (C-S,C-G) is learnt as result of incoming MSDP SA messages,		o If the (C-S,C-G) is learnt as result of incoming MSDP SA messages,
	the RP address in the selected MSDP SA message is used.		the RP address in the selected MSDP SA message is used.
	In addition to procedures in [RFC6514], an MVPN PE may be provisioned		In addition to procedures in [RFC6514], an MVPN PE may be provisioned
	to generate MSDP SA messages from received MVPN SA routes, with or		to generate MSDP SA messages from received MVPN SA routes, with or
	without fine policy control. If a received MVPN SA route is to		without fine grained policy control. If a received MVPN SA route is
	trigger MSDP SA message, it is treated as if a corresponding MSDP SA		to trigger MSDP SA message, it is treated as if a corresponding MSDP
	message was received from within the PE mesh group and normal MSDP		SA message was received from within the PE mesh group and normal MSDP
	procedure is followed (e.g. an MSDP SA message is advertised to other		procedure is followed (e.g. an MSDP SA message is advertised to other
	MSDP peers outside the PE mesh group). The (S,G) information comes		MSDP peers outside the PE mesh group). The (S,G) information comes
	from the (C-S,C-G) encoding in the MVPN SA NLRI and the RP address		from the (C-S,C-G) encoding in the MVPN SA NLRI and the RP address
	comes from the "MVPN SA RP-address EC" mentioned above. If the		comes from the "MVPN SA RP-address EC" mentioned above. If the
	received MVPN SA route does not have the EC (this could be from a		received MVPN SA route does not have the EC (this could be from a
	legacy PE that does not have the capability to attach the EC), the		legacy PE that does not have the capability to attach the EC), the
	local RP address for the C-G is used. In that case, it is possible		local RP address for the C-G is used. In that case, it is possible
	that receiving PE's RP for the C-G is actually the MSDP peer to which		that receiving PE's RP for the C-G is actually the MSDP peer to which
	the generated MSDP message is advertised, causing the peer to discard		the generated MSDP message is advertised, causing the peer to discard
	it due to RPF failure. To get around that problem the peer SHOULD		it due to RPF failure. To get around that problem the peer SHOULD
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 43 ¶
	direction - upon receiving an MVPN SA route in a VPN generate		direction - upon receiving an MVPN SA route in a VPN generate
	corresponding MSDP SA and advertise to MSDP peers in the same VPN.		corresponding MSDP SA and advertise to MSDP peers in the same VPN.
	As such, the capabilities specified in this document introduce no		As such, the capabilities specified in this document introduce no
	additional security considerations beyond those already specified in		additional security considerations beyond those already specified in
	RFC6514 and RFC3618. Moreover, the capabilities specified in this		RFC6514 and RFC3618. Moreover, the capabilities specified in this
	document actually eliminate the control message amplification that		document actually eliminate the control message amplification that
	exists today where VPN-specific MSDP sessions are required among the		exists today where VPN-specific MSDP sessions are required among the
	PEs that are customer MSDP peers, which lead to redundant messages		PEs that are customer MSDP peers, which lead to redundant messages
	(MSDP SAs and MVPN SAs) being carried in parallel between PEs.		(MSDP SAs and MVPN SAs) being carried in parallel between PEs.
	5. IANA Assignment		5. IANA Considerations
	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". IANA has		Extended Community "MVPN SA RP-address Extended Community". IANA has
	registered subcode 0x20 in the Transitive IPv4-Address-Specific		registered subcode 0x20 in the Transitive IPv4-Address-Specific
	Extended Community Sub-Types registry for this EC.		Extended Community Sub-Types registry for this EC.
	6. 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
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 20 ¶
	7. References		7. References
	7.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
	Discovery Protocol (MSDP)", RFC 3618,
	DOI 10.17487/RFC3618, October 2003,
	<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>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	7.2. Informative References		7.2. Informative References
			[RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source
			Discovery Protocol (MSDP)", RFC 3618,
			DOI 10.17487/RFC3618, October 2003,
			<https://www.rfc-editor.org/info/rfc3618>.
	[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
	Juniper Networks		Juniper Networks
End of changes. 15 change blocks.
	30 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/