Experience with rsvp-te p2mp based mvpn
draft-joseph-p2mp-mvpn-experience-00
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Vinod Joseph | ||
| Last updated | 2009-08-20 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Multicast based VPNs have been deployed for a while now, based on the Draft Rosen solution. In today's scenario, network deployments are moving towards a choice Label Switched Multicast, primarily to garner some of the advantages that a Label Switched Network can offer. In short, the requirement is to achieve more optimal multicast replication and in other words achieve better and effective bandwidth savings. This document describes some of the experiences gained from the implementation and deployment of Label Switched multicast using the RSVP-TE P2MP Label Switched Path approach, and such is information only. The intent is to translate the experiences gained into valuable practices for the Service Provider and Enterprise community who intend to deploy this class of mVPNs. Information based on "Hierarchical Multicast Trees" and "Aggregated P Tunnels" have not been included, and will follow in the next version of this draft.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)