Internet DRAFT - draft-nalawade-l3vpn-bgp-connector
draft-nalawade-l3vpn-bgp-connector
Network Working Group Gargi Nalawade
Internet Draft Ruchi Kapoor
October 2005 David Ward
Cisco Systems
BGP Connector Attribute
draft-nalawade-l3vpn-bgp-connector-00.txt
1. 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.
2. Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
3. Abstract
In the case of BGP AFIs such as IPv6 unicast or VPNv4 unicast, it is
possible for the data traffic intended for the NLRIs of that
AFI/SAFI, to be forwarded over an underlying tunnel. The tunnel may
be to a PE or to a Tunnel Concentrator or a Tunnel Broker. Both will
be referred to as Tunnel endpoints. In this document an egress router
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 1]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
refers to the egress point of the Tunnel and an ingress router refers
to the ingress point of the tunnel.
The discovery of the Tunnel endpoint and the corresponding tunnel
encapsulation information may be done out of band, either by static
configuration, or through a number of different mechanisms.
There is a need to be able to indicate with the BGP update for a
given NLRI, the Tunnel endpoint to be used for forwarding data
traffic to that NLRI destination.
This document defines a new BGP attribute called the 'Connector
Attribute' which would convey the information about the Tunnel
endpoint - the Tunnel Identifier, the Tunnel endpoint address.
4. Introduction
When data traffic needs to be tunneled through an ISP core, multiple
tunneling types can be used (MPLS LSPs, IPsec, L2TPv3,...). The
establishment of the tunnels as well as the selection of the tunnel
type(s) to be used from an ingress router to a given egress router
can be statically controlled by configuration. Alternatively the
tunneling capabilities and preferences as well as the individual
tunnel attributes [BGP-TUN] can be dynamically discovered, and in
turn dynamically established, via various mechanisms such as the BGP
IPv4/IPv6 Tunnel SAFI [BGP-TUN-SAFI] or IGP based discovery of TE
tunnels [IGP-TE].
In some cases, the same tunnel can be used for all NLRIs advertised
by the egress router. The tunnel can then be selected by the ingress
router based on its local configuration as well as the information
that may have been advertised by the egress router about tunneling
capabilities and preferences for example via [BGP-TUN-SAFI].
In other cases, different NLRIs may need to be carried over different
tunnels. For example, some NLRIs may require transport over IPsec
tunnels while the other NLRIs may be more efficiently transported
without IPsec protection over MPLS LSPs. In these cases there is a
requirement for the egress router to advertise which tunnel ought to
be used for a particular set of NLRIs. The ingress router needs an
indication in the BGP update for these NLRIs, as to which tunnel to
use to reach the egress router. This indication is provided by the
Connector Attribute which is carried in the BGP AFI/SAFI updates (for
AFIs such as IPv4 Unicast, VPNv4 unicast etc.) along with the NLRIs
for that AFI/SAFI. The Connector attribute indicates the Tunnel-ID
and Tunnel endpoint address.
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 2]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
5. Connector Attribute
An Optional Transitive Connector attribute is being defined. This
attribute is meant to transport the Tunnel endpoint Identifier and
IPv4/6 address to the remote peer.
The attribute contains one or more tuples of the form :
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value (as specified by Type) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where :
Flags: The first 4 bits are flag bits.
The leftmost bit indicates whether the Tunnel endpoint is
IPv4 or IPv6. If the bit is not set it indicates IPv4 and
if the bit is set, it indicates IPv6.
Type : indicates the format of the value field.
Value : is a field as defined by the Type.
Following Types are being defined :
Type 1 : indicates that the value contains an IPv4 address of the
egress router.
Type 2 : indicates that the value is of the format
Tunnel-ID:Tunnel endpoint address
+--------------------------------+
| Tunnel Identifier (2 octets) |
+--------------------------------+
| Tunnel endpoint address |
| |
+--------------------------------+
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 3]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
where,
Tunnel-ID: is a 2 octet Identifier that uniquely identifies a
Tunnel on the advertising BGP router
Tunnel endpoint: is the IPv4/6 address of the Tunnel endpoint.
Type 3 : indicates that the value if of the format Multicast
Tree Identifier:Tunnel endpoint address
+--------------------------------+
| Tree Identifier (2 octets) |
+--------------------------------+
| Tunnel endpoint address |
| |
+--------------------------------+
where,
Tree-ID: is a 2 octet Identifier that uniquely identifies a
Multicast Tree on the advertising BGP router
Tunnel endpoint: is the IPv4/6 address of the Multicast Tree
endpoint.
The attribute may contain one or more tuples.
8. Operation
Let us consider the case when an ingress router receives a BGP update
for NLRIs which will receive data traffic (Eg. IPv4/6
unicast/multicast, VPNv4/6 etc). If this update contains a Connector
attribute carrying a Type, Tunnel-ID and Tunnel endpoint address, the
ingress router will use this information in the following manner :
The Tunnel/Tree-ID and the Tunnel endpoint address will be used to
lookup the appropriate tunnel in the Tunnel database to establish
data forwarding through this Tunnel. Data traffic for the NLRIs
carried in this BGP update will now be forwarded through this Tunnel.
The Tunnels themselves will be established by the respective Tunnel
protocols (Eg. mGRE, IPSec, L2TP etc).
As an example, if the BGP Tunnel SAFI is the mechanism used to
discover the Tunnels, then the Tunnel-ID:Tunnel endpoint address will
be the NLRI carried by the BGP Tunnel SAFI [BGP-TUN-SAFI] updates.
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 4]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
The Tunnel encapsulations will be carried in the BGP Tunnel attribute
[BGP-TUN] accompanying the BGP Tunnel SAFI update.
On the other hand, if IGP-based discovery of TE tunnels [IGP-TE], the
mechanism used to discover TE tunnels, then the Tunnel-ID and Tunnel
endpoint address will identify the TE tunnel discovered through this
mechanism.
Similarly this applies to other out of band Tunnel discovery
mechanisms as well which includes static configuration.
9. Applicability Statement
9.1. VPNv4 unicast traffic over a Tunnel
If VPNv4 unicast traffic has to be tunneled through an ISP core
instead of being MPLS switched as per RFC 2547, then the ingress PE
needs to know what Tunnel to connect to. The Tunnel encapsulation
itself could be statically configured or discovered through various
mechanisms such as IGP based discovery of TE tunnels [IGP-TE] or a
BGP Tunnel SAFI [BGP-TUN-SAFI].
If an ingress PE receives a BGP update for the VPNv4 prefix with a
Connector attribute, it would be able to connect to the appropriate
Tunnel. Using the Tunnel-ID and Tunnel endpoint address, the
Connector attribute will indicate which Tunnel is to be used to reach
the VPNv4 destination.
9.2. MVPN traffic over a default MDT Tunnel
A Multicast tunnel is setup between the PEs in one or more VPN-
Providers networks. Over the Multicast tunnel we create PIM
neighbors. The IP address of the PIM neighbor that is seen over the
Multicast tunnel depends on the configured address of the Tunnel
endpoint. This can either be an unnumbered address from a different
interface or a configured address on the Tunnel itself. The PE router
that does an RPF check on a VPN source can find which Tunnel the
source is on, but may not know what PIM neighbor to target on that
tunnel. Therefore we need a way to connect the BGP VPNv4 prefix to
the PIM neighbor on the tunnel to allow the RPF check to succeed.
Suppose PIM wants to join to a source that is behind another VPN
site. We do an RPF lookup on the source address in the VPNv4 unicast
table on this PE. The RPF lookup will return a connected next-hop and
interface to use to reach the source. The returned next-hop may not
be the neighbor on the Multicast tunnel. This can be due to the
next-hop being rewritten by BGP Route Reflectors (RR) or crossing
AS's. Therefore we don't know which PIM neighbor to target as an
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 5]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
upstream neighbor in the PIM join.
This can be achieved by using the Connector attribute to carry that
information. The Connector attribute when carried with Type 1, will
indicate what default MDT tunnel endpoint's IP address is.
9.3. Multicast VPN traffic over Label-switched or other Multicast
Tunnels
If a BGP Multicast Overlay SAFI [BGP-MOS] is used for signalling
Multicast Join/Prune Binding information, the downstream PE needs to
know what Multicast tree built by MLDP or what Tunnel to bind to. The
Tunnel encapsulation information itself could be provided by MLDP
when Multipoint LSPs are used in the core. Or the Tunnel
encapsulation could be provided by TE, or through the BGP Tunnel SAFI
[BGP-TUN-SAFI]. Either ways, the downstream PE needs to know which
Tunnel to connect to in order to receive a Multicast stream
corresponding to a given PIM Join.
This can be achieved by the Upstream PE sending the Tunnel/P-MP LSP
binding information through the Connector attribute.
10. Security Considerations
This extension to BGP does not change the underlying security issues.
11. Acknowledgements
The authors would like to thank Arjun Sreekantaiah, Francois Le
Faucher, Eric Rosen and Scott Wainner for their feedback, review and
comments.
12. Normative References
[BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway Protocol
4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-26.txt, April 2005.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002.
[BGP-TUN] Kapoor R., Nalawade G., "BGPv4 Tunnel Encapsulation
Attribute", Oct 2005, <draft-kapoor-nalawade-bgp-ssa-04.txt>, Work in
Progress.
[BGP-TUN-SAFI] Nalawade G., Kapoor R., Tappan T., Wainner S. "BGPv4
Tunnel SAFI", October 2005, <draft-nalawade-kapoor-bgp-tunnel-safi-
04.txt>, Work in Progress.
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 6]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
[BGP-MOS] Nalawade G., Bhaskar N., Mehta P. "Multicast PE-PE
Signaling using BGP", October 2005, draft-nalawade-bgp-mcast-
signaling-00.txt, Work in Progress.
[MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft-
ietf-idr-rfc2858bis-02.txt, work in progress.
[IGP-TE] Vasseur J., Psenak P., Yasukawa S., "OSPF MPLS Traffic
Engineering Capabilities", Feb 2004, Work in Progress.
13. Author's Addresses
Gargi Nalawade
170 Tasman Drive
San Jose, CA, 95134
E-mail: gargi@cisco.com
Ruchi Kapoor
170 Tasman Drive
San Jose, CA, 95134
E-mail: ruchi@cisco.com
David Ward
408 St Peter Street, Hamm Bldg
St Paul, MN, 55102
E-mail: wardd@cisco.com
14. 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 rights that may cover technology that may be required
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 7]
Internet Draft draft-nalawade-l3vpn-bgp-connector-00.txt October 2005
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
15. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
16. Expiration Date
This memo is filed as <draft-nalawade-l3vpn-bgp-connector-00.txt>, and
expires April, 2006.
draft-nalawade-l3vpn-bgp-connector-00.txt [Page 8]