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]