INTERNET DRAFT Jeremy De Clercq
<draft-ietf-l3vpn-bgp-ipv6-vpn-00.txt> Dirk Ooms
Gerard Gastaud
Alcatel
Marco Carugi
Nortel Networks
Francois Le Faucheur
Cisco Systems
November 2002
Expires May, 2003
BGP-MPLS VPN extension for IPv6 VPN
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document describes a method by which a Service Provider may use
its packet switched backbone to provide Virtual Private Network
services for its IPv6 customers. This method extends the "BGP/MPLS
VPN" method [2547bis] for support of IPv6. In BGP/MPLS VPN,
"Multiprotocol BGP" is used for distributing IPv4 VPN routes over the
service provider backbone and MPLS is used to forward IPv4 VPN
packets over the backbone. This document defines an IPv6 VPN address
family and describes the corresponding route distribution in
"Multiprotocol BGP". This document defines support of the IPv6 VPN
De Clercq, et al. Expires May 2003 [Page 1]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
srvice over both an IPv4 and an IPv6 backbone, and using various
tunnelling techniques over the core including MPLS, IPsec, IP-in-IP
and GRE.
1. Introduction
This document adopts the definitions, acronyms and mechanisms
described in [2547bis]. Unless otherwise stated, the mechanisms of
[2547bis] apply and will not be re-described here.
A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6
capable and is natively connected over an IPv6 interface or sub-
interface to the SP backbone via a Provider Edge device (PE).
A site may be both IPv4- and IPv6-capable. The logical interface on
which packets arrive at the PE may determine the version, but
alternatively a per-packet header lookup may determine the version.
This document only concerns itself with handling of the IPv6 packets.
In a similar manner to how IPv4 VPN routes are distributed in
[2547bis], BGP and its extensions are used to distribute routes from
an IPv6 VPN site to all the other PE routers connected to a site of
the same IPv6 VPN. PEs use VRFs to separately maintain the
reachability information and forwarding information of each IPv6 VPN.
As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have
its own IPv6 address space, which means that a given address may
denote different systems in different VPNs (as may be required when
site-local addresses are used by the end customers). This is achieved
via a new address family, the VPN-IPv6 Address Family, in a fashion
similar to the VPN-IPv4 address family definition given by [2547bis].
In addition to operation over MPLS Label Switched Paths (LSPs), the
MPLS/BGP VPN solution is extended to allow operation over other
tunnelling techniques including GRE tunnels, IP-in-IP tunnels [2547-
GRE/IP] and IPsec tunnels [2547-IPsec]. In a similar manner, this
document allows support of an IPv6 VPN service over MPLS LSPs as well
as over other tunnelling techniques including GRE tunnels, IP-in-IP
tunnels and IPsec tunnels. Similar BGP-based negotiation and
discovery [TUNNEL-ATTR] mechanisms are proposed to dynamically
determine which tunnelling technique is to be used in a given
network.
This document allows support for an IPv6 VPN service over an IPv4
backbone as well as over an IPv6 backbone. The IPv6 VPN service
supported is identical in both cases.
The IPv6 VPN solution defined in this document offers the following
De Clercq, et al. Expires May 2003 [Page 2]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
benefits:
o from both the Service Provider perspective and the customer
perspective, the VPN service that can be supported for IPv6 sites
is identical to the one that can be supported for IPv4 sites;
o from the Service Provider perspective, operations of the IPv6
VPN service require the exact same skills, procedures and
mechanisms as for the IPv4 VPN service;
o where both IPv4 VPNs and IPv6 VPN services are suppported over
an IPv4 core, the same single set of MP-BGP peering relationships
and the same single PE-PE tunnel mesh can be used for both;
o independence of whether the core runs IPv4 or IPv6. So that the
IPv6 VPN service suppported before, and after a migration of the
core from IPv4 to IPv6 is undistinguishable to the VPN customer.
2. The VPN Address Family
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
from multiple "address families". We introduce the notion of the
"VPN-IPv6 address family", that is similar to the VPN-IPv4 address
family introduced in [2547bis].
2.1 The VPN-IPv6 Address Family
A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte
"Route Distinguisher" (RD) and ending with a 16-byte IPv6 address.
If two VPNs use the same IPv6 address prefix (effectively denoting
different physical systems), the PEs translate these into unique
VPN-IPv6 address prefixes using different RDs. This ensures that if
the same address is used in two different VPNs, it is possible to
install two completely different routes to that address, one for each
VPN.
The purpose of the RD is solely to allow one to create distinct
routes to a common IPv6 address prefix, similarly to the purpose of
the RD defined in [2547bis]. As it is possible per [2547bis], the RD
can also be used to create multiple different routes to the very same
system. This can be achieved by creating two different VPN-IPv6
routes that have the same IPv6 part, but different RDs. This allows
BGP to install multiple different routes to the same system, and
allows policy to be used to decide which packets use which route.
Note that VPN-IPv6 addresses and IPv6 addresses are always considered
by BGP to be incomparable.
De Clercq, et al. Expires May 2003 [Page 3]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6
address prefix. When a packet's destination address is matched
against a VPN-IPv6 route, only the IPv6 part is actually matched.
When a site is IPv4- and IPv6-capable, the same RD can be used for
the advertisement of IPv6 addresses and IPv4 addresses.
2.2. Encoding of Route Distinguishers
The RDs are encoded as per [2547bis]:
- TYPE field: 2 bytes
- VALUE field: 6 bytes
The interpretation of the VALUE field depends on the value of the
TYPE field. As it is the case in [2547bis], 3 encodings can be used:
- TYPE field = 0 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 2 bytes, it contains an Autonomous
System Number
* Assigned Number subfield: 4 bytes
- TYPE field = 1 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 4 bytes, it contains a global IPv4
address
* Assigned Number subfield: 2 bytes
- TYPE field = 2 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 4 bytes, it contains a 4-byte Autonomous
System Number
* Assigned Number subfield: 2 bytes
3. VPN-IPv6 route distribution
3.1. Route Distribution Among PEs by BGP
As described in [2547bis], if two sites of a VPN attach to PEs which
are in the same Autonomous System, the PEs can distribute VPN routes
to each other by means of an (IPv4) IBGP connection between them.
Alternatively, each can have an IBGP connection to a route reflector.
Similarly, for IPv6 VPN route distribution, PEs can use an iBGP
De Clercq, et al. Expires May 2003 [Page 4]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
connection between them or use iBGP connections to a route reflector.
The PE routers:
(i) exchange, via MP-BGP [MP-BGP], reachability information for the
IPv6 prefixes in the IPv6 VPNs.
(ii) announce themselves as the BGP Next Hop.
3.2 VPN IPv6 NLRI encoding
The advertising PE router MUST also assign and distribute MPLS labels
with the IPv6 VPN routes. Essentially, PE routers do not distribute
IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the
advertising PE receives a packet that has this particular advertised
label, the PE will pop the MPLS stack, and process the packet
appropriately (i.e. forward it directly based on the label or perform
a lookup in the corresponing IPv6-VPN context).
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows:
- AFI: 2; for IPv6
- SAFI: 128; for MPLS labeled VPN-IPv6
The labeled VPN-IPv6 MP_REACH_NLRI itself is encoded as specified in
[MPLS-BGP]. In the context of this extension, the prefix belongs to
the VPN-IPv6 Address Family and thus consists of an 8-byte Route
Distinguisher followed by an IPv6 prefix as specified in section 2
above.
3.2.1 BGP Next Hop encoding
MP-BGP has the constraint that the "BGP Next Hop" field in the
MP_REACH_NLRI attribute needs to be of the same address family as the
NLRI encoded in the MP_REACH_NLRI attribute. In this document, this
means that the BGP Next Hop field must belong to the VPN-IPv6 Address
Family.
3.2.1.1 IPv6 backbone
When an IPv6 VPN service is offered as per this document over an IPv6
backbone, the BGP Next Hop MUST contain a VPN-IPV6 address:
- whose RD is set to zero, and
- whose 16-byte IPv6 address is set to the IPv6 address of the
De Clercq, et al. Expires May 2003 [Page 5]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
advertising PE. This IPv6 address must be routable in the Service
Provider's backbone.
This is the same approach as used in [2547bis] where the PE encodes
its IPv4 address in a VPN-IPv4 Address Family format.
3.2.1.2 IPv4 backbone
When an IPv6 VPN service is offered as per this document over an IPv4
backbone, the BGP Next Hop MUST contain a VPN-IPV6 address:
- whose RD is set to zero, and
- whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6
address [V6ADDR] containing the IPv4 address of the advertising
PE. This IPv4 address must be routable in the Service Provider's
backbone.
3.3. Route Target
The use of route target is specified in [2547bis] and applies to IPv6
VPNs. Encoding of the extended community attribute is defined in
[BGP-EXTCOM].
3.4 BGP Capability Negotiation
In order for two PEs to exchange labelled IPv6 VPN NLRIs, they must
use BGP Capabilities Negotiation to ensure that they both are capable
of properly processing such NLRI. This is done as specified in
[BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
BGP), with AFI and SAFI fields according to above.
4. Automatic Determination of Tunnel Type
As mentioned earlier, this document allows support of IPv6 VPN
service using various tunneling techniques in the core.
The tunneling type to use in the core for IPv6 VPN may be determined
via configuration of PEs.
There is work underway [TUNNEL-ATTR] on a new BGP attribute (Tunnel
Type) and associated procedures so that BGP speakers can
automatically determine which tunneling type to use for a given
Prefix and a given BGP next hop.
This document defines MPLS as the default tunneling type. This means
that when no Tunnel Type attribute is included in a BGP advertisement
for a labeled VPN-IPv6 Prefix and when the tunnel type to be used is
De Clercq, et al. Expires May 2003 [Page 6]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
not specified by the PE configuration, MPLS LSPs MUST be used to
tunnel IPv6 VPN packets to the BGP Next Hop over the Service Provider
backbone.
Where another tunneling technique than MPLS is desired for tunneling
traffic to an IPv6 VPN prefix between PEs, the Tunnel Type attribute
MAY be used in BGP advertisement of a labeled VPN-IPv6 Prefix, as
specified in [TUNNEL-ATTR].
5. Encapsulation
The ingress PE Router MUST tunnel IPv6 VPN data over the backbone
towards the Egress PE router identified as the BGP Next Hop for the
corresponding IPv6 VPN prefix.
When the 16-byte IPv6 address contained in the BGP Next Hop field is
encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the
ingress PE will use IPv4 tunnelling.
When the 16-byte IPv6 address contained in the BGP Next Hop field is
not encoded as an IPv4-mapped address (see section 3.2.1.2), the
ingress PE will use IPv6 tunnelling.
Regardless of whether it is IPv4 or IPv6 tunnelling, the tunnelling
type is determined as discussed above in section 4.
When a PE receives a packet from a CE, it looks up the packet's IPv6
destination address in the VRF corresponding to that CE. This enables
it to find a VPN-IPv6 route. The VPN-IPv6 route will have an
associated MPLS label and an associated BGP Next Hop. First, this
MPLS label is pushed on the packet. Then, this labelled packet is
encapsulated into the tunnel for transport to the egress PE. Details
of this encapsulation depend on the actual tunnelling technique as
follows:
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunnelling is done
using IP-in-IP IPv4 tunnels or IP-in-IP IPv6 tunnels (resp. IPv4 GRE
tunnels or IPv6 GRE tunnels), encapsulation of the labelled IPv6 VPN
packet results in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated
packet as specified in [MPLS-in-IP] (resp. [MPLS-in-GRE]).
As with MPLS/BGP for IPv4 VPNs [2547-IPsec], when tunnelling is done
using an IPsec secured tunnel, encapsulation of the labelled IP6 VPN
packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated packet
[MPLS-in-IP], [MPLS-in-GRE]. The IPsec Transport Mode is used to
secure this IPv4 or GRE tunnel from ingress PE to egress PE.
When tunnelling is done using IP-in-IP IPv4 tunnels or IPv4 GRE
De Clercq, et al. Expires May 2003 [Page 7]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
tunnels (whether IPsec secured or not), the Ingress PE Router MUST
use the IPv4 address which is encoded in the IPv4-mapped IPv6 address
field of the BGP next hop field, as the destination address of the
prepended IPv4 tunnelling header. It uses one of its IPv4 addresses
as the source address of the prepended IPv4 tunneling header.
When tunnelling is done using IP-in-IP IPv6 tunnels or IPv6 GRE
tunnels tunnels (whether IPsec secured or not), the Ingress PE Router
MUST simply use the IPv6 address which is contained in the IPv6
address field of the BGP next hop field, as the destination address
of the prepended IPv6 tunnelling header. It uses one of its IPv6
addresses as the source address of the prepended IPv6 tunneling
header.
When tunneling is done using MPLS LSPs, the LSPs can be established
using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE],
...). Nevertheless, to ensure interoperability among systems that
implement this VPN architecture using MPLS LSPs as the tunneling
technology, all such systems must support LDP [LDP].
When tunnelling is done using MPLS LSPs, the ingress PE Router
directly pushes the LSP tunnel label on the label stack of the
labelled IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6
header). The topmost label imposed corresponds to the LSP starting on
the ingress PE Router and ending on the egress PE Router. The BGP
Next Hop field is used to identify the egress PE router and as such
the topmost label to be pushed on the stack. The bottom label is the
label bound to the IPv6 VPN Prefix via BGP.
6. Address Scope
The IPv6 address architecture [ADDRARCH] defines the concept of scope
for IPv6 addresses and defines the following unicast address scopes:
- link-local,
- site-local,
- global
Since Link-local scope addresses are defined as uniquely identifying
interfaces within (i.e., attached to) a single link only, those may
be used on the PE-CE link but they are not supported for reachability
across IPv6 VPN Sites and are never advertised via MP-BGP to remote
PEs.
Global scope addresses are defined as uniquely identifying interfaces
anywhere in the Internet. Global addresses are expected to be
De Clercq, et al. Expires May 2003 [Page 8]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
commonly used within and across IPv6 VPN Sites. They are obviously
supported by this IPv6 VPN solution for reachability across IPv6 VPN
Sites and advertised via MP-BGP to remote PEs and processed without
any specific considerations to their Global scope.
Site-local scope addresses are defined as uniquely identifying
interfaces within a single site only. Quoting from [SCOPE-ARCH], ''a
"site" is, by intent, not rigorously defined,...''. However, it is
anticipated by the authors of this document that, when used in an
IPv6 VPN network, the concept of Site Local scope will typically be
used in either of the following scenarios:
- all IPv6 VPN sites of a given VPN are within the same Site-Local
zone. Thus, Site-Local addresses may be used for reachability
across all IPv6 VPN sites and corresponding Site-Local routes may
be advertised via MP-BGP to remote PEs and installed in VRFs. In
this scenario, Site Local routes MUST effectively be treated by
the PE in exactly the same way as Global routes.
- Each IPv6 VPN site of a given VPN is in a different Site-Local
zone. Site-Local addresses can not be used for reachability across
IPv6 VPN sites and corresponding Site-Local routes should not be
advertised via MP-BGP to remote PEs. This IPv6 VPN solution
proposes that this scenario be supported simply by effectively
hiding the Site Local routes to the PE. This can be seen as
placing the Site-Local zone boundary on the CE (as opposed to on
the PE) and thus locating the PE outside the Site-Local zone.
Then, when dynamic IPv6 routing is used between the PE and CE (v6
IGP, MP-BGP), the CE will not distribute Site-Local routes to the
PE. Thus, no special handling of Site Local routes is required on
the PE since there are none.
The following is an example of the first scenario:
I VPN I VPN I Site-Local I Site-Local addresses within I
I I Site I Zone I I
=================================================================
I Yellow I 1 I 1 I FEC0::CAFE1/64 I
I Yellow I 2 I 1 I FEC0::CAFE2/64 I
I Yellow I 3 I 1 I FEC0::CAFE3/64 I
The following is an example of the second scenario:
De Clercq, et al. Expires May 2003 [Page 9]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
I VPN I VPN I Site-Local I Site-Local addresses within I
I I Site I Zone I I
=================================================================
I Green I 1 I 1 I FEC0::BEEF1/64 I
I Green I 2 I 2 I FEC0::BEEF2/64 I
I Green I 3 I 3 I FEC0::BEEF3/64 I
Note that these two scenarios can be supported by the IPv6 VPN
solution without any additional PE mechanism specific to the concept
of Site-Local scope, since in the first scenario Site-Local routes
are treated by the PEs in exactly the same way as Global routes, and
in the second scenario Site Local routes are hidden to the PEs.
Additional scenarios for the use of Site-Local scope in the context
of IPv6 VPNs are conceivable. For example, a scenario could involve a
given VPN which comprises a first set of VPN Sites which are within
the same Site-Local zone and a second set of VPN Sites which are
within another Site-Local zone. In that case, Site-Local addresses
may be used to support reachability across VPN sites of the same
Site-Local zone, but not across VPN Sites of different Site-Local
zones. Such scenarios would require that Global routes be advertised
and installed in the VRFs of all the VPN sites but that Site-Local
routes only be installed in the VRFs of a subset of the VPN sites.
Thus, such scenarios may require additional PE mechanisms specific to
the concept of Site Local scope (such as perhaps automatically using
a different Route Targets for Site Local routes and Global routes).
Because it is unclear at this point in time that there is a practical
requirement for handling such scenarios, support for these scenarios,
and corresponding mechanisms, are left for further study.
7. Multicast
Multicast operations is outside the scope of this document.
8. Inter-Provider Backbones
The same mechanisms described in [2547bis] can be used and have the
same scalability properties.
9. Accessing the Internet from a VPN
The methods proposed by [2547bis] to access the global Internet can
be used in the context of IPv6 VPNs and the global IPv6 Internet.
Note however that if the IPv6 packets destined for the global IPv6
Internet need to traverse the SP's backbone, and if this is an IPv4
only backbone, they must be tunnelled through that IPv4 backbone.
10. Management VPN
De Clercq, et al. Expires May 2003 [Page 10]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
Where the IPv6 VPN service is supported over an IPv4 backbone, and
where the Service Provider manages the CE, the Service Provider may
elect to use IPv4 for communication between the management tool and
the CE for such management purposes. In that case, regardless of
whether a customer IPv4 site is actually connected to the CE or not,
the CE is effectively part of an IPv4 VPN (i.e. it is attached to an
IPv4 VRF) in addition to belonging to an IPv6 VPN. Considerations
presented in [2547bis] on how to ensure that the management tool can
communicate with such managed CEs from multiple VPNs without allowing
undesired reachability across CEs of different VPNs, are applicable
to the IPv4 VRF to which the CE attaches.
Where the IPv6 VPN service is supported over an IPv4 backbone, and
where the Service Provider manages the CE, the Service Provider may
elect to use IPv6 for communication between the management tool and
the CE for such management purposes. Considerations presented in
[2547bis] on how to ensure that the management tool can communicate
with such managed CEs from multiple VPNs without allowing undesired
reachability across CEs of different VPNs, are then applicable to the
IPv6 VRF to which the CE attaches.
11. Security
The same security concerns as in [2547bis] are applicable.
12. Quality of Service
[2547bis] is applicable.
13. Acknowledgements
In Memoriam:
The authors would like to acknowledge the valuable contribution to
this document from Tri T. Nguyen, who passed away in April 2002 after
a sudden illness.
14. References
[2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn-
rfc2547bis-03.txt, October 2002, work in progress
[2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547
VPNs", draft-ietf-ppvpn-gre-ip-2547-01.txt, February 2002, work in
progress
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of
De Clercq, et al. Expires May 2003 [Page 11]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt,
August 2002, work in progress
[BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work in
progress
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
for BGP4", June 2000, RFC2858
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002, work in
progress
[IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460.
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", RFC3031
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
RFC3107
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
Conta, "MPLS Label Stack Encoding", RFC3032
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", RFC3036
[TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC2893.
[V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing
Architecture", draft-ietf-ipngwg-addr-arch-v3-10.txt, work in
progress
[SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture",
draft-ietf-ipngwg-scoping-arch-04.txt, work in progress
[TUNNEL-ATTR] Cristallo, G., De Clercq, J., "BGP Tunnel Attribute",
draft-cristallo-bgp-tunnel-attr-00.txt, June 2002, work in progress
[LDP] Andersson, L., et al., "LDP Specification", January 2001,
RFC3036
[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", December 2001, RFC3209
De Clercq, et al. Expires May 2003 [Page 12]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
[MPLS-in-IP] Doolan, P., et al., "MPLS Label Stack Encapsulation in
IP", draft-worster-mpls-in-ip-03.txt, work in progress
[MPLS-in-GRE] Rekhter, Y., Tappan, D., Rosen, E., "MPLS Label Stack
Encapsulation in GRE", draft-rekhter-mpls-over-gre-01.txt, work in
progress
11. Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Gerard Gastaud
Alcatel
10 rue Latecoere, BP 57, 78141 Velizy Cedex, France
E-mail: gerard.gastaud@alcatel.fr
Dirk Ooms
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: dirk.ooms@alcatel.be
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France
E-mail: marco.carugi@nortelnetworks.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
E-mail: flefauch@cisco.com
De Clercq, et al. Expires May 2003 [Page 13]
Internet Draft draft-ietf-ppvpn-bgp-ipv6-vpn November 2002
De Clercq, et al. Expires May 2003 [Page 14]
