Network Working Group Rahul Aggarwal (Juniper Networks)
Internet Draft Wim Henderickx (Alcatel-Lucent)
Intended Status: Proposed Standard Praveen Muley (Alcatel-Lucent)
Expiration Date: January 2010 Ray Qiu (Alcatel-Lucent)
Yakov Rekhter (Juniper Networks)
Use of Wildcard in S-PMSI Auto-Discovery Routes
draft-rekhter-mvpn-wildcard-spmsi-01.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 and License Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Aggarwal, Rekhter [Page 1]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-01.txt July 2009
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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
Aggarwal, Rekhter [Page 2]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-01.txt July 2009
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
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-01.txt July 2009
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-01.txt July 2009
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-01.txt July 2009
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.
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.
+ 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:
Aggarwal, Rekhter [Page 6]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-01.txt July 2009
+ 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.
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
Aggarwal, Rekhter [Page 7]
Internet Draft draft-rekhter-mvpn-wildcard-spmsi-01.txt July 2009
10. Non-normative References
11. Author Information
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 Qiu
Alcatel-Lucent
e-mail: Ray.Qiu@alcatel-lucent.com
Yakov Rekhter
Juniper Networks, Inc.
e-mail: yakov@juniper.net
Aggarwal, Rekhter [Page 8]