BGP Signaling of
IPv6-Segment-Routing-based VPN NetworksCisco SystemsUSAgdawra@cisco.comCisco SystemsBelgiumcfilsfil@cisco.comCisco SystemsCanadaddukes@cisco.comCisco SystemsCanadapbrisset@cisco.comCisco SystemsSpainpcamaril@cisco.comComcastUSAjohn_leddy@cable.comcast.comBell CanadaCanadadaniel.voyer@bell.caBell CanadaCanadadaniel.bernier@bell.caSteinberg ConsultingGermanydws@steinberg.netBloomberg LPUSArobert@raszuk.netOrangeFrancebruno.decraene@orange.comSoftBankJapansatoru.matsushima@g.softbank.co.jp
General
Inter-Domain RoutingBRP SRv6 VPNInternet-DraftThis draft defines procedures and messages for BGP SRv6-based EVPNs
and L3 VPNs. It builds on RFC7432 “BGP MPLS-Based Ethernet VPN” and
RFC4364 “BGP/MPLS IP Virtual Private Networks (VPNs)” to provide a
migration path from MPLS-based VPNs to SRv6 based VPNs.SRv6 refers to Segment Routing instantiated on the IPv6 dataplane
.SRv6-based VPN (SRv6-VPN) refers to the creation of VPN between PE’s
leveraging the SRv6 dataplane and more specifically the END.DT*
(crossconnect to a VRF) and END.DX* (crossconnect to a nexthop)
functions defined in the SRv6 network programming document . SRv6-L3VPN
refers to the creation of Layer3 VPN service between PE’s supporting an
SRv6 data plane.SRv6 SID refers to a SRv6 Segment Identifier as defined in .SRv6-VPN SID refers to an SRv6 SID that MAY be associated with one of
the END.DT or END.DX functions as defined in .To provide SRv6-VPN service with best-effort connectivity, the egress
PE signals an SRv6-VPN SID with the VPN route. The ingress PE
encapsulates the VPN packet in an outer IPv6 header where the
destination address is the SRv6-VPN SID provided by the egress PE. The
underlay between the PE’s only need to support plain IPv6 forwarding
.To provide SRv6-VPN service in conjunction with an underlay SLA from
the ingress PE to the egress PE, the egress PE colors the VPN route with
a color extended community. The ingress PE encapsulates the VPN packet
in an outer IPv6 header with an SRH that contains the SR policy
associated with the related SLA followed by the SRv6-VPN SID associated
with the route. The underlay nodes whose SRv6 SID’s are part of the SRH
must support SRv6 data plane.BGP is used to advertise the reachability of prefixes in a particular
VPN from an egress Provider Edge (egress-PE) to ingress Provider Edge
(ingress-PE) nodes.This document describes how existing BGP messages between PEs may
carry SRv6 Segment IDs (SIDs) as the means to interconnect PEs and form
VPNs.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 .BGP egress nodes (egress-PEs) advertise a set of reachable prefixes.
Standard BGP update propagation schemes , which
MAY make use of route reflectors , are used to
propagate these prefixes. BGP ingress nodes (ingress-PE) receive these
advertisements and may add the prefix to the RIB in an appropriate
VRF.For PEs supporting SRv6 the egress-PE advertises an SRv6-VPN SID with
VPN routes. This SRv6-VPN SID only has local significance at the
egress-PE where it is allocated or configured on a per-CE or per-VRF
basis. In practice the SID encodes a cross-connect to a specific Address
Family table (END.DT) or next-hop/interface (END.DX) as defined in the
SRv6 Network Programming Document The SRv6 VPN SID MAY be routable within the AS of the egress-PE and
serves the dual purpose of providing reachability between ingress-PE and
egress-PE while also encoding the VPN identifier.For each NLRI, the egress-PE includes a new optional, transitive BGP
SRv6-VPN SID Path TLV as part of the BGP Prefix-SID Attribute. It contains a list of SIDs, for
L3VPN only a single SRv6-VPN SID is necessary. See Section 3.1 below for
details on the SRv6-VPN SID TLV.At an ingress-PE, BGP installs the advertised prefix in the correct
RIB table, recursive via an SR Policy leveraging the received SRv6-VPN
SID.Assuming best-effort connectivity to the egress PE, the SR policy has
a single path with a single SID list made of a single SID: the SRv6-VPN
SID received with the related route.When the VPN route is colored with an extended color community C and
the SID is next-hop N and the ingress PE has a valid SRv6 Policy (N, C)
associated with SID list <S1,S2, S3> then the SR Policy
is <S1, S2, S3, SRv6-VPN SID>.Multiple VPN routes MAY recurse on the same SR Policy.The SRv6-VPN SID TLV is defined as another TLV for BGP-Prefix-SID
Attribute . The value
field of the BGP Prefix SID attribute is defined here to be a set of
elements encoded as "Type/Length/Value" (i.e., a set of TLVs). Type
for SRv6-VPN SID TLV is defined to be TBD.The IPv6-SID TLV MUST be present in the Prefix-SID attribute
attached to MP-BGP VPN NLRI defined in when egress-PE is capable
of SRv6 data-plane. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRv6 SID information(Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SRv6 SID information is encoded as follows:
+---------------------------------------+
| SID Type (1 Octet) |
+---------------------------------------+
| SRv6 SID (16 octet) |
+---------------------------------------+
Where: Type is TBDLength: 16bit field. The total length of the value portion of
the TLV.RESERVED: 8 bit field. SHOULD be 0 on transmission and MUST be
ignored on reception.Current Type of SID defined as: Type-1 - corresponds to the equivalent functionality provided
by an VPN MPLS Label attribute when received with a route
containing a MPLS label.IPv4 VPN Over IPv6 Core is defined in , the
MP_REACH_NLRI is encoded as follows for an SRv6 Core: AFI = 1SAFI = 128Length of Next Hop Network Address = 16 (or 32)Network Address of Next Hop = IPv6 address of the egress PENLRI = IPv4-VPN routesLabel = Implicit-NullSRv6-VPN SID are encoded as part of the SRv6-VPN SID TLV defined in
. The function of the SRv6 SID is entirely up
to the originator of the advertisement. In practice the function would
likely be End.DX4 or End.DT4.IPv6 VPN over IPv6 Core is defined in , the
MP_REACH_NLRI is enclosed as follows for an SRv6 Core: AFI = 2SAFI = 128Length of Next Hop Network Address = 16 (or 32)Network Address of Next Hop = IPv6 address of the egress PENLRI = IPv6-VPN routesLabel = Implicit-NullSRv6-VPN SID are encoded as part of the SRv6-VPN SID TLV defined in
. The function of the IPv6 SRv6 SID is entirely
up to the originator of the advertisement. In practice the function
would likely be End.DX6 or End.DT6.Migration from IPv4 MPLS based underlay to an SRv6 underlay with BGP
speakers is achieved with BGP sessions per BGP instance, one for IPv4
and a one for IPv6. Migration from IPv4 to IPv6 is independent of SRv6
BGP endpoints, and the selection of which route to use (received via the
IPv4 or IPv6 session) is a local configurable decision of the
ingress-PE, and is outside the scope of this document.Migration from IPv6 MPLS based underlay to an SRv6 underlay with BGP
speakers is achieved with a few simple rules at each BGP speaker.
At Egress-PE
If BGP offers an SRv6-VPN service
Then BGP allocates an SRv6-VPN SID for the VPN service
and adds the BGP SRv6-VPN SID TLV while advertising VPN prefixes.
If BGP offers an MPLS VPN service
Then BGP allocates an MPLS Label for the VPN service and
use it in NLRI as normal for MPLS L3 VPNs.
At Ingress-PE
*Selection of which encapsulation below (SRv6-VPN or MPLS-VPN) is
defined by local BGP policy
If BGP supports SRv6-VPN service, and
receives a BGP SRv6-VPN SID Attribute with an SRv6 SID
Then BGP programs the destination prefix in RIB recursive via
the related SR Policy.
If BGP supports MPLS VPN service, and
the MPLS Label is not Implicit-Null
Then the MPLS label is used as a VPN label and inserted with the
prefix into RIB via the BGP Nexthop.
The EVPN SRv6 solution is actively under definition and will be added
in a later revision.When a BGP Speaker receives a BGP Update message containing a
malformed SRv6-VPN SID TLV, it MUST ignore the received BGP attributes
and not pass it to other BGP peers. This is equivalent to the -attribute
discard- action specified in . When discarding
an attribute, a BGP speaker MAY log an error for further analysis.This memo includes no request to IANA.This document introduces no new security considerations beyond those
already specified in and .This document proposes extensions to the BGP to allow advertising
certain attributes and functionalities related to SRv6.Bart Peirens
Proximus
Belgium
Email: bart.peirens@proximus.com