In addition to the Interface-ful and interoperable Interface-less models described in the previous sections, SR OS also supports Interface-less Model (EVPN IFL) with IP encapsulation for MPLS tunnels. In the standard specification - draft-ietf-bess-evpn-ip-prefix - this refers to the EVPN IFL model for IP NVO tunnels.
Compared to the Ethernet NVO option, the ingress PE no longer pushes an inner Ethernet header, but the IP packet is directly encapsulated with an EVPN service label and the transport labels.
Figure 1 illustrates the Interface-less Model (EVPN IFL) with IP encapsulation for MPLS tunnels.
EVPN IFL uses EVPN IP Prefix routes to exchange prefixes between PEs without the need for an R-VPLS service, termed Supplementary Broadcast Domain (SBD) in the standards, and any destination MAC lookup. The data path used in EVPN IFL is the same as that is used for IP-VPN services in the VPRN.
In the example of Figure 1:
PE2 advertises IP Prefix 20.0/24 (shorthand for 20.0.0.0/24) in an EVPN IP Prefix route that does not contain a Router's MAC extended community anymore. As usual, and depicted in step 1, arriving frames with IP destination of 20.0.0.1 on PE1's R-VPLS-1 are processed for a route lookup on VPRN-1.
However, in step 2 and as opposed to the previous models, the lookup yields a route-table entry that does not point at an SBD R-VPLS, but rather to an MPLS tunnel terminated on PE2. PE1 then pushes the EVPN service label that was received on the IP Prefix route at the top of the IP packet, and the packet is sent on the wire without any inner Ethernet header.
On step 3, the MPLS tunnel is terminated on PE2 and the EVPN label identifies the VPRN-1 service for a route lookup.
Step 4 corresponds to the regular R-VPLS forwarding that happens in the other EVPN L3 models.
A new vprn>bgp-evpn>mpls context has been added to configure a VPRN service for EVPN IFL. This context is like the one existing in VPLS and Epipe services and enables the use of EVPN IFL in the VPRN service. When configured, no R-VPLS with evpn-tunnel should be added to the VPRN, that is, no SBD is configured. As an example, in Figure 1 PE1 and PE2 VPRN-1 service are configured as follows:
[ex:configure service vprn "vprn-1"]
A:admin@PE1# info
admin-state enable
ecmp 2
bgp-evpn {
mpls 1 {
admin-state enable
route-distinguisher "192.0.2.1:12"
vrf-target {
community "target:64500:2"
}
auto-bind-tunnel {
resolution any
}
}
}
interface "irb-1" {
ipv4 {
primary {
address 10.0.0.254
prefix-length 24
}
}
vpls "r-vpls-1" {
}
}
[ex:configure service vprn "vprn-1"]
A:admin@PE2# info
admin-state enable
ecmp 2
bgp-evpn {
mpls 1 {
admin-state enable
route-distinguisher "192.0.2.2:21"
vrf-target {
community "target:64500:2"
}
auto-bind-tunnel {
resolution any
}
}
}
interface "irb-2" {
ipv4 {
primary {
address 20.0.0.254
prefix-length 24
}
}
vpls "r-vpls-1" {
}
}