Internet DRAFT - draft-agrewal-idr-accept-own-nexthop
draft-agrewal-idr-accept-own-nexthop
IDR A. Grewal
Internet-Draft N. Sheth
Intended status: Standards Track K. Vairavakkalai
Expires: April 22, 2018 Juniper Networks
October 19, 2017
BGP accept-own-nexthop community attribute
draft-agrewal-idr-accept-own-nexthop-00
Abstract
Various Service chain techniques utilize a Controller to inject
Border Gateway Protocol (BGP) Virtual Private Network (VPN) routes to
help steer traffic through a given path. The Controller does so by
controlling how these VPN routes are imported into various Virtual
Routing and Forwarding (VRF) tables at routers along the desired
path. A couple of such approaches are specified in
[I-D.ietf-bess-service-chaining]. These approaches rely on the
Controller modifying the Route Target (RT) list and next-hop of a VPN
route received from a downstream router and redistributing these
modified routes to upstream routers. This is done such that -
o routes originated by an ingress VRF at the downstream router are
imported into the egress VRF at the immediately preceding upstream
router and
o next-hop advertised to the upstream router is the address of the
immediately succeeding downstream router.
This forces the traffic to flow through a sequence of network
functions creating a service chain.
This works fine as long as the VRF importing the route received from
the Controller is on a different router than the VRF that originally
exported the route to the Controller. This is because BGP protocol
[RFC4271] specifies that a router reject routes received with its own
next-hop. This document proposes a new community the reception of
which relaxes this particular rule in the BGP protocol standard and
describes at least one way of how next-hops of such routes could be
resolved.
Requirements Language
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 [RFC2119].
Grewal, et al. Expires April 22, 2018 [Page 1]
Internet-Draft bgp-accept-own-nhop October 2017
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 22, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. accept-own-nexthop community . . . . . . . . . . . . . . . . 5
3.1. New BGP behavior . . . . . . . . . . . . . . . . . . . . 5
3.2. Configuration Control . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
Grewal, et al. Expires April 22, 2018 [Page 2]
Internet-Draft bgp-accept-own-nhop October 2017
1. Introduction
The BGP ACCEPT_OWN Community Attribute standard [RFC7611] defined a
technique to let the route reflector modify the RT list of a VPN
route and redistribute it back to the originating Provider Edge (PE).
This enables the route reflector to control how a route originated
within one VRF at the PE is imported into other VRFs at the
originating PE. However, the ACCEPT_OWN standard does not specify
how the forwarding next-hop for such an accepted route is derived.
It is understood that once the source VRF is located, the original
route for this prefix in this source VRF is located and the next-hop
information of the original route is used as the forwarding state for
the received route. The standard also mandates that the route
received from the route reflector be originated by a source VRF on
the receiving router.
This document proposes a new community - BGP accept-own-nexthop -
whose usage means - 'accept a route with one's own next-hop'
(regardless of whether the route was originated by the PE). Doing
so, enables some new useful use cases. The scope of this community
does not mandate the route be originated by a source VRF on the
receiving router as was the case in BGP ACCEPT_OWN community
attribute. Also, the usage of this community does not specify how
the forwarding next-hop of such a route is derived. One different
approach, than the implicit approach used in BGP ACCEPT_OWN standard,
to obtain the forwarding information of the received route is
described below.
2. Use Case
Let us walk through an example of how a router could redirect
traffic, that it is receiving in the Ingress VRF, towards a Layer 2
Physical Network Function (PNF) before the traffic exits this router.
A gateway in the form of a router is necessary to have Layer 2 PNFs
become part of a service chain.
Grewal, et al. Expires April 22, 2018 [Page 3]
Internet-Draft bgp-accept-own-nhop October 2017
+--------------------------------------+
| Layer 2 Physical network function |
+-------------^------------|-----------+
| |
| |
| |
+---------------|------------|---------------+
| | | |
| +----|----+ +----v----+ |
| | Service | | Service | |
| +--> in-VRF | | out-VRF ---+ |
| | | | | | | |
| | +---------+ +---------+ | |
| | | |
| +----|----+ +----v----+ |
| | Ingress | | Egress | |
---------> VRF | | VRF --------->
| | | | | |
| +---------+ +---------+ |
| |
| Router |
+--------------------------------------------+
Figure 1: A Layer 2 PNF as part of service chain
In the service chaining scenario involving a Layer 2 PNF - a PE (Fig.
1) advertises a static route - configured inside a VRF (service in-
VRF) - whose next-hop is the interface that a (transparent layer-2)
service instance (viz., firewall, anti-virus system etc.) is
connected to. The prefix for this route is an address that also
belongs to the same subnet as this interface's address. The
destination address will be in a different vrf (Service out-VRF) at
the PE itself where the serviced traffic coming from the service will
be received to be sent to it's destination.
PE will advertise this route with next-hop as itself and a label that
identifies the interface on the PE that the service is connected to.
A Controller acting as an extended route reflector could now steer
the traffic for a particular destination - for which the controller
wants the traffic to be serviced - by sending a VPN route for that
destination, with PE's own address as the next-hop and the above
label. The RT that Controller attaches to such a route would allow
it to be imported to the Ingress VRF. Such a route will be resolved
using the received VPN label - that the PE itself advertised - to
point to whatever next-hop information that is associated with this
label locally. A controller may create multiple such service VRFs on
the PE and follow the above procedure for each service to construct a
Grewal, et al. Expires April 22, 2018 [Page 4]
Internet-Draft bgp-accept-own-nhop October 2017
service chain by advertising routes with different RTs for the same
destination prefix with different labels, where each label identifies
the interface towards that particular service.
3. accept-own-nexthop community
A new well-known BGP community in the First Come First Served
[RFC5226] range called accept-own-nexthop has been assigned value of
0XFFF008 by IANA.
3.1. New BGP behavior
A change to default BGP behavior is proposed such that a router that
receives a route, whose NEXT_HOP value matches one of the addresses
configured on itself, MAY accept the route if and only if the
following are true:
o The received route is carrying the accept-own-nexthop community.
o Processing of the accept-own-nexthop community is enabled by
configuration on the receiving router.
3.2. Configuration Control
The processing - as defined above - of accept-own-nexthop community
is disabled by default. An implementation SHOULD provide a
configuration statement to enable a router to activate the behavior
specified in this document.
4. IANA Considerations
IANA has assigned the value 0xFFFF0008 in the "BGP Well-known
Communities" registry for the accept-own-nexthop community.
5. Security Considerations
accept-own-nexthop community allows a router to accept a route with
it's own next-hop. If the originator of that route is that router
itself and if the router accepts the received route to the same VRF
from where it was originated route oscillations would happen if this
new route is more preferable than the original route. That is so
because the receiving router preferring the received route would lead
to it withdrawing its advertisement for the original route. This
will prompt the Controller to withdraw the re-originated route. This
in turn will prompt the PE to re-advertise the original route and the
cycle would continue.
Grewal, et al. Expires April 22, 2018 [Page 5]
Internet-Draft bgp-accept-own-nhop October 2017
Since these routes are like any other BGP VPN route, all the
vulnerabilities applicable to any other BGP VPN route are also
applicable to these routes. Such vulnerabilities for BGP VPN routes
have been described in [RFC4364].
6. Acknowledgements
The authors would like to thank John Scudder, Jeff Haas and Minto
Jeyanath for their valuable comments and suggestions.
7. References
7.1. Normative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
7.2. Informative References
[I-D.ietf-bess-service-chaining]
Fernando, R., Mackie, S., Rao, D., Rijsman, B., Napierala,
M., and T. Morin, "Service Chaining using Virtual Networks
with BGP VPNs", draft-ietf-bess-service-chaining-03 (work
in progress), July 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC7611] Uttaro, J., Mohapatra, P., Smith, D., Raszuk, R., and J.
Scudder, "BGP ACCEPT_OWN Community Attribute", RFC 7611,
DOI 10.17487/RFC7611, August 2015,
<https://www.rfc-editor.org/info/rfc7611>.
Grewal, et al. Expires April 22, 2018 [Page 6]
Internet-Draft bgp-accept-own-nhop October 2017
Authors' Addresses
Ashutosh Grewal
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
EMail: agrewal@juniper.net
Nischal Sheth
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
EMail: nsheth@juniper.net
Kaliraj Vairavakkalai
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
EMail: kaliraj@juniper.net
Grewal, et al. Expires April 22, 2018 [Page 7]
