BESS R. Kebler, Ed.
Internet-Draft J. Zhang
Intended status: Standards Track Juniper Networks
Expires: September 10, 2015 A. Dolganow
J. Kotalwar
Alcatel-Lucent
H. Sipra
Google
March 9, 2015
MVPN UMH Procedure Based on Source Active A-D Route
draft-kebler-bess-sa-pref-00
Abstract
This document define new procedures to use Source-Active A-D routes
to influence the UMH selection procedures at a downstream PE in
certain deployments. These procedures allow some greater flexibility
to influence the UMH selection based on more than just the unicast
route to the source.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Kebler, et al. Expires September 10, 2015 [Page 1]
Internet-Draft MVPN Source-Active Preference March 2015
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedure Details . . . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
It may be desirable to influence the UMH selection result for a given
customer multicast group, without influencing the UMH procedures for
all the other customer groups with the same source. For example, if
it is desirable for traffic to be chosen for S1,G1 from ingress PE,
and for S1,G2 for a different ingress PE, it is not possible to
accomplish with the exisitng UMH procedures that are based solely on
the Source address.
Consider the case when an Anycast source address is being used to
source the content from two headends. If the content were preferred
from one headend for certain groups, and the other headend for other
groups based on some policy on the ingress PEs depending on the
particular groups, then this would not be possible with a source
based UMH method.
This document define new procedures to use Source-Active A-D routes
to influence the UMH selection procedures at an egress PE, taking
both the Source and Group into account to allow greater flexibility
in the UMH procedures.
As defined in RFC 6514, An ingress PE will advertise a (C-S,C-G)
Source Active A-D route if it receives a PIM Register message or MSDP
message saying that C-S is a source for C-G. When advertising the
Source-Active A-D route, a policy can be applied at the ingress PEs
(e.g., BGP communities) to help influence the BGP route selection of
the egress PEs. The ingress PE can be configured to include some
communities to the Source-Active A-D routes based on that policy.
The egress PEs can then be configured to set the route preference
based on the received communities. The exact details on procedures
Kebler, et al. Expires September 10, 2015 [Page 2]
Internet-Draft MVPN Source-Active Preference March 2015
to influence BGP route selection are outside the scope of this
document. The selected Source Active A-D route will then be used to
influence the UMH selection.
2. Applicability
These procedures are applicable only when procedures in Section 10 of
RFC 6513 are being used to "Eliminate PE-PE Distribution of (C-*,C-G)
State". Furthermore, the procedures in this document are restricted
to the case when the ingress PEs are configured either MSDP or as RP.
The typical use-case would be an IPTV deployment when a headend is
located behind a set of PEs and those PEs can be configured as RPs or
MSDP peers. These procedures are not applicable for groups in the
SSM range.
3. Procedure Details
RFC 6513 describes procedures to build the "UMH Route Candidate Set"
and then select the single route from the set to be the "Selected UMH
Route". The procedures are modified to prefer, from the "UMH Route
Candidate Set", the Upstream PE that has advertised the best (as
determined by the BGP route selection procedures) Source-Active A-D
route.
It may not be obvious on how to match the UMH candidate to the
originator of the Source-Active A-D route since the NLRI of the
Source Active A-D route does not specify the originator of the route.
For MVPN procedures, refer to the extranet draft
[I-D.ietf-bess-mvpn-extranet] (section 7.4). For Global
Table Multicast (GTM) procedures, refer to the GTM draft
[I-D.ietf-bess-mvpn-global-table-mcast] (section 2.8.1).
If the UMH is selected solely based on best Source Active A-D route
without considering the UMH Route Candidate Set as defined in RFC
6514, then it would have the drawback that a UMH may be chosen which
does not have reachability to the source through a vrf interface.
Also, it may take some time for an RP to determine that the source
has stopped sending traffic and the unicast reachability may converge
before the Source Active A-D routes are withdrawn. As a result,
using the UMH Route Candidate Set as the base can improve the
convergence on the egress PEs.
4. IANA Considerations
None
Kebler, et al. Expires September 10, 2015 [Page 3]
Internet-Draft MVPN Source-Active Preference March 2015
5. Security Considerations
There are no security considerations for this design other than what
is already in the base MVPN specifications.
6. Acknowledgements
The authors want to thank Eric Rosen for his review and useful
feedback.
7. Normative References
[]
Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., Henderickx,
W., Morin, T., Muley, P., Qiu, R., and I. Wijnands,
"Extranet Multicast in BGP/IP MPLS VPNs", draft-ietf-bess-
mvpn-extranet-00 (work in progress), November 2014.
[I-D.ietf-bess-mvpn-global-table-mcast]
Zhang, J., Giuliano, L., Rosen, E., Subramanian, K.,
Pacella, D., and J. Schiller, "Global Table Multicast with
BGP-MVPN Procedures", draft-ietf-bess-mvpn-global-table-
mcast-00 (work in progress), November 2014.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012.
Authors' Addresses
Robert Kebler (editor)
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rkebler@juniper.net
Kebler, et al. Expires September 10, 2015 [Page 4]
Internet-Draft MVPN Source-Active Preference March 2015
Jeffrey Zhang
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: zzhang@juniper.net
Andrew Dolganow
Alcatel-Lucent
600 March Rd.
Ottawa, Ontario K2K 2E6
Canada
Email: andrew.dolganow@alcatel-lucent.com
Jayant Kotalwar
Alcatel-Lucent
701 East Middlefield Rd
Mountain View, California 94043
United States
Email: jayant.kotalwar@alcatel-lucent.com
Hassan Sipra
Google
Email: hisipra@google.com
Kebler, et al. Expires September 10, 2015 [Page 5]