One document matched: draft-lefaucheur-mp-nh-00.txt
Francois Le Faucheur
Dan Tappan
Gargi Nalawade
Cisco Systems, Inc.
IETF Internet Draft
Expires: May, 2002
Document: draft-lefaucheur-mp-nh-00.txt June, 2003
BGP-4 Multiprotocol Next Hop Attribute
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are
Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months 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.
Abstract
This document specifies a new BGP attribute, called the BGP-4
Multiprotocol Next Hop (MP_NEXT_HOP), which can optionally be used
in conjunction with the MP_REACH_NLRI defined in [MP-BGP] (or the
NLRI field defined in BGP-4) to advertise next hop information
associated with a different Network Layer protocol to the one
associated with the NLRI. This is desirable or required in a number
of environments, but is not currently possible with [MP-BGP].
In addition, the MP_NEXT_HOP provides the generic capability to
advertise information (set of TLVs) associated with the next hop.
Finally, provision is made for a future potential extension to allow
advertisement of multiple next hops.
Le Faucheur et al. 1
BGP-4 Multiprotocol Next Hop Attribute June 2003
The extensions proposed in this document are backward compatible: a
router which supports the extensions can interoperate with a router
that doesn't support the extensions.
1. Introduction
[MP-BGP] defines extensions to BGP-4 to enable it to carry routing
information for multiple Layer protocols (e.g. IPv4-VPN, IPv6, IPv6-
VPN). This is achieved by associating a particular Network Layer
protocol with the next hop information and with the NLRI. In [MP-
BGP], the Network Layer Protocol is simultaneously associated with
both the next hop information and the NLRI. Thus [MP-BGP] does not
allow advertisement of next hop information from a different Network
Layer protocol to the one of the NLRI.
However, there are situations where the next hop information to be
advertised is indeed from a different Network Layer protocol to the
one of the NLRI.
In a number of such situations, the [MP-BGP] limitation has been
circumvented by effectively embedding the meaningful next hop
information inside the next hop information field of the same
Network Layer protocol as the NLRI, and somehow flagging this fact
through ad-hoc padding of the unused bits of the field. [RFC2547] is
an example of this since it calls for advertisement of IPv4 next hop
information along with IPv4-VPN NLRI, which is achieved by
prepending a Null Route Distinguisher to the IPv4 Next Hop address.
[BGP-TUN] is another example of this since it calls for
advertisement of IPv4 next hop information along with IPv6 NLRI,
which is achieved by encoding the IPv4 next hop address as an
IPv4-mapped IPv6 address. [IPv6-VPN] is yet another example of this
since it calls for advertisement of IPv4 or IPv6 next hop
information along with IPv6-VPN NLRI, which is achieved by
prepending a Null Route Distinguisher to the next hop address and,
when the meaningful next hop is IPv4, by encoding it as an
IPv4-mapped IPv6 address.
In a number of other situations, the [MULTI-BGP] limitation would be
very difficult to circumvent in similar ways because the Network
Layer protocol of the meaningful next hop information is such that
the next hop address to convey cannot be aligned to the format
corresponding to the Network Layer protocol of the NLRI by simple
padding. Support of IPv4 VPNs over an IPv6 backbone is an example of
this since it calls for advertisement of IPv6 next hop information
along with IPv4-VPN NLRI.
As a general solution to this problem, this document specifies a new
BGP attribute, called the BGP-4 Multiprotocol Next Hop
(MP_NEXT_HOP), which can optionally be used in conjunction with the
MP_REACH_NLRI defined in [MP-BGP] (or with the NLRI field defined in
Le Faucheur et. al 2
BGP-4 Multiprotocol Next Hop Attribute June 2003
BGP-4) to advertise next hop information associated with a different
Network Layer protocol to the one associated with the NLRI.
In addition, the MP_NEXT_HOP attribute provides the generic
capability to advertise information (set of TLVs) associated with
the next hop. Finally, provision is made for a future potential
extension to allow advertisement of multiple next hops.
The extensions proposed in this document are backward compatible: a
router which supports the extensions can interoperate with a router
that doesn't support the extensions.
2. Multiprotocol Next Hop - MP_NEXT_HOP (Type Code TBD)
This is an optional non-transitive attribute that can be used for
the purpose of advertising the address of any Network Layer protocol
that should be used as the next hop to the destinations advertised
in the BGP NLRI field, or in the MP_NLRI field of the MP_REACH_NLRI
attribute.
The attribute is encoded as shown below:
+---------------------------------------------------------+
| Reserved-1 (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop (2 octets) |
+---------------------------------------------------------+
| Address Family Identifier (2 octets) |
+---------------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) |
+---------------------------------------------------------+
| Length of Next Hop Network Address (1 octet) |
+---------------------------------------------------------+
| Network Address of Next Hop (variable) |
+---------------------------------------------------------+
| Set of Next Hop TLVs (variable length) |
+---------------------------------------------------------+
Where:
"Reserved-1" (1 octet):
This field MUST be set to 1. It may be used in the future
to indicate the number of "sets of next hop information"
carried in the attribute in case there is such a need,
where each set of next hop information comprises Length of
Next Hop, Address Family Identifier, Subsequent Address
Family Identifier, Length of Next Hop Network Address,
Network Address of Next Hop and Set of Next Hop TLVs.
Le Faucheur et. al 3
BGP-4 Multiprotocol Next Hop Attribute June 2003
"Length of Next Hop" (2 octets):
This field indicates the total length in octets of all the
following fields related to the Next Hop (ie AFI, SAFI,
Length of Network Address, Network Address and Reserved-
2).
Address Family Identifier (2 octets):
This field carries the identity of the Network Layer
protocol associated with the Next Hop Network Address that
follows. Presently defined values for this field are
specified in RFC1700 (see the Address Family Numbers
section).
Subsequent Address Family Identifier (1 octet):
This field provides additional information about the type
of the Next Hop Network Address that follows.
Length of Next Hop Network Address (1 octet):
This field indicates the length in octets of the Next Hop
Network Address field which follows.
Next Hop Network Address (variable length):
This field contains the Network Address of the next router
on the path to the destination system(s).
Set of Next Hop TLVs (variable length):
This field carries zero or more TLVs associated with the
Next Hop whose address is contained in the previous field.
Specification of these TLVs is beyond the scope of this
document.
3. Operations
When a BGP Speaker supporting the MP_NEXT_HOP attribute wants to
advertise itself as the router that should be used as the next hop
to the destinations advertised in the NLRI field, or in the MP_NLRI
field of the MP_REACH_NLRI attribute, and wants to advertise one of
its Network Layer addresses for a Network Layer protocol which is
different to the Network Layer protocol of the NLRI destinations,
the BGP speaker SHOULD include the MP_NEXT_HOP attribute and convey
this (these) Network Layer address(es) inside.
A BGP Speaker supporting the MP_NEXT_HOP attribute which receives a
BGP advertisement containing a MP_NEXT_HOP attribute and which does
not modify the next hop information, SHOULD propagate the received
MP_NEXT_HOP attribute unchanged.
A BGP Speaker supporting the MP_NEXT_HOP attribute which receives a
BGP advertisement containing a MP_NEXT_HOP attribute and which
modifies next hop information, SHOULD include an MP_NEXT_HOP
Le Faucheur et. al 4
BGP-4 Multiprotocol Next Hop Attribute June 2003
attribute in the generated advertisement with modified next hop
information. In particular, in the case where the BGP speaker
modifies next hop information, it MUST NOT simply propagate the
received MP_NEXT_HOP unchanged.
When a BGP speaker supporting the MP_NEXT_HOP attribute receives a
BGP advertisement with next hop information encoded both in the
MP_REACH_NLRI and in the MP_NEXT_HOP, the BGP speaker SHOULD use the
next hop information encoded in the MP_NEXT_HOP, unless configured
to do otherwise.
4. Usage Examples
4.1. IPv4 VPNs over IPv6 Core
The MP_NEXT_HOP attribute may be used for support of IPV4 VPNs over
an IPv6 backbone. In this application, PE Routers would advertise
IPv4-VPN NLRI information in the MP_REACH_NLRI along with an IPv6
next hop in the MP_NEXT_HOP attribute.
4.2. IPv4 over IPv6 Core
The MP_NEXT_HOP attribute may be used for support of IPv4
reachability over an IPv6 core. In this application, BGP speakers
would advertise IPv4 NLRI information in the MP_REACH_NLRI along
with an IPv6 next hop in the MP_NEXT_HOP attribute.
4.3. IPv6 over IPv4 Core
The MP_NEXT_HOP attribute may be used for support of IPv6
reachability over an IPv4 core. In this application, BGP speakers
would advertise IPv6 NLRI information in the MP_REACH_NLRI along
with an IPv4 next hop in the MP_NEXT_HOP attribute.
4.4. Migration of IPv4 VPN network to use of MP_NEXT_HOP
Let us consider the case where an (intra-AS) IPv4 VPN network:
- (i) initially operates purely as per [2547] and thus
advertises next hop information in the MP_REACH_NLRI along with VPN-
IPv4 NLRI, by pre-pending a Null Route Distinguisher to the IPv4
Next Hop address and
- (ii) has elected to migrate to the use of MP_NEXT_HOP
attribute for advertisement of the IPv4 next hop information.
Let us consider an arbitrary interim situation where some PEs have
been upgraded while others haven't, and, if used, some RRs have been
upgraded while others haven't.
Then some VPN-IPv4 NLRIs will be generated with next hop information
encoded only in the MP_REACH_NLRI (the ones generated by PEs which
have not been upgraded) while some VPN-IPv4 NLRIS will be advertised
Le Faucheur et. al 5
BGP-4 Multiprotocol Next Hop Attribute June 2003
with next hop information encoded both in the MP_REACH_NLRI and in
the MP_NEXT_HOP attribute.
If the advertisement transits via a Route Reflector which hasn't
been updated, the MP_NEXT_HOP attribute, if present, will be dropped
since it is non-transitive. If the advertisement transits via a
Route Reflector which has been updated, the MP_NEXT_HOP attribute,
if present, will be propagated.
Upgraded PEs receiving an advertisement will start making use of the
next hop information in the MP_NEXT_HOP attribute when present, and
will use next hop information in the MP_REACH_NLRI as before
otherwise. Non-upgraded PEs will ignore the MP_NEXT_HOP attribute
when present (since it is non-transitive) and will use next hop
information in the MP_REACH_NLRI as before.
When it can be established with certainty that all BGP speakers have
been upgraded to support the MP_NEXT_HOP attribute, PEs can stop
advertising next hop information in the MP_REACH_NLRI. This can be
achieved by setting the Length of Next Hop Network Address to zero
in the MP_REACH_NLRI.
Thus, the MP_NEXT_HOP attribute allows this migration to take place
without any flag day and with upgrade of BGP speakers independently
and in any arbitrary order.
5. Security Considerations
This document does not raise any additional security issues beyond
those of BGP-4 and the Multiprotocol extensions for BGP-4. The same
security mechanisms are applicable.
6. Acknowledgments
We thank Jim Guichard, Robert Raszuk and Pedro Marques for their
comments and suggestions on this document.
References
[MULTI-BGP] Bates et al, Multiprotocol Extensions for BGP-4, draft-
ietf-idr-rfc2858bis-02.txt, work in progress.
[RFC2547] Rosen et al., BGP/MPLS VPNs, draft-ietf-ppvpn-rfc2547bis-
03.txt, work in progress.
[BGP-TUNN] Ooms et al., Connecting IPv6 Islands across IPv4 Clouds
with BGP, draft-ooms-v6ops-bgp-tunnel-00.txt, work in progress.
Le Faucheur et. al 6
BGP-4 Multiprotocol Next Hop Attribute June 2003
[IPv6-VPN] De Clercq et al., BGP-MPLS VPN extension for IPv6 VPN,
draft-ietf-ppvpn-bgp-ipv6-vpn-03.txt, work in progress.
[RFC1700] Postel et al., Assigned Numbers, STD2, RFC1700 (see also
http://www.iana.org/iana/assignments.html)
Authors' Address:
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Email: flefauch@cisco.com
Dan Tappan
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, 01719, MA
USA
Email: tappan@cisco.com
Gargi Nalawade
Cisco Systems, Inc.
510 McCarthy Blvd
Milpitas, 95035, CA
USA
Email: gargi@cisco.com
Le Faucheur et. al 7
| PAFTECH AB 2003-2026 | 2026-04-23 06:11:17 |