[j-nsp] Egress Protection/Service Mirroring

[James Bensley]

On 15 July 2018 at 12:47, Saku Ytti <saku at ytti.fi> wrote:
> On Sun, 15 Jul 2018 at 13:12, <adamv0025 at netconsultings.com> wrote:

Hi Saku, Adam,

>> > a) If P2->PE2 goes down, we have to wait for PE1 to experience it, after
>> PE1
>> > experiences it, it can immediately redirect to PE3
>> > b) If PE2->CE2 goes down, PE2 should  be able to redirect to PE3
>> >
>
>> But this feature solves only egress PE node failure protection (no need for
>> PIC "core" or IGP tuning), that is BGP-PIC Edge is still needed to protect
>> for egress PE-CE link failures.
>
> Are you sure? To me it looks like this feature also fixes PE=>CE,
> because the primary egress PE also knows the backup egress PE, so if
> it gets packet it cannot forward to 'LAN', it should be able to bypass
> the packet to backup egress PE.
> It's not obvious to me how the P can send it to backup egress PE, if P
> cannot reach primary egress PE.

Saku it fixes your scenario A. The PLR (P2 in your topology)
advertises a secondary new loopback IP into the IGP. PE2 also
advertises this same additional loopback IP and sets net-hop-self to
that IP for VPN prefixes. So prefixes are floating around the iBGP
with next-hop of PE2's secondary loopback IP. The same IP is
advertised from PLR/P2 but with a worse IGP metric so VPN traffic is
sent to PE2 as normal.

When PE2 goes down P2 is the first to know (before PE1) and P2 is now
the best source of this additional loopback IP within the IGP. It
beocmes the "collector" (collecting VPN traffic for PE2's secondary
loopback IP). No one knows PE2 is down so VPN traffic heads to P2
because it's originating the same loopback IP ("context ID"). In this
topology P2 would have to have BGP running and receiving prefixes from
PE2 and PE3. P2 then performs a label swap; it swaps the service label
PE1 is using for traffic sent towards PE2's secondary loopback IP, to
the service labels used on the backup "protector" egress PE, PE3, then
forward the traffic towards PE3 (the "protector").

However, P2 is not a great PLR "collector". PE3 in this topology would
be a better PLR/collector because it already runs BGP for VPN
signaling. PE3 could be a joint collector and protector. I think this
is what Krzysztof is getting at, PE2 and PE3 would be good "collector"
and "protector" nodes for each other:

On 15 July 2018 at 12:55, Krzysztof Szarkowicz <kszarkowicz at gmail.com> wrote:
> MPLS egress protection is simple, if you have ‘standardized’ PE pairs. I.e.,
> you have CEs connected to PE1/PE2, CEs connected to PE3/PE4, CEs connected
> to PE5/PE6, and so on, but no CEs connected to PE1/PE4

For your scenario B Saku, that is a separate feature, that is
basically PIC Edge Link Protection / BGP Advertise Best-External - PE3
will never advertise his PE-CE prefixes if he see's better ones via
PE2.

On 15 July 2018 at 11:12,  <adamv0025 at netconsultings.com> wrote:
> But this feature solves only egress PE node failure protection (no need for
> PIC "core" or IGP tuning),

I would slightly disagree with you there mate; In Saku's topology with
PE3 is the collector and protector for PE2 (not P2 to keep the P's BGP
free), and they both advertise the same loopback IP (context ID)
inside the IGP but with PE3 less preferred, so that PE3 can "collect"
the VPN traffic destined for PE2 when PE2 is down, I'd like that
alternate path to PE3 to be pre-installed in my P node FIBs/HW a-la
PIC/FRR.

Cheers,
James.