Signaling Tunnel Encapsulation/Deencapsulation Capabilities
draft-raggarwa-ppvpn-tunnel-encap-sig-03
Document | Type |
Expired Internet-Draft
(individual in sub area)
Expired & archived
|
|
---|---|---|---|
Author | Rahul Aggarwal | ||
Last updated | 2015-10-14 (Latest revision 2004-02-11) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Expired (IESG: Dead) | |
Action Holders |
(None)
|
||
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Alex D. Zinin | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document proposes a mechanism for signaling a PE router's tunnel encapsulation capabilities. One example is its capability to encapsulate MPLS using dynamic GRE and/or IP. This is applicable when a MPLS packet is tunneled using dynamic GRE and/or IP encapsulation [MPLS-IP-GRE] between PE routers. For instance the MPLS packet may be a 2547 based MPLS VPN packet [2547bis], a layer 2 packet transported using MPLS [MARTINI], a MPLS tunneled IPv6 packet or a MPLS IPv6 VPN packet [BGP-VPN-IPv6]. Adding such a mechanism has several benefits. It helps in blackhole avoidance and eases transitioning from MPLS tunneling based Layer 3/Layer 2 VPNs to GRE/IP tunneling based Layer 3/Layer 2 VPNs (and vice versa). Such a mechanism is needed where a network may be using MPLS and GRE (or IP) for tunneling, simultaneously in different parts of the network. It can help in encapsulation selection when multiple tunneling technologies are supported.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)