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/