Network Working Group Rahul Aggarwal (Juniper Networks)
Internet Draft Wim Henderickx (Alcatel-Lucent)
Expiration Date: August 2011 Praveen Muley (Alcatel-Lucent)
Intended Status: Proposed Standard Ray Qiu (Huawei)
Yakov Rekhter (Juniper Networks)
February 14, 2011
Use of Wildcard in S-PMSI Auto-Discovery Routes
draft-rekhter-mvpn-wildcard-spmsi-04.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (c) 2010 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
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.
Aggarwal, Rekhter [Page 1]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
Abstract
The current MVPN specifications do not define encoding and procedures
for advertising in a single route binding of multiple multicast
streams of a given MVPN customer to a single provider's tunnel. This
document defines such encoding and procedures. These procedures allow
in certain situations to reduce MVPN control plane load (note though
that these procedures have no impact on the data plane load). The
procedures specified in this document assume that BGP is used for
transmission of MVPN customers' routing information within the
service provider(s) infrastructure.
Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction
An S-PMSI auto-discovery route (A-D route), as defined in [MVPN-BGP],
advertises binding of a given MVPN customer multicast flow (C-
multicast flow) to a particular provider tunnel (P-tunnel). While the
definition and procedures specified in [MVPN-BGP] support binding of
multiple C-multicast flows to the same P-tunnel (by having multiple
S-PMSI A-D routes advertise the same P-tunnel), they do not support
the ability to advertise such a binding in a single S-PMSI A-D route.
The ability of a PE to advertise binding of multiple C-multicast
flows, all originating from the site(s) of a given MVPN connected to
that PE, to a single P-tunnel in a single S-PMSI A-D route, rather
than in multiple S-PMSI A-D routes (one per each C-multicast flow),
improves control plane scalability, as it reduces the number of S-
PMSI A-D routes. Note however, that the ability to advertise binding
of multiple C-multicast flows to a single P-tunnel in a single S-PMSI
A-D route has no impact on the forwarding/data plane scalability, as
it does not reduces the number of P-tunnels, relative to the scenario
where each C-multicast flow is advertised via its own S-PMSI A-D
route, while all these routes advertise the same P-tunnel.
One possible application of advertising binding of multiple C-
multicast flows to a single P-tunnel in a single S-PMSI A-D route is
when these are PIM-SM in ASM mode flows. In this case a PE router
connected to an MVPN customer's site that contains customer's RP (C-
RP) could bind all the C-multicast flows traveling along a customer's
RPT tree to a single P-tunnel, and advertise such binding in a single
Aggarwal, Rekhter [Page 2]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
S-PMSI A-D route. Likewise, a PE router connected to an MVPN
customer's site that contains multiple (multicast) sources, all
sending to the same (multicast) group, could bind all the C-mulicast
flows for that group originated by these sources to a single P-
tunnel, and advertise such binding in a single S-PMSI A-D route.
Another possible application of advertising binding of multiple C-
multicast flows to a single P-tunnel in a single S-PMSI A-D route is
when these are PIM-Bidir flows. In this case a PE router could bind
to a single P-tunnel all the C-multicast flows for the same
(multicast) group that have been originated within the site(s) of a
given MVPN connected to that PE, and advertise such binding in a
single S-PMSI A-D route.
Another possible application of advertising binding of multiple C-
multicast flows to a single P-tunnel in a single S-PMSI A-D route is
when these are PIM-SM in SSM mode flows. In this case a PE router
could bind to a single P-tunnel all the C-multicast flows coming from
a given (multicast) source located in a site connected to that PE.
Yet another possible application of advertising binding of multiple
C-multicast flows to a single P-tunnel in a single S-PMSI A-D route
is to carry in that P-tunnel all the C-multicast flows originated
within the site(s) of a given MVPN connected to a given PE.
This document defines OPTIONAL extensions to the procedures specified
in [MVPN-BGP]. These extensions allow to advertise in a single S-PMSI
A-D route binding of multiple C-multicast flows to a single P-tunnel.
The extensions are based on the notion of a "wildcard".
In order to use the extensions specified in this document with a
particular MVPN, all the PEs that have sites of that MVPN MUST
support these extensions.
The procedures specified in this document assume that BGP is used for
transmission of MVPN customers' multicast (C-multicast) routing
information within the service provider(s) infrastructure among the
PE routers ([MVPN-BGP]).
Aggarwal, Rekhter [Page 3]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
2. Encoding of wildcard in S-PMSI A-D routes
As specified in [MVPN-BGP], the NLRI of an S-PMSI A-D route has the
following format:
+-----------------------------------+
| RD (8 octets) |
+-----------------------------------+
| Multicast Source Length (1 octet) |
+-----------------------------------+
| Multicast Source (Variable) |
+-----------------------------------+
| Multicast Group Length (1 octet) |
+-----------------------------------+
| Multicast Group (Variable) |
+-----------------------------------+
| Originating Router's IP Addr |
+-----------------------------------+
This document uses a zero value in Mutlicast Source Length or
Multicast Group Length field to indicate a wildcard value for the
respective field. This document defines procedures for the following
two combinations of wildcard S-PMSI encodings:
+ (C-*, C-G): Source Wildcard, Group specified
+ (C-S, C-*): Source specified, Group Wildcard
+ (C-*, C-*): Source Wildcard, Group Wildcard
3. Procedures for (C-*, C-G) S-PMSI A-D routes
This document covers the use of (C-*, C-G) S-PMSI A-D routes for only
the C-multicast flows when C-G is not in the SSM range. Use of (C-*,
C-G) S-PMSI A-D routes for other C-multicast flows is outside the
scope of this document.
When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*,
C-G), the PE MUST use the P-tunnel advertised in this route for
sending any PIM-SM in ASM mode or PIM-Bidir C-multicast flows for
that C-G that it needs to send (downstream) to other PEs, except for
the C-multicast flows that the PE already bound to specific (C-S, C-
G)s S-PMSIs. Just like with (C-S, C-G) S-PMSI A-D routes, the
criteria for originating (C-*, C-G) S-PMSI A-D routes is local to the
originating PE.
When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*, C-
Aggarwal, Rekhter [Page 4]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
G), the PE follows the procedures specified in [MVPN-BGP], except for
the case where the PE does not originate a Shared Tree Join C-
multicast route for (C-*, C-G), and for every Source Tree Join C-
multicast route for (C-S, C-G) originated by the PE, the PE already
accepted a (specific) (C-S, C-G) S-PMSI A-D route. In that case the
PE need not take any further action upon receiving the S-PMSI A-D
route with (C-*, C-G) NLRI.
If an implementation supports (C-*, C-G) S-PMSI A-D routes, then the
implementation MUST support receiving (C-S, C-*) and (C-*, C-*) S-
PMSI A-D routes, and MAY support originating (C-S, C-*) and (C-*,
C-*) S-PMSI A-D routes.
4. Procedures for (C-S, C-*) S-PMSI A-D routes
This document covers the use of (C-S, C-*) S-PMSI A-D routes for only
the C-multicast flows when C-G is in the SSM range. Use of (C-S,
C-*) S-PMSI A-D routes for other C-multicast flows is outside the
scope of this document.
When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-S,
C-*), the PE MUST use the P-tunnel advertised in this route for
sending any PIM-SM in SSM mode C-multicast flows for that C-S that it
needs to send (downstream) to other PEs, except for the C-multicast
flows that the PE already bound to specific (C-S, C-G)s S-PMSIs.
Just like with (C-S, C-G) S-PMSI A-D routes, the criteria for
originating (C-S, C-*) S-PMSI A-D routes is local to the originating
PE.
When a PE receives an S-PMSI A-D route whose NLRI specifies (C-S,
C-*), the PE follows the procedures specified in [MVPN-BGP], except
for the case where for every Source Tree Join C-multicast route for
(C-S, C-G) originated by the PE, the PE already accepted a (specific)
(C-S, C-G) S-PMSI A-D route. In that case the PE need not take any
further action upon receiving the S-PMSI A-D route with (C-S, C-*)
NLRI.
If an implementation supports (C-S, C-*) S-PMSI A-D routes, then the
implementation MUST support receiving (C-*, C-G) and (C-*, C-*) S-
PMSI A-D routes, and MAY support originating (C-*, C-G) and (C-*,
C-*) S-PMSI A-D routes.
Aggarwal, Rekhter [Page 5]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
5. Procedures for (C-*, C-*) S-PMSI A-D routes
(C-*, C-*) S-PMSI A-D routes are expected to be used when for a given
MVPN a PE has a policy not to use I-PMSI for carrying multicast
traffic originated in the MVPN's site(s) connected to that PE (this
is known as "S-PMSI only" mode).
When a PE advertises an S-PMSI A-D route whose NLRI specifies (C-*,
C-*), the PE MUST use the P-tunnel advertised in this route for
sending any C-multicast flows that it needs to send (downstream) to
other PEs, except for the C-multicast flows that the PE already bound
to either specific (C-*, C-G)s S-PMSIs, or specific (C-S, C-G)s S-
PMSIs.
Just like with (C-S, C-G) S-PMSI A-D routes, the criteria for
originating (C-*, C-*) S-PMSI A-D routes is local to the originating
PE. However, the following criteria must be implemented:
+ An implementation MUST support the ability to trigger origination
of a (C-*, C-*) S-PMSI A-D route from a given VRF on a given PE
when this PE receives (from some other PE(s)) either a Source
Tree Join C-multicast route with the C-S carried in the route
being reachable via one of the PE-CE interfaces of that VRF, or a
Shared Tree Join C-multicast route with the C-RP carried in that
route being reachable via one of the PE-CE interfaces on that
VRF.
+ An implementation MUST also support the ability to trigger
origination of a (C-*, C-*) S-PMSI A-D route from a given VRF on
a given PE at provisioning time on that PE.
To facilitate description of the procedures for receiving (C-*, C-*)
S-PMSI A-D routes, we introduce the following definitions:
+ We say that an (C-S, C-G) S-PMSI A-D route received by a PE
"matches" a Source Tree Join C-multicast route for (C-S, C-G)
originated by that PE if the upstream PE of that route is the PE
that originates the S-PMSI A-D route.
+ We say that an (C-*, C-G) S-PMSI A-D route received by a PE
"matches" a Source Tree Join C-multicast route for (C-S, C-G)
originated by that PE if the upstream PE of that route is the PE
that originates the S-PMSI A-D route, and C-G is not in the SSM
range.
Aggarwal, Rekhter [Page 6]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
+ We say that an (C-*, C-G) S-PMSI A-D route received by a PE
"matches" a Shared Tree Join C-multicast route for (C-*, C-G)
originated by that PE if the upstream PE of that route is the PE
that originates the S-PMSI A-D route, and C-G is not in the SSM
range.
+ We say that an (C-S, C-*) S-PMSI A-D route received by a PE
"matches" a Source Tree Join C-multicast route for (C-S, C-G)
originated by that PE if the upstream PE of that route is the PE
that originates the S-PMSI A-D route, and C-G is in the SSM
range.
When a PE receives an S-PMSI A-D route whose NLRI specifies (C-*,
C-*), the PE follows the procedures specified in [MVPN-BGP], except
when:
+ for all the Source Tree Join C-multicast routes originated by the
PE, the PE already accepted either a matching (C-S, C-G), or a
matching (C-*, C-G), or a matching (C-S, C-*) S-PMSI A-D route,
AND
+ for all the Shared tree Join C-multicast routes originated by the
PE, the PE already accepted a matching (C-*, C-G) S-PMSI A-D
route,
in which case the PE need not take any further action upon receiving
the S-PMSI A-D route with NLRI (C-*, C-*).
If an implementation supports (C-*, C-*) S-PMSI A-D routes, then the
implementation MUST support receiving (C-*, C-G) and (C-S, C-*) S-
PMSI A-D routes, and MAY support originating (C-*, C-G) and (C-S,
C-*) S-PMSI A-D routes.
6. IANA Considerations
This document introduces no new IANA Considerations.
Aggarwal, Rekhter [Page 7]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
7. Security Considerations
This document introduces no new Security Considerations, above and
beyond what is already specified in [MVPN] and [MVPN-BGP].
8. Acknowledgements
Many thanks to Thomas Morin for his contributions, review, and
comments.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress
[MVPN-BGP], R. Aggarwal, E. Rosen, T. Morin, Y. Rekhter, "BGP
Encodings for Multicast in MPLS/BGP IP VPNs", draft-ietf-
l3vpn-2547bis-mcast-bgp, work in progress
10. Non-normative References
11. Authors' Addresses
Rahul Aggarwal
Juniper Networks, Inc.
e-mail: rahul@juniper.net
Wim Henderickx
Alcatel-Lucent
e-mail: wim.henderickx@alcatel-lucent.be
Praveen Muley
Alcatel-Lucent
e-mail: Praveen.Muley@alcatel-lucent.com
Ray (Lei) Qiu
2330 Central Expressway
Santa Clara, CA 95050
Aggarwal, Rekhter [Page 8]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-04.txtFeburary 14, 2011
USA
e-mail: rayq@huawei.com
Yakov Rekhter
Juniper Networks, Inc.
e-mail: yakov@juniper.net
Aggarwal, Rekhter [Page 9]