< draft-ietf-l3vpn-ospf-2547-05.txt   draft-ietf-l3vpn-ospf-2547-06.txt >
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Peter Psenak Internet Draft Peter Psenak
Expiration Date: May 2006 Padma Pillay-Esnault Expiration Date: August 2006 Padma Pillay-Esnault
Updates: draft-ietf-l3vpn-ospf-2547-05.txt Cisco Systems, Inc. Updates: RFC4364 Cisco Systems, Inc.
November 2005 February 2006
OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs
draft-ietf-l3vpn-ospf-2547-05.txt draft-ietf-l3vpn-ospf-2547-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 33 skipping to change at page 2, line 33
4.2.3 OSPF Areas ........................................... 10 4.2.3 OSPF Areas ........................................... 10
4.2.4 OSPF Domain Identifiers .............................. 11 4.2.4 OSPF Domain Identifiers .............................. 11
4.2.5 Loop Prevention ...................................... 12 4.2.5 Loop Prevention ...................................... 12
4.2.5.1 The DN Bit ........................................... 12 4.2.5.1 The DN Bit ........................................... 12
4.2.5.2 Use of OSPF Route Tags ............................... 13 4.2.5.2 Use of OSPF Route Tags ............................... 13
4.2.5.3 Other Possible Loops ................................. 14 4.2.5.3 Other Possible Loops ................................. 14
4.2.6 Handling LSAs from the CE ............................ 14 4.2.6 Handling LSAs from the CE ............................ 14
4.2.7 Sham Links ........................................... 17 4.2.7 Sham Links ........................................... 17
4.2.7.1 Intra-Area Routes .................................... 17 4.2.7.1 Intra-Area Routes .................................... 17
4.2.7.2 Creating Sham Links .................................. 18 4.2.7.2 Creating Sham Links .................................. 18
4.2.7.3 OSPF Protocol on Sham Links .......................... 20 4.2.7.3 OSPF Protocol on Sham Links .......................... 18
4.2.7.4 Routing and Forwarding on Sham Links ................. 21 4.2.7.4 Routing and Forwarding on Sham Links ................. 19
4.2.8 VPN-IPv4 routes received via BGP ..................... 21 4.2.8 VPN-IPv4 routes received via BGP ..................... 20
4.2.8.1 External Routes ...................................... 22 4.2.8.1 External Routes ...................................... 21
4.2.8.2 Summary Routes ....................................... 24 4.2.8.2 Summary Routes ....................................... 22
4.2.8.3 NSSA Routes .......................................... 24 4.2.8.3 NSSA Routes .......................................... 23
4.2.8.4 Sham Link Endpoint Address Routes .................... 24 5 IANA Considerations .................................. 23
5 IANA Considerations .................................. 25 6 Security Considerations .............................. 23
6 Security Considerations .............................. 25 7 Acknowledgments ...................................... 24
7 Acknowledgments ...................................... 26 8 Authors' Addresses ................................... 24
8 Authors' Addresses ................................... 26 9 Normative References ................................. 25
9 Normative References ................................. 27 10 Informative References ............................... 25
10 Informative References ............................... 27 11 Full Copyright Statement ............................. 25
11 Full Copyright Statement ............................. 27 12 Intellectual Property ................................ 26
12 Intellectual Property ................................ 28
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
[VPN] describes a method by which a Service Provider (SP) can use its [VPN] describes a method by which a Service Provider (SP) can use its
skipping to change at page 4, line 28 skipping to change at page 4, line 28
Consider a set of VPN sites which are thought of as being in the same Consider a set of VPN sites which are thought of as being in the same
"OSPF domain". Two sites are considered to be in the same OSPF domain "OSPF domain". Two sites are considered to be in the same OSPF domain
if it is intended that routes from one site to the other be if it is intended that routes from one site to the other be
considered to be intra-network routes. A set of OSPF sites in the considered to be intra-network routes. A set of OSPF sites in the
same domain will almost certainly be a set of sites which together same domain will almost certainly be a set of sites which together
constitute an "intranet", and each of which runs OSPF as its intra- constitute an "intranet", and each of which runs OSPF as its intra-
site routing protocol. site routing protocol.
Per [VPN], the VPN routes are distributed among the PE routers by Per [VPN], the VPN routes are distributed among the PE routers by
BGP. If the PE uses OSPF to distribute routes to the CE router, the BGP. If the PE uses OSPF to distribute routes to the CE router, the
standard procedures governing BGP/OSPF interactions [OSPF] would standard procedures governing BGP/OSPF interactions [OSPFv2] would
cause routes from one site to be delivered to another in type 5 LSAs cause routes from one site to be delivered to another in type 5 LSAs
("Link State Advertisements"), as "AS-external" routes. This is ("Link State Advertisements"), as "AS-external" routes. This is
undesirable; it would be much better to deliver such routes in type 3 undesirable; it would be much better to deliver such routes in type 3
LSAs (as inter-area routes), so that they can be distinguished from LSAs (as inter-area routes), so that they can be distinguished from
any "real" AS-external routes that may be circulating in the VPN. any "real" AS-external routes that may be circulating in the VPN.
(That is, so that they can be distinguished by OSPF from routes which (That is, so that they can be distinguished by OSPF from routes which
really do not come from within the VPN.) Hence it is necessary for really do not come from within the VPN.) Hence it is necessary for
the PE routers to implement a modified version of the BGP/OSPF the PE routers to implement a modified version of the BGP/OSPF
interaction procedures. interaction procedures.
skipping to change at page 6, line 11 skipping to change at page 6, line 11
be possible, by suitable adjustment of the OSPF metrics, to make be possible, by suitable adjustment of the OSPF metrics, to make
OSPF prefer routes which traverse the SP's VPN backbone to OSPF prefer routes which traverse the SP's VPN backbone to
alternative routes which do not. alternative routes which do not.
- The OSPF metric assigned to a given route should be carried - The OSPF metric assigned to a given route should be carried
transparently over the VPN backbone. transparently over the VPN backbone.
Routes from sites which are not in the same OSPF domain will appear Routes from sites which are not in the same OSPF domain will appear
as AS-external routes. as AS-external routes.
We presuppose familiarity with the contents of [OSPF], including the We presuppose familiarity with the contents of [OSPFv2], including
OSPF LSA types, and will refer without further exegesis to type 1, 2, the OSPF LSA types, and will refer without further exegesis to type
3, etc., LSAs. Familiarity with [VPN] is also presupposed. 1, 2, 3, etc., LSAs. Familiarity with [VPN] is also presupposed.
4. BGP/OSPF Interaction Procedures for PE routers 4. BGP/OSPF Interaction Procedures for PE routers
4.1. Overview 4.1. Overview
4.1.1. VRFs and OSPF Instances 4.1.1. VRFs and OSPF Instances
A PE router which attaches to more than one OSPF domain MUST run an A PE router which attaches to more than one OSPF domain MUST run an
independent instance of OSPF for each domain. If the PE is running independent instance of OSPF for each domain. If the PE is running
OSPF as its IGP ("Interior Gateway Protocol"), the instance of OSPF OSPF as its IGP ("Interior Gateway Protocol"), the instance of OSPF
skipping to change at page 7, line 31 skipping to change at page 7, line 31
"sham link". If the next hop interface for an installed (OSPF- "sham link". If the next hop interface for an installed (OSPF-
distributed) route is the sham link, forwarding is done according to distributed) route is the sham link, forwarding is done according to
a corresponding BGP route. This is detailed in section 4.2.7.4. a corresponding BGP route. This is detailed in section 4.2.7.4.
To meet the requirements of section 3, a PE that installs a To meet the requirements of section 3, a PE that installs a
particular route into a particular VRF needs to know whether that particular route into a particular VRF needs to know whether that
route was originally an OSPF route, and if so, whether the OSPF route was originally an OSPF route, and if so, whether the OSPF
instance from which it was redistributed into BGP is in the same instance from which it was redistributed into BGP is in the same
domain as the OSPF instances into which the route may be domain as the OSPF instances into which the route may be
redistributed. Therefore a domain identifier is encoded as a BGP redistributed. Therefore a domain identifier is encoded as a BGP
Extended Communities attribute [EXT], and distributed by BGP along Extended Communities attribute [EXTCOMM], and distributed by BGP
with the VPN-IPv4 route. The route's OSPF metric and OSPF route type along with the VPN-IPv4 route. The route's OSPF metric and OSPF
are also carried as BGP attributes of the route. route type are also carried as BGP attributes of the route.
4.1.3. Inter-Area, Intra-Area, and External Routes 4.1.3. Inter-Area, Intra-Area, and External Routes
If a PE installs a particular VPN-IPv4 route (learned via BGP) in a If a PE installs a particular VPN-IPv4 route (learned via BGP) in a
VRF, and if this is the preferred BGP route for the corresponding VRF, and if this is the preferred BGP route for the corresponding
IPv4 prefix, then the corresponding IPv4 route is then "eligible for IPv4 prefix, then the corresponding IPv4 route is then "eligible for
redistribution" into each OSPF instance that is associated with the redistribution" into each OSPF instance that is associated with the
VRF. As a result, it may be advertised to each CE in an LSA. VRF. As a result, it may be advertised to each CE in an LSA.
Whether a route which is eligible for redistribution into OSPF is Whether a route which is eligible for redistribution into OSPF is
skipping to change at page 10, line 44 skipping to change at page 10, line 44
If a PE has a link which belongs to a non-zero area, the PE functions If a PE has a link which belongs to a non-zero area, the PE functions
as an Area Border Router (ABR) for that area. as an Area Border Router (ABR) for that area.
PEs do not pass along the link state topology from one site to PEs do not pass along the link state topology from one site to
another (except in the case where a sham link is used, see section another (except in the case where a sham link is used, see section
4.2.7). 4.2.7).
Per [OSPF, section 3.1], "the OSPF backbone always contains all area Per [OSPF, section 3.1], "the OSPF backbone always contains all area
border routers". The PE routers are therefore considered to be area border routers". The PE routers are therefore considered to be area
0 routers. Section 3.1 of [OSPF] also requires that area 0 be 0 routers. Section 3.1 of [OSPFv2] also requires that area 0 be
contiguous. It follows that if the OSPF domain has any area 0 contiguous. It follows that if the OSPF domain has any area 0
routers other than the PE routers, at least one of those MUST be a CE routers other than the PE routers, at least one of those MUST be a CE
router, and it MUST have an area 0 link (possibly a virtual link) to router, and it MUST have an area 0 link (possibly a virtual link) to
at least one PE router. at least one PE router.
4.2.4. OSPF Domain Identifiers 4.2.4. OSPF Domain Identifiers
Each OSPF instance MUST be associated with one or more Domain Each OSPF instance MUST be associated with one or more Domain
Identifiers. This MUST be configurable, and the default value (if Identifiers. This MUST be configurable, and the default value (if
none is configured) SHOULD be NULL. none is configured) SHOULD be NULL.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
** 1 or 2 for intra-area routes (depending on whether the ** 1 or 2 for intra-area routes (depending on whether the
route came from a type 1 or a type 2 LSA). route came from a type 1 or a type 2 LSA).
** 3 for inter-area routes ** 3 for inter-area routes
** 5 for external routes (area number must be 0) ** 5 for external routes (area number must be 0)
** 7 for NSSA routes. ** 7 for NSSA routes.
** 129 for Sham Link Endpoint Addresses. See section
4.2.7.1 for the specification of when this value must be
used.
Note that the procedures of section 4.2.8 do not make any Note that the procedures of section 4.2.8 do not make any
distinction between routes types 1, 2, and 3. If BGP distinction between routes types 1, 2, and 3. If BGP
installs a route of one of these types in the VRF, and if installs a route of one of these types in the VRF, and if
that route is selected for redistribution into OSPF, it will that route is selected for redistribution into OSPF, it will
be advertised by OSPF in either a type 3 or a type 5 LSA, be advertised by OSPF in either a type 3 or a type 5 LSA,
depending on the domain identifier. depending on the domain identifier.
* Options: 1 byte. Currently this is only used if the route * Options: 1 byte. Currently this is only used if the route
type is 5 or 7. Setting the least significant bit in the type is 5 or 7. Setting the least significant bit in the
field indicates that the route carries a type 2 metric. field indicates that the route carries a type 2 metric.
skipping to change at page 18, line 19 skipping to change at page 18, line 15
For a given OSPF instance, a VRF needs only a single Sham Link For a given OSPF instance, a VRF needs only a single Sham Link
Endpoint Address, no matter how many sham links it has. The Sham Endpoint Address, no matter how many sham links it has. The Sham
Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4 Link Endpoint Address MUST be distributed by BGP as a VPN-IPv4
address whose IPv4 address prefix part is 32 bits long. The Sham address whose IPv4 address prefix part is 32 bits long. The Sham
Link Endpoint Address MUST NOT be advertised by OSPF; if there is no Link Endpoint Address MUST NOT be advertised by OSPF; if there is no
BGP route to the Sham Link Endpoint Address, that address is to BGP route to the Sham Link Endpoint Address, that address is to
appear to be unreachable, so that the sham link appears to be down. appear to be unreachable, so that the sham link appears to be down.
4.2.7.2. Creating Sham Links 4.2.7.2. Creating Sham Links
Sham links may be manually configured, or they may be auto- Sham links are manually configured.
configured.
Each VRF that is associated with a PE-CE link on which OSPF is
running MUST be configurable as to whether auto-configuration of sham
links to/from that VRF is allowed. The default MUST be "manual
configuration".
If a VRF is configured for manual configuration of the sham links, it
will never initiate auto-configuration of a sham link, nor will it
ever create a sham link as the result of a remotely initiated auto-
configuration procedure. If a VRF is configured for auto-
configuration of sham links, manual configuration of particular sham
links is still allowed. In any event, no more than one sham link
with the same pair of sham link endpoint addresses will ever be
created.
To manually configure a sham link between two VRFs, each VRF has to
be configured to create a sham link to the other, where the "other"
is identified by its sham link endpoint address. This specification
does not include procedures for single-ended manual configuration of
the sham link.
If a VRF is configured for auto-configuration of sham links, it MUST
distribute, via BGP, a VPN-IPv4 route corresponding to the 32-bit
Sham Link Endpoint Address (i.e., the route MUST consist of the 32-
bit Sham Link Endpoint Address with a prepended Route Distinguisher).
This route MUST have the OSPF Route Type Extended Community
attribute, with the OSPF Route Type field set to "Sham Link Endpoint
Address", the Area Number field set to the area number of the sham
link, and the Options byte set to 0. (If such a route is
distributed, it meets the requirements of the previous section that a
route for the Sham Link Endpoint address be distributed.)
Note that a route with Route Type "sham link endpoint address" is
treated by BGP decision process as an ordinary route, which will be
installed in the VRF if the BGP decision process regards it as the
preferred route for that address. However, the reception of such a
route may trigger the creation of an auto-configured sham link even
if the route is not installed in the VRF.
The requirement of the previous section, that the Sham Link Endpoint
Address MUST be distributed by BGP as a VPN-IPv4 address whose IPv4
address prefix part is 32 bits long, MAY be met by distributing the
route with the OSPF Route Type field set to "sham link endpoint
address".
When a PE receives such a route, with a Route Target value that
allows the route to be imported into a particular VRF, then if
- that route has an OSPF Domain Identifier Extended Communities
attribute which is identical to the Domain Identifier of one of
the VRF's OSPF instances, or the route has no OSPF Domain
Identifier Extended Communities attribute and each of the VRF's
OSPF instances has only a NULL Domain Identifier, AND
- that route has an OSPF area number which matches that of at least
one of the interfaces associated with the VRF,
then if the local VRF is configured for auto-configuration of sham
links, a sham link is created from the local VRF to the VRF
identified by the sham link endpoint address. If the VRF is
associated with more than one OSPF instance, the OSPF instance to
which the sham link belongs is determined by the Domain Identifier.
When comparing two OSPF Domain Identifier Extended Communities
attributes for equality, all eight bytes of the Extended Communities
attribute must be compared. The two attributes are regarded as equal
only if they are identical in all eight bytes, or if the lower order
six bytes are identical, and one attribute has two high order bytes
of 0005 and the other has two high order bytes of 8005.
If all VRFs are configured for auto-configuration of sham links, a For a sham link to exist between two VRFs, each VRF has to be
full mesh of sham links will be created among all the sites which are configured to create a sham link to the other, where the "other" is
in the same OSPF area. This may not be what is desired. To obtain identified by its sham link endpoint address. No more than one sham
more control over the set of sham links which are created, some or link with the same pair of sham link endpoint addresses will ever be
all of the VRFs can be configured to disable auto-configuration of created. This specification does not include procedures for single-
the sham links. ended manual configuration of the sham link.
Note that sham links may be created for any area, including area 0. Note that sham links may be created for any area, including area 0.
A sham link connecting two VRFs is considered to be up if and only if A sham link connecting two VRFs is considered to be up if and only if
a route to the 32-bit remote endpoint address of the sham link has a route to the 32-bit remote endpoint address of the sham link has
been installed in VRF. been installed in VRF.
The sham link endpoint address MUST NOT be used as the endpoint The sham link endpoint address MUST NOT be used as the endpoint
address of an OSPF Virtual Link. address of an OSPF Virtual Link.
skipping to change at page 24, line 41 skipping to change at page 23, line 16
the VPN-IPv4 route carries an area number identical to that of the CE the VPN-IPv4 route carries an area number identical to that of the CE
router. This means that if an area is "partitioned" such that the router. This means that if an area is "partitioned" such that the
two pieces are connected only via the VPN backbone, it appears to be two pieces are connected only via the VPN backbone, it appears to be
two areas, with inter-area routes between them.) two areas, with inter-area routes between them.)
4.2.8.3. NSSA Routes 4.2.8.3. NSSA Routes
NSSA routes are treated the same as external routes, as described in NSSA routes are treated the same as external routes, as described in
section 4.2.8.1. section 4.2.8.1.
4.2.8.4. Sham Link Endpoint Address Routes
These VPN-IPv4 routes are treated just as other routes are for the
purpose of determining whether to install the route in a VRF and
whether to select the route. However, these routes MUST NOT be
redistributed into OSPF. If there is no BGP route to the Sham Link
Endpoint Address, the address is considered to be unreachable and the
Sham Link is considered to be down.
5. IANA Considerations 5. IANA Considerations
Section 11 of [EXT] calls upon IANA to create a registry for BGP Section 11 of [EXTCOMM] calls upon IANA to create a registry for BGP
Extended Communities Type Field and Extended Type Field values. Extended Communities Type Field and Extended Type Field values.
Section 4.2.6 of this document assigns new values for the BGP Section 4.2.6 of this document assigns new values for the BGP
Extended Communities Extended Type Field. These values all fall Extended Communities Extended Type Field. These values all fall
within the range of values which [EXT] states "are to be assigned by within the range of values which [EXTCOMM] states "are to be assigned
IANA, using the 'First Come, First Served' policy defined in RFC by IANA, using the 'First Come, First Served' policy defined in RFC
2434". 2434".
The BGP Extended Communities Extended Type Field values assigned in The BGP Extended Communities Extended Type Field values assigned in
section 4.2.6 of this document are: section 4.2.6 of this document are:
- OSPF Domain Identifier: Extended Types 0005, 0105, and 0205. - OSPF Domain Identifier: Extended Types 0005, 0105, and 0205.
- OSPF Route Type: Extended Type 0306 - OSPF Route Type: Extended Type 0306
- OSPF Router ID: Extended Type 0107 - OSPF Router ID: Extended Type 0107
6. Security Considerations 6. Security Considerations
Security considerations which are relevant in general to BGP/MPLS IP Security considerations which are relevant in general to BGP/MPLS IP
VPNS are discussed in [VPN] and [VPNAS]. We discuss here only those VPNS are discussed in [VPN] and [VPN-AS]. We discuss here only those
security considerations that are specific to the use of OSPF as the security considerations that are specific to the use of OSPF as the
PE/CE protocol. PE/CE protocol.
A single PE may be running OSPF as the IGP of the SP backbone A single PE may be running OSPF as the IGP of the SP backbone
network, as well as running OSPF as the IGP of one or more VPNs. network, as well as running OSPF as the IGP of one or more VPNs.
This requires the use of multiple, independent OSPF instances, so This requires the use of multiple, independent OSPF instances, so
that routes are not inadvertently leaked between the backbone and any that routes are not inadvertently leaked between the backbone and any
VPN. The OSPF instances for different VPNs must also be independent VPN. The OSPF instances for different VPNs must also be independent
OSPF instances, to prevent inadvertent leaking of routes between OSPF instances, to prevent inadvertent leaking of routes between
VPNs. VPNs.
skipping to change at page 26, line 29 skipping to change at page 25, line 4
E-mail: erosen@cisco.com E-mail: erosen@cisco.com
Peter Psenak Peter Psenak
Parc Pegasus, Parc Pegasus,
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ppsenak@cisco.com E-mail: ppsenak@cisco.com
Padma Pillay-Esnault Padma Pillay-Esnault
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
E-mail: ppe@cisco.com E-mail: ppe@cisco.com
9. Normative References 9. Normative References
[EXT] "BGP Extended Communities Attribute", draft-ietf-idr-bgp-ext- [EXTCOMM] "BGP Extended Communities Attribute", RFC 4360, Sangli, S.,
communities-09.txt, Sangli, S., Tappan, D., Rekhter, Y., July 2005 Tappan, D., Rekhter, Y., February 2006
[OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998
[OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP [OSPF-DN] "Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP
VPNs", draft-ietf-ospf-2547-dnbit-04.txt, Rosen, Psenak, Pillay- VPNs", draft-ietf-ospf-2547-dnbit-04.txt, Rosen, Psenak, Pillay-
Esnault, March 2004 Esnault, March 2004
[RFC2119] "Key words for use in RFCs Indicate Requirement Levels", [RFC2119] "Key words for use in RFCs Indicate Requirement Levels",
RFC 2119, Bradner, S., March 1997 RFC 2119, Bradner, S., March 1997
[VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Rosen, [VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, E.
Rekhter, et. al. October 2004 Rosen and Y. Rekhter, February 2006
10. Informative References 10. Informative References
[BGP] "A Border Gateway Protocol 4 (BGP-4)", Rekhter, Y., Li, T., RFC [BGP] "A Border Gateway Protocol 4 (BGP-4)", Rekhter, Y., Li, T.,
1771, March 1995 Hares, S., RFC 4271, January 2006
[RIP] "RIP Version 2", Malkin, G., RFC 2453, November 1998 [RIP] "RIP Version 2", Malkin, G., RFC 2453, November 1998
[VPNAS] "Applicability Statement for BGP/MPLS IP VPNs", draft-ietf- [VPN-AS] "Applicability Statement for BGP/MPLS IP Virtual Private
l3vpn-as2547-07.txt, Rosen, October 2004 Networks (VPNs)", RFC 4365, E. Rosen, February 2006
11. Full Copyright Statement 11. Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 22 change blocks. 
132 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/