Network Working Group T. Morin, Ed.
Internet-Draft France Telecom R&D
Intended status: Informational B. Niven-Jenkins, Ed.
Expires: April 11, 2008 BT
Y. Kamite
NTT Communications
R. Zhang
BT
N. Leymann
Deutsche Telekom
October 09, 2007
Considerations about Multicast for BGP/MPLS VPN Standardization
draft-morin-l3vpn-mvpn-considerations-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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.
This Internet-Draft will expire on April 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The current proposal for multicast in BGP/MPLS includes multiple
Morin, et al. Expires April 11, 2008 [Page 1]
Internet-Draft Multicast VPN Considerations October 2007
alternative mechanisms for some of the required building blocks of
the solution. The aim of this document is to leverage previously
documented requirements to identify the key elements and help move
forward solution design, toward the definition of a standard having a
well defined set of mandatory procedures. The different proposed
alternative mechanisms are examined in the light of requirements
identified for multicast in L3VPNs, and suggestions are made about
which of these mechanisms standardization should favor. Issues
related to existing deployments of early implementations are also
addressed.
Requirements Language
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 [RFC2119].
Morin, et al. Expires April 11, 2008 [Page 2]
Internet-Draft Multicast VPN Considerations October 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Examining alternatives mechanisms for MVPN functions . . . . . 4
3.1. MVPN auto-discovery . . . . . . . . . . . . . . . . . . . 4
3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 6
3.3. PE-PE Transmission of C-Multicast Routing . . . . . . . . 8
3.4. Encapsulation techniques for P-multicast trees . . . . . . 11
3.5. Inter-AS deployments options . . . . . . . . . . . . . . . 12
4. Co-located RPs . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Existing deployments . . . . . . . . . . . . . . . . . . . . . 15
6. Summary of recommendations . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. Informative References . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Morin, et al. Expires April 11, 2008 [Page 3]
Internet-Draft Multicast VPN Considerations October 2007
1. Introduction
The current proposal for multicast in BGP/MPLS
[I-D.ietf-l3vpn-2547bis-mcast] includes multiple alternative
mechanisms for some of the required building blocks of the solution.
However, it does not identify the core set of mechanisms which must
be implemented in order to ensure interoperability. This may lead to
a situation where implementations may support different subsets of
the available optional mechanisms leading to implementations that do
not interoperate.
The aim of this document is to leverage the already expressed
requirements [RFC4834] to identify the mechanisms that the authors
believe are good candidates for being part of a core set of mandatory
mechanisms which can be used to provide a base for interoperable
solutions.
This document will go through the different building blocks of the
solution and provide the authors' recommendations as to which
mechanisms the authors' favor for each building block, while
considering the requirements already defined and the goal of a fully-
interoperable standard.
Considering the history of the multicast VPN proposals and
implementations, the authors also consider it useful to discuss how
existing deployments of early implementations
[I-D.rosen-vpn-mcast][I-D.raggarwa-l3vpn-2547-mvpn] can fit in the
picture, and provide suggestions in this respect.
2. Terminology
Please refer to [I-D.ietf-l3vpn-2547bis-mcast] and [RFC4834].
3. Examining alternatives mechanisms for MVPN functions
3.1. MVPN auto-discovery
Section 5.2.10 of [RFC4834] states "The operation of a multicast VPN
solution SHALL be as light as possible and providing automatic
configuration and discovery SHOULD be a priority when designing a
multicast VPN solution. Particularly the operational burden of
setting up multicast on a PE or for a VR/VRF SHOULD be as low as
possible".
The current solution document [I-D.ietf-l3vpn-2547bis-mcast]
addresses this requirement by proposing two different mechanisms for
Morin, et al. Expires April 11, 2008 [Page 4]
Internet-Draft Multicast VPN Considerations October 2007
MVPN auto-discovery:
1. BGP-based auto-discovery (described in section 4).
2. Discovery using PIM running on a MI-PMSI implemented with a
shared tree using multicast ASM, or MP2MP LDP with the same
common tree identifier configured in all VRFs of an MVPN.
It is the recommendation of the authors that BGP-based auto-discovery
is the preferred solution for auto-discovery and should be supported
by all implementations while PIM/shared-tree based auto-discovery
should be optionally considered for migration purpose only.
Part of the rationale for this recommendation is also based on
section 5.2.10 of [RFC4834] which states "as far as possible, the
design of a solution SHOULD carefully consider the number of
protocols within the core network: if any additional protocols are
introduced compared with the unicast VPN service, the balance between
their advantage and operational burden SHOULD be examined
thoroughly".
BGP is the auto-discovery protocol used in unicast (RFC4364) VPNs and
therefore the use of BGP-based auto-discovery within multicast VPNs
avoids the introduction of an additional auto-discovery protocol that
would require additional OAM processes and tools. Service providers
with deployed unicast (RFC4364) VPNs already have extensive
deployment and operations experience of using BGP as an auto-
discovery protocol including OAM processes and tools. Such processes
and tools will require modifications in order to support multicast
auto-discovery but those modifications are anticipated to be less
than those required to develop new processes and tools for a specific
auto-discovery protocol. Additionally, BGP supports MD5
authentication of its peers for additional security. In contrast,
there are no obvious authentication mechanisms to secure PIM
communications in any known implementation.
Furthermore, PIM based discovery is only applicable to deployments
using a shared tree on an MI-PMSI, whereas BGP-based auto-discovery
does not place any restrictions on the type of multicast trees that
can be used. BGP-based auto-discovery is independent of the type of
P-multicast tree used thus satisfying the requirement in section
5.2.4.1 of [RFC4834] that "a multicast VPN solution SHOULD be
designed so that control and forwarding planes are not
interdependent". Additionally, it is to be noted that a number of
service providers have chosen to use SSM-based trees for the default
MDTs within their current deployments, therefore relying already on
BGP-based auto-discovery.
Morin, et al. Expires April 11, 2008 [Page 5]
Internet-Draft Multicast VPN Considerations October 2007
When shared trees are used, the use of BGP auto-discovery would allow
inconsistencies in the addresses/identifiers used for the shared
trees to be detected (e.g. the same shared tree identifier being used
for different VPNs with distinct BGP route targets). This is
particularly attractive in the context of inter-AS VPNs where the
impact of any misconfiguration could be magnified and where a single
service provider may not operate all the ASs.
The authors note that, in order to support the coexistence of both
protocols (for example during migration scenarios), implementations
could support both alternatives by providing a per-VRF configuration
knob that would allow recognizing new PIM neighbors based on the
reception of PIM hellos on a shared P-multicast tree, even for
neighbors that did not advertise a BGP auto-discovery route.
3.2. S-PMSI Signaling
The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes
two mechanisms for S-PMSI Signaling:
1. A new UDP-based TLV protocol specifically for S-PMSI signaling
(described in section 7.2.1).
2. A BGP-based mechanism for S-PMSI signaling (described in section
7.2.2).
It is the recommendation of the authors that BGP is the preferred
solution for S-PMSI signaling and should be supported by all
implementations while the UDP-based S-PMSI signaling protocol should
be considered optional.
Part of the rationale for this recommendation is similar to that for
BGP-based auto-discovery and is based on section 5.2.10 of [RFC4834]
and the desire to avoid introducing and deploying additional
protocols unless strictly necessary.
Furthermore:
o The BGP-based S-PMSI signaling mechanism can be used within MVPNs
using either a UI-PMSI or a MI-PMSI while the UDP-based protocol
is restricted to use within MVPNs using an MI-PMSI.
o The BGP-based S-PMSI signaling mechanism can be efficiently used
in an inter-AS option B deployment context while the use of the
UDP-based protocol does not preserve AS routing independence when
used in an inter-AS option B context (i.e. the decision by a PE in
an AS to use an S-PMSI for a given customer flow will impact
routing state in other ASes). Co-existence with unicast inter-AS
Morin, et al. Expires April 11, 2008 [Page 6]
Internet-Draft Multicast VPN Considerations October 2007
VPN options is strongly encouraged by section 5.2.6 of [RFC4834].
o The BGP-based S-PMSI signaling supports all the functionality and
all the operational contexts that are supported by UDP-based
protocol (and more).
o BGP supports MD5 authentication of its peers for additional
security. In contrast, there are no obvious authentication
mechanisms to secure PIM communications in any known
implementation.
Therefore, it is the opinion of the authors that BGP is the preferred
solution for performing S-PMSI signaling.
However, the authors recognize that the UDP-based protocol has been
in deployment for some time and would recommend that implementations
supporting both protocols optionally provide a per-VRF configuration
knob to allow an implementation to use the UDP-based TLV protocol for
S-PMSI signaling for specific VRFs in order to support the
coexistence of both protocols (for example during migration
scenarios).
Apart from such migration-facilitating mechanisms, the authors
specifically do not recommend extending the already proposed UDP-
based TLV protocol to new types of P-multicast trees.
Section 7.2.2.3 of [I-D.ietf-l3vpn-2547bis-mcast] proposes two
approaches for how a source PE can decide when to start transmitting
customer multicast traffic on a S-PMSI:
1. The source PE sends multicast packets for the <C-S, C-G> on both
the I-PMSI P-multicast tree and the S-PMSI P-multicast tree
simultaneously for a pre-configured period of time, letting the
receiver PEs select the new tree for reception, before switching
to only the S-PMSI.
2. The source PE waits for a pre-configured period of time after
advertising the <C-S, C-G> entry bound to the S-PMSI before fully
switching the traffic onto the S-PMSI-bound P-multicast tree.
The first alternative has essentially two drawbacks:
o <C-S,C-G> traffic is sent twice for some period of time, which
would appear to be at odds with the motivation for switching to an
S-PMSI in order to optimize the bandwidth used by the multicast
tree for that stream.
Morin, et al. Expires April 11, 2008 [Page 7]
Internet-Draft Multicast VPN Considerations October 2007
o It is unlikely that the switchover can occur without packet loss
or duplication if the transit delays of the I-PMSI P-multicast
tree and the S-PMSI P-multicast tree differ.
By contrast, the second alternative has none of these drawbacks, and
satisfy the requirement in section 5.1.3 of [RFC4834], which states
that "[...] a multicast VPN solution SHOULD as much as possible
ensure that client multicast traffic packets are neither lost nor
duplicated, even when changes occur in the way a client multicast
data stream is carried over the provider network". The second
alternative also happen to be the one used in existing deployments.
For these reasons, it is the authors' recommendation to mandate the
implementation of the second alternative for switching to S-PMSI.
3.3. PE-PE Transmission of C-Multicast Routing
The current solution document [I-D.ietf-l3vpn-2547bis-mcast] proposes
multiple mechanisms for PE-PE transmission of customer multicast
routing information:
1. Full per-MVPN PIM peering across an MI-PMSI (described in section
5.2.1).
2. Lightweight PIM peering across an MI-PMSI (described in section
5.2.2)
3. The unicasting of PIM C-Join/Prune messages (described in section
5.2.3)
4. The use of BGP for carrying C-Multicast routing (described in
section 5.3).
The first mechanism (full per-MVPN PIM peering across an MI-PMSI) is
the mechanism used by [I-D.rosen-vpn-mcast] and therefore it is
deployed and operating in MVPNs today. The authors recognize that
because full per-MVPN PIM peering has been in deployment for some
time support for this mechanism may be required for backwards
compatibility and in order to facilitate migration towards
alternative PE-PE protocols.
Section 4.2.4 of [RFC4834] recommends that "a multicast VPN solution
SHOULD support several hundreds of PEs per multicast VPN, and MAY
usefully scale up to thousands" and section 4.2.5 states that "a
solution SHOULD scale up to thousands of PEs having multicast service
enabled".
At those scales of multicast deployment within a large VPN, the first
Morin, et al. Expires April 11, 2008 [Page 8]
Internet-Draft Multicast VPN Considerations October 2007
and third mechanisms require PEs to maintain a large number of PIM
adjacencies with other PEs within the same MVPN and to regularly
exchange PIM hellos with each other and refresh C-Join/Prune state.
The third mechanism would reduce the amount of C-Join/Prune
processing by PEs when they are not the upstream neighbor for a given
multicast flow, but would :
a. require explicit tracking related state to be maintained by PEs
when they are the upstream PE for a said customer flow, and
b. require refresh reduction mechanisms to be used to be applicable.
The second mechanism (lightweight PIM peering across an MI-PMSI)
would operate in a similar manner to full per-MVPN PIM peering except
that PIM hellos are not transmitted and PIM C-Join/Prune refresh
reduction would be used, thereby improving scalability.
The fourth mechanism (the use of BGP for carrying C-Multicast
routing) has to solve roughly the same intrinsic scalability related
difficulties as the other three mechanisms, but because it is based
on TCP it has no refresh-related scalability limit, and inherits some
BGP features that are expected to improve scalability through, for
instance, providing a means to offload some of the processing burden
associated with client multicast routing onto BGP route reflectors.
Furthermore, co-existence with unicast inter-AS VPN options, and an
equal level of security for multicast and unicast including in an
inter-AS context, are specifically mentioned in sections 5.2.6, 5.2.8
and 5.2.12 of [RFC4834]. The first three mechanisms impose direct PE
to PE communications which means that they do not apply well to an
inter-AS option B context, because of security and robustness issues
that are involved by such a level of reachability and interaction
between PEs in different ASes. Their use in an inter-AS context is
possible, but not without limitations or additional engineering
design trade-offs depending upon the interconnect types. By
comparison, the fourth option (the use of BGP for carrying
C-Multicast routing) does not have any of the above limitations
related to inter-AS deployments, and also provides an additional
alternative to facilitate such deployments through the possibility of
using segmented inter-AS trees.
Moreover, mechanisms one and two are restricted to use within MVPNs
using an MI-PMSI, thereby necessitating:
a. The use of a P-multicast tree technique that allows shared trees
(for example PIM-SM in ASM mode or MP2MP LDP).
Morin, et al. Expires April 11, 2008 [Page 9]
Internet-Draft Multicast VPN Considerations October 2007
b. The use of one P-multicast tree per PE per VPN, even for PEs that
do not have sources in their directly attached sites for that
VPN.
By comparison, the fourth mechanism doesn't impose either of these
restrictions.
Additionally, the fourth mechanism (the use of BGP for carrying
C-Multicast routing) would appear to fit well with the current
unicast architecture as BGP is the customer routing distribution
protocol used in unicast VPNs and therefore using BGP for customer
routing distribution within multicast VPNs avoids the introduction of
an additional protocol that would require additional OAM processes
and tools. Service provider's with deployed unicast (RFC4364) VPNs
already have extensive deployment and operations experience of using
BGP as a customer routing distribution protocol including OAM
processes and tools. Such processes and tools will require
modification in order to support customer multicast routing but those
modifications are anticipated to be less than those required to
develop new processes and tools for a distinct customer routing
protocol. It should be noted that because PIM will be used as the
CE-PE customer routing distribution protocol, service providers will
still need OAM processes and tools in order to manage the PIM
protocol, so this rationale only applies to a subset of the tools and
processes already in place. Additionally, BGP supports MD5
authentication of its peers for additional security. In contrast,
there are no obvious authentication mechanisms to secure PIM
communications in any known implementation.
An illustrative example of the benefit brought by consistency with
unicast design is how the "extranet" feature can be implemented :
when BGP-based mechanisms are used, the well defined and well
understood BGP route target import/export semantics are just reused.
By contrast, it is not specified how implementing the same feature
would be done in the context of other alternative mechanism, and
unclear if this is possible without significant engineering trade-
offs. Note that the support for such a feature is stated as a MUST
in sections 5.1.6 of [RFC4834].
Section 5.2.10 of [RFC4834] states that "as far as possible, the
design of a solution SHOULD carefully consider the number of
protocols within the core network: if any additional protocols are
introduced compared with the unicast VPN service, the balance between
their advantage and operational burden SHOULD be examined
thoroughly". Considering that the recommendation of the authors
would be BGP for auto-discovery and S-PMSI signalling, the choice of
BGP for customer multicast routing would be consistent with the
protocol choice for unicast VPNs and would adequately address this
Morin, et al. Expires April 11, 2008 [Page 10]
Internet-Draft Multicast VPN Considerations October 2007
requirement.
BGP-based customer multicast routing clearly presents some advantages
over the PIM-based alternatives. However it has yet to be deployed
within an operational MVPN, and service providers currently lack
experience of its implementation. By contrast, experience proves
that PIM-based mechanisms are operationally viable, but with well
identified limitations. Some of those limitations may be improved
upon (although there is currently no clearly defined proposal to do
this), however some of the limitations appear to be intrinsic to the
approach.
Moreover to improve the clarity of the proposed specifications,
considering that neither hello suppression nor refresh reduction
procedures are currently specified or documented and that it is not
clear what the impact to the PIM state machine of these additional
procedures may be, the authors recommend that the proposals for
lightweight PIM peering across an MI-PMSI (the second mechanism) and
for the unicasting of PIM C-Join/Prune messages (the third mechanism)
be removed from the current solution document
[I-D.ietf-l3vpn-2547bis-mcast] until the additional PIM hello and
refresh reduction procedures have been well specified and both their
impact and benefit on an MPVN deployment is understood.
Consequently, at the present time and until there is experience with
all of the proposed mechanisms it is not clear which of the above
mechanisms should be recommended as the preferred solution to
implementers. However, it would appear prudent for implementations
to consider supporting both the fourth (BGP-based) and first (full
per-MPVN PIM peering) mechanisms. Further experience on both
implementation is likely to be required before some best practice can
be defined.
3.4. Encapsulation techniques for P-multicast trees
In this section the authors will not make any restricting
recommendations as the appropriateness of a specific core (P) data
plane technology will depend on a large number of factors, for
example the service provider's currently deployed unicast data plane,
many of which are service provider specific.
However, implementations should not unreasonably restrict the data
plane technology that can be used, and should not force the use of
the same technology for different VPNs attached to a single PE.
Initial implementations may only support a reduced set of
encapsulation techniques and data plane technologies but this should
not be considered a limiting factor that hinders future support for
other encapsulation techniques, data plane technologies or
Morin, et al. Expires April 11, 2008 [Page 11]
Internet-Draft Multicast VPN Considerations October 2007
interoperability.
Section 5.2.4.1 of [RFC4834] states "In a multicast VPN solution
extending a unicast L3 PPVPN solution, consistency in the tunneling
technology has to be favored: such a solution SHOULD allow the use of
the same tunneling technology for multicast as for unicast.
Deployment consistency, ease of operation and potential migrations
are the main motivations behind this requirement."
Current unicast VPN deployments use a variety of LDP, RSVP-TE and
GRE/IP for encapsulating customer packets for transport across the
provider core of VPN services. It is recommended that
implementations support the three corresponding multicast tree
encapsulations techniques, namely: mLDP, P2MP RSVP-TE and GRE/IP
multicast in order to allow the same encapsulations to be used for
unicast and multicast traffic as well as facilitating migration from
[I-D.rosen-vpn-mcast] to an MPLS label based encapsulation.
3.5. Inter-AS deployments options
There are a number of scenarios that lead to the requirement for
inter-AS multicast VPNs, including:
1. A service provider may have a large network that they have
segmented into a number of ASs.
2. A service provider's multicast VPN may consist of a number of ASs
due to aquisitions and mergers with other service providers.
3. A service provider may wish to interconnect their multicast VPN
platform with that of another service provider.
The first scenario can be considered the "simplest" because the
network is wholly managed by a single service provider under a single
strategy and is therefore likely to use a consistent set of
technologies across each AS.
The second scenario may be more complex than the first because the
strategy and technology choices made for each AS may have been
different due to their differing history and the service provider may
not have (or may be unwilling to) unified the strategy and technology
choices for each AS.
The third scenario is the most complex because in addition to the
complexity of the second scenario, the ASs are managed by different
service providers and therefore may be subject to a different trust
model than the other scenarios.
Morin, et al. Expires April 11, 2008 [Page 12]
Internet-Draft Multicast VPN Considerations October 2007
Section 5.2.6 of [RFC4834] states "A solution MUST support inter-AS
multicast VPNs, and SHOULD support inter-provider multicast VPNs.
Considerations about coexistence with unicast inter-AS VPN Options A,
B and C (as described in section 10 of [RFC4364]) are strongly
encouraged." and "A multicast VPN solution SHOULD provide inter-AS
mechanisms requiring the least possible coordination between
providers, and keep the need for detailed knowledge of providers'
networks to a minimum - all this being in comparison with
corresponding unicast VPN options."
Section 8 of [I-D.ietf-l3vpn-2547bis-mcast] addresses these
requirements by proposing two approaches for mVPN inter-AS
deployments:
1. Segmented inter-AS tunnels where each AS constructs its own
separate multicast tunnels which are then 'stitched' together by
the ASBRs (described in section 8.2).
2. Non-segmented inter-AS tunnels where the multicast tunnels are
end-to-end across ASes, so even though the PEs belonging to a
given MVPN may be in different ASs the ASBRs play no special role
and function merely as P routers (described in section 8.1).
Section 5.2.6 of [RFC4834] also states "Within each service provider
the service provider SHOULD be able on its own to pick the most
appropriate tunneling mechanism to carry (multicast) traffic among
PEs (just like what is done today for unicast)". Segmented inter-AS
tunnels is the only solution that is capable of meeting this
requirement.
The segmented inter-AS solution would appear to offer the largest
degree of deployment flexibility to operators, however the non-
segmented inter-AS solution can simplify deployment in a restricted
number of scenarios and [I-D.rosen-vpn-mcast] only supports the non-
segmented inter-AS solution and therefore the non-segmented inter-AS
solution is likely to be required by some operators for backward
compatibility and during migration from [I-D.rosen-vpn-mcast] to
[I-D.ietf-l3vpn-2547bis-mcast].
The applicability of segmented or non-segmented inter-AS tunnels to a
given deployment or inter-provider interconnect will depend on a
number of factors specific to each service provider. However, due to
the additional deployment flexibility offered by segmented inter-AS
tunnels, it is the recommendation of the authors that all
implementations should support the segmented inter-AS model.
Additionally, the authors recommend that implementations should
consider supporting the non-segmented inter-AS model in order to
facilitate co-existence with existing deployments, and as a feature
Morin, et al. Expires April 11, 2008 [Page 13]
Internet-Draft Multicast VPN Considerations October 2007
to provide a lighter engineering in a restricted set of scenarios,
although it is recognised that initial implementations may only
support one or the other.
Additionally, the authors note that the proposed BGP-based approaches
for S-PMSI signaling and C-multicast routing information distribution
provide a good fit with both segmented and non-segmented inter-AS
tunnels. In contrast the UDP-TLV based approach for S-PMSI signaling
appears to be incompatible with segmented inter-AS tunnels, and it is
unclear if the proposed PIM-based approaches for C-multicast routing
information distribution would be fully applicable to segmented
inter-AS tunnels.
4. Co-located RPs
Section 5.1.10.1 of [RFC4834] states "In the case of PIM-SM in ASM
mode, engineering of the RP function requires the deployment of
specific protocols and associated configurations. A service provider
may offer to manage customers' multicast protocol operation on their
behalf. This implies that it is necessary to consider cases where a
customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN
solution MAY support the hosting of the RP function in a VR or VRF."
Co-locating a customer's RP on a PE can provide some benefits to the
customer as outlined in section 5.1.10.3 of [RFC4834] which states
"In the case of PIM-SM, when a source starts to emit traffic toward a
group (in ASM mode), if sources and receivers are located in VPN
sites that are different than that of the RP, then traffic may
transiently flow twice through the SP network and the CE-PE link of
the RP (from source to RP, and then from RP to receivers). This
traffic peak, even short, may not be convenient depending on the
traffic and link bandwidth.
However, customers who have already deployed multicast within their
networks and have therefore already deployed their own internal RPs
are often reluctant to hand over the control of their RPs to their
service provider and make use of a co-located RP model.
Also, providing colocating the RP on PE will require the activation
of MSDP or the processing of PIM Registers on the PE. Securing the
PE routers for such acitivity requires special care, additional work,
and will likely rely on specific features to be provided by the
routers themselves.
The applicability of the co-located RP model to a given MVPN will
thus depend on a number of factors specific to each customer and
service provider. It is therefore the recommendation of the authors
Morin, et al. Expires April 11, 2008 [Page 14]
Internet-Draft Multicast VPN Considerations October 2007
that implementations should support a co-located RP model, but that
support for a co-located RP model within an implementation should not
restrict deployments to using a co-located RP model, and
implementations should also support deployments when no RP is co-
located on a PE router and where all RPs are deployed within the
customers' networks.
5. Existing deployments
Some suggestions provided in this document can be used to
incrementally modify currently deployed implementations without
hindering these deployments, and without hindering the consistency of
the standardized solution by providing optional per-VRF configuration
knobs to support modes of operation compatible with currently
deployed implementations, while at the same time using the
recommended approach on implementations supporting the standard.
In cases where this may not be easily achieved, a recommended
approach would be to provide a per-VRF configuration knob that allows
incremental per-VPN migration of the mechanisms used by a PE device,
which would allow migration with some per-VPN interruption of service
(e.g. during a maintenance window).
Mechanisms allowing "live" migration by providing concurrent use of
multiple alternatives for a given PE and a given VPN, is not seen as
a priority considering the expected implementation complexity
associated with such mechanisms. However, if there happen to be
cases where they could be viably implemented relatively simply, such
mechanisms may help improve migration management.
6. Summary of recommendations
The following list summarizes the authors' recommendations. These
recommendations are not intended to prevent the implementation of
alternative solutions, rather they are the authors' recommendations
for the mechanisms that should be made mandatory in
[I-D.ietf-l3vpn-2547bis-mcast] and therefore be supported by all
implementations.
It is the authors' recommendation:
o that BGP-based auto-discovery be the mandated solution for auto-
discovery;
o that BGP be the mandated solution for S-PMSI signaling;
Morin, et al. Expires April 11, 2008 [Page 15]
Internet-Draft Multicast VPN Considerations October 2007
o that the mandated solution for S-PMSI switch-over be the mechanism
based on the source-connected PE switching traffic from the I-PMSI
tunnel to the S-PMSI tunnel, without transmitting traffic on both
at the time;
o that implementations support both the BGP-based and the full per-
MPVN PIM peering solutions for PE-PE transmission of customer
multicast routing until further operational experience is gained
with both solutions;
o that implementations support the following multicast tree
encapsulations: mLDP, P2MP RSVP-TE and GRE/IP;
o that implementations support segmented inter-AS tunnels and
consider supporting non-segmented inter-AS tunnels[[in order to
maintain backwards compatibility and for migration]].
o that implementations support a co-located RP model, but that
implementations should not restrict deployments to having to use a
co-located RP model.
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
8. Security Considerations
This document does not by itself raise any particular security
considerations.
9. Acknowledgements
[To be completed]
10. Informative References
[I-D.ietf-l3vpn-2547bis-mcast]
Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", draft-ietf-l3vpn-2547bis-mcast-03 (work in
progress), October 2006.
Morin, et al. Expires April 11, 2008 [Page 16]
Internet-Draft Multicast VPN Considerations October 2007
[I-D.raggarwa-l3vpn-2547-mvpn]
Aggarwal, R., "Base Specification for Multicast in BGP/
MPLS VPNs", draft-raggarwa-l3vpn-2547-mvpn-00 (work in
progress), June 2004.
[I-D.rosen-vpn-mcast]
Rosen, E., "Multicast in MPLS/BGP VPNs",
draft-rosen-vpn-mcast-08 (work in progress),
December 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4834] Morin, T., "Requirements for Multicast in L3 Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4834,
April 2007.
Authors' Addresses
Thomas Morin (editor)
France Telecom R&D
2 rue Pierre Marzin
Lannion 22307
France
Email: thomas.morin@orange-ftgroup.com
Ben Niven-Jenkins (editor)
BT
208 Callisto House, Adastral Park
Ipswich, Suffolk IP5 3RE
UK
Email: benjamin.niven-jenkins@bt.com
Yuji Kamite
NTT Communications Corporation
Tokyo Opera City Tower
3-20-2 Nishi Shinjuku, Shinjuku-ku
Tokyo 163-1421
Japan
Email: y.kamite@ntt.com
Morin, et al. Expires April 11, 2008 [Page 17]
Internet-Draft Multicast VPN Considerations October 2007
Raymond Zhang
BT
2160 E. Grand Ave.
El Segundo CA 90025
USA
Email: raymond.zhang@bt.com
Nicolai Leymann
Deutsche Telekom
Goslarer Ufer 35
10589 Berlin
Germany
Email: nicolai.leymann@t-systems.com
Morin, et al. Expires April 11, 2008 [Page 18]
Internet-Draft Multicast VPN Considerations October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Morin, et al. Expires April 11, 2008 [Page 19]