[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02
L3VPN Working Group Marko Kulmala
Internet Draft Ville Hallivuori
Expires: August 2006 Tellabs
Jyrki Soini
Telia Sonera
Jim Guichard
Robert Hanzl
Cisco Systems Inc
Martin Halstead
Nexagent Ltd
February 6, 2006
ASBR VRF context for BGP/MPLS IP VPN
draft-kulmala-l3vpn-interas-option-d-02.txt
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.
Kulmala et al. Expires August 6, 2006 [Page 1]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
Abstract
This document describes an additional option to the 'Multi-AS
Backbones' section of [RFC4364]. This option combines per VPN VRFs at
the Autonomous System Border Router (ASBR) as described in 'Option A'
with the redistribution of labeled VPN-IPv4 routes as described in
'Option B'. In addition, this option allows for a data plane consisting
of two methods of traffic forwarding between attached ASBR pairs.
In this Multi-AS option, the ASBR installs VPN-IPv4 routes into VRFs in
the same manner as described in [RFC4364] e.g. VPN-IPv4 routes are
converted back to IPv4 routes and imported into VRFs via Route Target
(RT) based filtering policies. Once installed in a VRF, selected IPv4
routes are converted to VPN-IPv4 routes by the addition of Route
Distinguisher (RD) values, along with one or more associated RTs as
configured per VRF at the ASBR.
Dependant on service provider preference, traffic forwarding between
attached ASBRs is either via per VRF attachment circuits or a 'global'
(non-VRF attachment circuit associated) IP interface. In both traffic
forwarding cases, packets may be MPLS-labeled or non-labeled.
If attached ASBR pairs belonging to separate Autonomous Systems (AS)
make use of this Multi-AS option, then VRF based route filtering
policies via RTs is achieved directly between ASBR pairs, independent
of PE based RT filtering within an AS.
Table of Contents
1. Conventions used in this document.............................3
2. Introduction..................................................3
3. Scope.........................................................4
4. ASBR VRF Context Reference Model..............................4
4.1. Route Advertisement to External BGP Peers................5
4.1.1. Route Advertisement - Private interface forwarding..6
4.1.2. Route Advertisement - Shared interface forwarding...6
4.2. Route Advertisement to Internal BGP Peers................7
4.3. Packet forwarding........................................7
4.3.1. Packet Forwarding - Private Interface Forwarding....7
4.3.2. Packet Forwarding - Shared interface forwarding.....7
5. ASBR VRF Context Operation....................................8
5.1. Inter-AS IP VPN Route Distribution.................;.....8
Kulmala et al. Expires August 6, 2006 [Page 2]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
5.1.1. Private Interface Forwarding Route Distribution.....8
5.1.2. Shared interface forwarding Route Distribution......8
5.2. Per VRF Route Limiting...................................9
5.3. Inter-AS Route Aggregation...............................9
5.4. Inter-AS per VRF Access Control Lists....................9
6. Carrier's Carrier Considerations for Private Interface Forwarding
................................................................9
7. Inter-AS Quality of Service...................................9
8. Deployment Considerations....................................10
9. Comparisons of Inter-AS options..............................11
10. Security Considerations.....................................13
11. Acknowledgments.............................................13
12. Intellectual Property Statement.............................13
13. Full Copyright Statement....................................14
14. Normative References........................................14
15. Informative Reference.......................................14
16. Author Information..........................................15
1. Conventions used in this document
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 RFC-2119
2. Introduction
Inter-AS VPN route distribution described in the Multi-AS section of
[RFC4364] is currently based on three options ('A', 'B' and 'C').
Each option, when deployed in isolation potentially exhibits
drawbacks that could be addressed by combining the beneficial
attributes of more than a single option.
Option 'A' inherently allows per VRF route readvertisement
import/export policy at the AS border. Options 'B' and 'C' do not
have this attribute, but remove Option 'A's requirement for per VRF
attachment circuit IPv4 peers and per-peer routing protocol or static
routing support. This additional Multi-AS option incorporates these
beneficial attributes, while allowing for two data plane forwarding
methods between attached ASBR pairs.
VPN packets can be forwarded between attached ASBR pairs either via
per VRF attachment circuits or via global (in the context of the
connected ASes), non VRF attachment circuit interfaces. For the
purposes of this document, VRF attachment circuit based forwarding
will be referred to as 'private interface forwarding' and non VRF
Kulmala et al. Expires August 6, 2006 [Page 3]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
attachment circuit forwarding will be referred to as 'shared
interface forwarding'.
Either traffic forwarding method can be utilized in conjunction with
the advertisement of labeled VPN-IPv4 routes between attached ASBRs.
Selection of either forwarding method is then dependant on service
provider requirements as discussed further in this document.
3. Scope
This Inter-AS VPN option is based on IPv4 VPN services as described
in [RFC4364], therefore references in this document are based on IPv4
only. This option does not preclude its use in VPN environments based
on IPv6 as described in [VPN-IPv6].
Existing inter-provider traffic forwarding techniques as described
in the 'Multi-AS' section of [RFC4364] are maintained and SHOULD be
available at the ASBR along with the new techniques described in
this document. Support of existing 'Multi-AS' options, along with
the new techniques are beyond the scope of this document.
4. ASBR VRF Context Reference Model
Figure 1 shows an arbitrary Multi-AS VPN interconnectivity scenario
between two Customer Edge routers, CE1 and CE2, interconnected by
Service Providers SP1 and SP2. This example shows a pair of
interfaces ('a' and 'b') between ASBR1 (belonging to SP1) and ASBR2
(belonging to SP2).
Interface 'b' is not associated with any VRF instances i.e. this
interface is 'global' in nature (in the context of the connected
ASes) and carries as a minimum all ASBR exported VPN-IPv4 routing
updates.
For shared interface forwarding outside of a VRF context, interface
'a' is not required. In addition to carrying all ASBR VPN-IPv4
routing updates, interface 'b' transports labeled IP VPN traffic or
native IPv4 traffic. IP VPN packets entering or leaving the ASBR via
this interface may be forwarded using normal MPLS mechanisms (e.g.
through use of the LFIB) or through a lookup within a VRF that has
been identified via MPLS label values.
For private interface forwarding, interface 'a' is a VRF attachment
circuit associated to VRF2 (on ASBR1) and VRF3 (on ASBR2) and is used
to transport labeled or native IP VPN traffic between VRF pairs. Per
Kulmala et al. Expires August 6, 2006 [Page 4]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
VPN routing updates are not advertised across this interface, rather
interface 'b' carries all ASBR VPN-IPv4 routing updates exported
from VRF pairs.
+-----+ +-----+
...| RR1 |... ...| RR2 |...
. +-----+ . . +-----+ .
. . . .
. . . .
+----+ +-----+ +-----+ +----+
+---+ |PE1 |-SP1-|ASBR1|-b-|ASBR2|-SP2-|PE2 | +---+
|CE1|--|VRF1| |VRF2 |-a-|VRF3 | |VRF4|--|CE2|
+---+ +----+ +-----+ +-----+ +----+ +---+
4.1. Route Advertisement to External BGP Peers
Routers CE1 and CE2 are in different Autonomous Systems, are members
of the same IP VPN (VPN-1) and require IP interconnectivity across
both SP1 and SP2. Router CE1 is associated to VRF1 on PE1. Routes
learned at VRF1 are converted by PE1 to VPN-IPv4 routes through the
attachment of an RD value which is associated with VRF1. PE1
allocates label values to these VPN-IPv4 routes and advertises these
label mappings to Route Reflector RR1, which in turn advertises the
routes to ASBR1.
ASBR1 has a VRF (VRF2) assigned, applicable to an IP VPN (VPN-1) to
which CE1 is a member. ASBR1 processes the VRF1 RT extended community
attributes and learns the label bindings associated with routes for
VPN-1. VPN-IPv4 routes are imported into VRF2's Routing Information
Base (RIB) where their RT and RD attributes, assigned by PE1 are
removed.
ASBR1 VPN-IPv4 routes are not advertised to RR1 as the original
routes applicable to VPN-1 sourced by PE1 were received from an
internal BGP peer. Any installed routes that are not imported into
VRF2's RIB MAY be advertised to external BGP peers using the existing
[RFC4364] Multi-AS "Option B" techniques. Dependant on which packet
forwarding method is used, routes are then exported from VRFs and
Kulmala et al. Expires August 6, 2006 [Page 5]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
advertised from ASBR1 to ASBR2 as described in the following
sections.
4.1.1. Route Advertisement - Private interface forwarding
VPN-IPv4 prefixes are advertised from ASBR1 to ASBR2 via a BGP
session that is in the global routing table context. This implies
that the advertised next-hop address is also reachable via the global
routing table context. In order to force traffic to be forwarded via
interface 'a', VRF forwarding entries need to be installed using a
next-hop address that is in VRF3's (which resides on ASBR2) routing
context. The address of the next-hop could be the same as the global
table address of the remote ASBR (in this case ASBR1), although this
would require that the same IP address be used across all VRF
attachment circuits linking ASBR pairs.
If the Service Provider needs to number the VRF interfaces
differently from the global table VPNv4 session, a configuration
method SHOULD be available so as to map the corresponding global
table VPNv4 neighbor address to an IP address reachable in the given
VRF.
ASBR1 exports routes associated to VPN-1 from VRF2's RIB to BGP where
RD and RT attributes, plus label bindings are attached to these
routes. These labeled VPN-IPv4 routes are advertised across interface
'b' to ASBR2 via BGP, with a label value set to implicit-null and the
'S' bit set. The routes next-hop addresses is set either to ASBR1
(usually interface 'b') or an address reachable via interface 'a'.
ASBR2 imports the VRF2 exported routes into VRF3's RIB where the
routes RT and RD attributes are removed. The imported routes next-hop
is either set via a policy or left unchanged to an address in VRF 3's
routing context. ASBR2 exports routes from VRF3's RIB to BGP and
attaches RT and RD attributes, as configured at VRF3 plus label
bindings. Labeled VPN-IPv4 routes are now advertised to PE2 via RR2
and so on.
4.1.2. Route Advertisement - Shared interface forwarding
ASBR1 exports routes associated to VPN-1 from VRF2's RIB to BGP where
RD and RT attributes, plus label bindings are attached to these
routes. These labeled VPN-IPv4 routes are advertised across interface
'b' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports the
VRF2 exported routes into VRF3's RIB where the routes RT and RD
attributes are removed. The imported routes next-hop is set to ASBR1,
available via interface 'b'. ASBR2 exports routes from VRF3's RIB to
BGP and attaches RT and RD attributes, as configured at VRF3 plus
Kulmala et al. Expires August 6, 2006 [Page 6]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
label bindings. Labeled VPN-IPv4 routes are now advertised to PE2 via
RR2 and so on.
4.2. Route Advertisement to Internal BGP Peers
On receipt of routes from an adjacent ASBR, the receiving ASBR needs
to import the routes into local VRFs and then advertise them toward
local PE-routers using an Internal BGP session. On advertisement the
sending ASBR MUST set the next-hop to itself so that label forwarding
can be successful.
4.3. Packet forwarding
Packets from CE2, destined for CE1 are label switched from PE2 to
ASBR2. The forwarding operation across the inter-ASBR links is
dependent upon the type of connection as discussed in the following
sections.
4.3.1. Packet Forwarding - Private Interface Forwarding
When receiving packets from its local AS, ASBR2 looks up the label
values (pushed on the packet by PE2) in its Label Forwarding
Information Base (LFIB). For traffic that will cross the inter-ASBR
links, ASBR2 pops these labels and performs an IP lookup via VRF3's
RIB. The next-hop for the routes is available via attachment circuit
interface 'a'. ASBR2 forwards the packets to VRF2 on ASBR1 via
attachment circuit interface 'a'. ASBR1 receives the packets and
looks up the destination IP addresses in VRF2's RIB where a match is
made.
4.3.2. Packet Forwarding - Shared interface forwarding
ASBR2 looks up the label values (pushed on the packet by PE2) in its
LFIB and performs either an IP lookup or label swap. For an IP
lookup, labels are popped and the packets destination address looked
up via VRF3's RIB. The next-hop for the routes is ASBR1, available
via interface 'b' and associated label binding. For a label swap,
ASBR2 finds a match for the label values in its LFIB and swaps the
labels for labels, learned via interface 'b'. In this case, no lookup
in VRF3's RIB is required. The labeled packets are now forwarded to
ASBR1 via interface 'b'. ASBR1 receives the packets via interface 'b'
and looks up the labels in its LFIB. Again, the packets could be
forwarded by ASBR1 to PE1 via either an IP lookup in VRF2 or label
swap.
Kulmala et al. Expires August 6, 2006 [Page 7]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
5. ASBR VRF Context Operation
5.1. Inter-AS IP VPN Route Distribution
Routes received from internal or external peers that are imported
into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors.
Routes that are not imported into VRFs but are installed in the
ASBR's global routing table MAY be readvertised using existing Option
'B' techniques as described in the Multi-AS section of [RFC4364]. The
ASBR MUST be equipped with RT based filtering mechanisms that
explicitly permit all or a subset of such RT values to be
readvertised to its neighbors.
IPv4 routes that are converted by the ASBR to labeled VPN-IPV4 routes
MUST NOT be readvertised to the source peer (or a Route Reflector
whose clients are PE neighbors), rather route readvertisement MUST
follow normal BGP route readvertisement policy for IBGP non route
reflector peers as specified in [BGP-4].
It SHOULD be possible to remove individual RT values when advertising
routes on a per neighbor basis. This is useful where the SP wants to
separate RT values advertised to EBGP peers from RT values advertised
to IBGP peers.
5.1.1. Private Interface Forwarding Route Distribution
For private interface forwarding, labeled VPN-IPv4 routes advertised
from ASBR to ASBR MUST have their next-hop set to an address within a
VRF RIB. This address will usually be the VRF attachment circuit
interface.
If the Service Provider needs to number the VRF interfaces
differently from the global table VPNv4 neighbor, a configuration
method SHOULD be available so as to map the corresponding global
table VPNv4 neighbor address to an IP address reachable in the given
VRF. This route mapping policy SHOULD be configurable on both
outbound and inbound peers.
5.1.2. Shared interface forwarding Route Distribution
For shared interface forwarding outside of a VRF context, the next-
hop must be a 'global' (non VRF RIB) address on an ASBR. This address
will usually be the interface linking ASBR pairs.
Kulmala et al. Expires August 6, 2006 [Page 8]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
5.2. Per VRF Route Limiting
The ASBR SHOULD have the ability to restrict the number of VPN-IPv4
routes installed per VRF and per BGP neighbor. The ability to
restrict numbers of routes learned on a per-VRF and BGP neighbor
basis SHOULD apply to routes received from External and Internal BGP
neighbors. This allows existing operational processes for per
customer restriction of numbers of routes to apply at the AS border.
5.3. Inter-AS Route Aggregation
The ASBR SHOULD have the capability to aggregate VPN-IPv4 routes
advertised per VRF. This allows existing operational processes for
per customer summarization of routes to apply at the AS border.
5.4. Inter-AS per VRF Access Control Lists
For shared interface forwarding, the ASBR SHOULD have the capability
to apply IPv4 based ACLs to received packets on a per VRF basis. For
private interface forwarding, IPv4 based ACLs should be configurable
per VRF attachment circuit.
6. Carrier's Carrier Considerations for Private Interface Forwarding
ASBRs need to allocate labels for prefixes that belong to VRFs and
are enabled for Carrier's Carrier operation. However, the ASBR has no
indication as to whether a given prefix was originated from a CSC
enabled VRF at the advertising PE. Therefore, the ASBR SHOULD have
the ability to dynamically or manually identify CSC enabled VPNs and
allocate labels accordingly.
7. Inter-AS Quality of Service
It SHOULD be possible for the ASBR as a DS boundary node [DS-ARCH]
operating traffic classification and conditioning functions to match
on ingress and egress a combination of application (TCP, UDP port,
RTP session, data pattern etc), IP Source Address, IP Destination
Address or DS field per packet, per VRF or per VRF attachment circuit
(in the case of private interface forwarding).
Once matched, the packets Layer-2 header (if applicable), IP DSCP and
MPLS EXP bits or combinations of the above should be capable of being
re-marked, and optionally shaped per traffic stream, dependant on the
DS domain's Traffic Conditioning Agreement (TCA). This will assist
where different DS domains have different TCA rules.
Kulmala et al. Expires August 6, 2006 [Page 9]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
For Private interface forwarding, the ASBR should be capable of
forwarding explicit null labeled MPLS packets across VRF attachment
circuits. This will assist with a pipe mode [DIFF-TUNNEL] operation
of traffic conditioning behavior at the ASBR. MPLS based forwarding
between attached ASBRs inherently should have these mechanisms built
in.
8. Deployment Considerations
For private interface forwarding where different IP addresses are
used across VRF attachment circuits linking ASBR pairs, routes that
are learnt from an adjacent ASBR SHOULD only be imported into a
single VRF as these routes could be rejected due to next-hop
validation failure. For VRF attachment circuits that share the same
IP address, care must be taken when importing routes into multiple
VRFs as configuration errors could result in the incorrect cross-
connection of VPNs.
Where attached ASBR pairs belonging to separate ASes make use of this
Multi-AS option, a hierarchical approach to the allocation of RT
values may be deployed. SPs should make use of existing RT allocation
schemas and numbering as applicable to their intra-domain IP VPN
service, while RTs advertised in EBGP updates that transit connected
ASBR pairs may be allocated from a separate pool owned by one of the
connected SPs, or a third party operator.
RT values assigned to VRFs at the AS border SHOULD, as per section
4.3.1 of [RFC4364] be provisioned with unique values across all
ASBRs. This policy will prevent incorrect cross-connection of IP VPN
routes into VRFs at the AS border. In this option, this policy need
not apply to RT values assigned within an AS.
RD values assigned to VRFs at the AS border SHOULD, as per section
4.2 of [RFC4364] be configured with unique values across all ASBRs.
This policy will enable traffic load balancing and CE-to-CE traffic
path optimization across multi-homed ASes. If attached ASBR pairs
operate this option, then ASBR advertised RDs cannot transit from one
AS to a Route Reflector in another AS. This will prevent the
possibility of routes being lost due to RD and address overlap,
resulting in incorrect best path decisions being made by Route
Reflectors.
Packet Switched Network (PSN) Traffic Engineering (TE) tunnels and TE
PSN tunnel attributes should be selectable per VRF at each ASBR. In
this option, Inter-AS TE tunnels could be be built AS-by-AS. ASBRs
and PEs within the same AS calculate routes and create TE tunnels
from VRFs to tail-end routers (ASBR VRF to PE and PE VRF to ASBR).
Kulmala et al. Expires August 6, 2006 [Page 10]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
This method does not require end-to-end TE LSPs with associated
Inter-AS extensions as per-AS TE tunnels are linked via VRFs at the
AS border. As TE tunnels do not transit from AS to AS, implementation
of TE tunnels with this option is vendor specific and out of the
scope of this document.
It may be desirable for ASBRs that have two or more eBGP neighbour to
advertise VPN-IPv4 routes to individual peers using more than a
single route advertisement technique. The ASBR may be configured to
advertise routes using techniques described in this document, i.e.
via VRF based import/export policy. In addition, the same ASBR may be
configured to advertised routes to separate peers by using existing
techniques described by Multi-AS option 'B' of [RFC4364]. The
following guidelines must be taken into consideration when
simultaneously deploying these options:
. Route filtering must be configured on the ASBR such that the same
route is not advertised to the same peer twice by simultaneously
using [RFC4364] Multi-AS option 'B' techniques and the techniques
described in this document. It is strongly recommended that only
one of these route advertising options is selected per peer, with
route filtering that by default explicitly prevents the other
option from being used.
. Different RD values should be configured across all ASBRs and PEs.
This will prevent routes from overlapping at the ASBR.
. Advertising of Route Target values, with associated RDs that are
sourced by customer attached PEs, rather than ASBRs could as
described in section 10. expose the VPN related topology of a
service provider to its neighbours.
9. Comparisons of Inter-AS options
This section describes some of the attributes of the three Multi-AS
options avaliable in [RFC4364].
Option 'a' allows for routes learned from external ASes to be
redistributed into an AS via VRF based export policies at the AS
border. This allows for RT and RD values to be applied per AS, rather
than end-to-end across AS borders. In addition, these VRFs are able
to restrict and summarize numbers of routes learned per VRF at the AS
border from other ASes.
In contrast, options 'b' and 'c' readvertise PE configured RT and RD
values from AS to AS, either via an ASBR in option 'b' or from PE to
PE (or AS route reflector to AS route reflector) in option 'c'. It
Kulmala et al. Expires August 6, 2006 [Page 11]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
may be possible to translate RT values at the AS border or Route
Reflector via BGP policies, but that is achieved per peer, rather
than via VRF based import/export policies. Options 'b' and 'c'
therefore do not offer an equivalent level of per VRF route
redistribution and IP VPN membership (RT and RD assignment)
separation as avaliable in option 'a'.
Options 'b' and 'c' require an LSP to exist from a packets ingress PE
to its egress PE. There is however a difference between how the two
option's LSPs operate. In establishing the LSP from AS to AS, option
'b', in contrast to option 'c' does not require PEs in separate ASes
to have visibility of each other. The interface attaching ASBR pairs
must in both options be MPLS enabled. In contrast to option 'a', this
removes the requirement for the interface media to support multiple
sub-interfaces, at least one per VRF whose traffic must pass from AS
to neighbouring AS. This static per IP VPN attachment circit
configuration could be seen as an advantage or disadvantage,
dependant on service provider requirements for security as discussed
further in section 9 of this document and per sub-interface ACL's as
discussed in section 5.4.
Option 'b' uses labeled VPN-IPv4 routes for route redistribution
directly between attached ASBRs in separate ASes. These single ASBR
to ASBR EBGP peers support routes associated to multiples of VPNs. In
contrast, Option 'a' requires each VRF on an ASBR to independantly
distribute unlabled IPv4 routes per VRF attachement circuit. This
requirement creates a depandancy on the ASBR to support a minimum of
a single EBGP peer per VRF attachment circuit.
This option builds on the beneficial attributes of the various
options described above by preserving per VRF route readvertisement
import/export policy at the AS border as described in option 'a',
while removing the requirement for per VRF IPv4 peers. Instead, EBGP
is used to readvertise labeled VPN-IPv4 routes via single ASBR to
ASBR peers as described in option 'b'. Due to differing SP
requirements for security and ACL's, this option supports either
'global' interface or VRF attachment circuit based IP VPN data plane.
In addition, per VPN VRFs at the ASBR allow Inter-AS TE to be
configured per VPN, per AS and between ASes using existing intra-AS
TE techniques.
Kulmala et al. Expires August 6, 2006 [Page 12]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
10. Security Considerations
For private interface forwarding, this document does not alter the
security properties of BGP based VPNs that are based on the
implementation described in Multi-AS Option 'a' of [RFC4364]. In this
forwarding option, all IP VPN traffic enters a service provider's
domain via VRF attachment circuits. The separate 'global' interface
carrying VPN-IPv4 routes between ASBRs does not forward IP VPN
traffic as all such traffic is forwarded between ASes via VRF
attachment circuits. Securing this 'global' interface is
implementation specific and beyond the scope of this document.
For shared interface forwarding, this document does not alter the
security properties of BGP based VPNs that are based on the
implementation described in Multi-AS Option 'b' of [RFC4364]. A trust
relationship between SP pairs is required as MPLS packets carrying IP
VPN traffic are forwarded across 'global' interfaces linking attached
ASBR pairs.
For both forwarding methods this inter-AS option does however hide
the SP's IP VPN topology construct (PE related RT and RD numbering).
11. Acknowledgments
The authors wish to acknowledge the contributions of Paul Hallanoro,
Heikki Heikkila, Jouni Tiainen, Nabil Bitar and Raymond Zhang.
12. Intellectual Property Statement
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
Kulmala et al. Expires August 6, 2006 [Page 13]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
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.
13. Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 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.
14. Normative References
[RFC4364] Rosen, E. and Rekhter, Y, " BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
15. Informative Reference
[BGP-4] Rekhter, Y. and T. Li,"A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[DS-ARCH] Blake, S et al, "An Architecture for Differentiated
Services", RFC 2475, December 1998
[VPN-IPv6] De Clercq et al, "BGP-MPLS IP VPN extension for IPv6 VPN",
draft-ietf-l3vpn-bgp-ipv6-07.txt, July 2005.
[DIFF-TUNNEL] Black, D, "Differentiated Services and Tunnels", RFC
2983, October 2000.
Kulmala et al. Expires August 6, 2006 [Page 14]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
16. Author Information
Ville Hallivuori
Tellabs
Sinimaentie 6
FI-02630 Espoo, Finland
e-mail: ville.hallivuori@tellabs.com
Martin Halstead
Nexagent
Thames Tower
Reading
Berkshire
RG1 1LX
United Kingdom
e-mail: mhalstead@nexagent.com
Marko Kulmala
Tellabs
Sinikalliontie 7
FI-02630 Espoo, Finland
e-mail: marko.kulmala@tellabs.com
Kulmala et al. Expires August 6, 2006 [Page 15]
Internet-Draft draft-kulmala-l3vpn-interas-option-d-02.txt February 2006
Jyrki Soini
TeliaSonera
P.O.Box 935
FI-00051 Sonera, Finland
e-mail: jyrki.soini@teliasonera.com
Jim Guichard
Cisco Systems Inc.
300 Beaver Brook Road
Boxborough, MA.
Email: jguichar@cisco.com
Kulmala et al. Expires August 6, 2006 [Page 16]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/