[j-nsp] Egress Protection/Service Mirroring

[Krzysztof Szarkowicz]

Hi,

Egress protection was presented at NANOG71:

https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf <https://pc.nanog.org/static/published/meetings/NANOG71/1451/20171004_Szarkowicz_Fast_Egress_Protection_v1.pdf>
https://www.youtube.com/watch?v=MoZn4qq3FcU&index=69&t=0s&list=UUIvcN8QNgRGNW9osYLGsjQQ <https://www.youtube.com/watch?v=MoZn4qq3FcU&index=69&t=0s&list=UUIvcN8QNgRGNW9osYLGsjQQ>

Another bing name, who implemented it in the network, was mentioned at NANOG (check the preso). They are using it for L3VPN protection.

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 example. If you have a lot of exceptions (CEs connected to non-standard PE pairs) the complexity increases, as you need to maintain policies to set different next-hops, depending, if CE is commented to PE1/PE2, or PE1/PE4. Saying that, we are looking to simplify that part.

Adam, if you plan to implement it, you can reach me at my Juniper e-mail with any specific question.

Thanks,
Krzysztof



> On 2018-Jul-15, at 12:12, adamv0025 at netconsultings.com wrote:
> 
> 
>> Of Saku Ytti
>> Sent: Sunday, July 15, 2018 10:32 AM
>> 
>> Hey James,
>> 
>> Thanks, I was not aware of this feature. How does it compare to PIC Edge?
>> Aren't both solving issue of ingress node rapidly choosing different
> egress
>> node from two installed options?
>> 
>> I think we have two secenarios:
>> 
>>               P2---PE2--CE2
>>               |         |
>> CE1 -- PE1 -- P1         |
>>               |         |
>>              P3---PE3---+
>> 
>> * CE1 primarily chooses PE2->CE2
>> 
>> 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
>> 
>> It wasn't obvious to me can this newer mechanism out-perform PIC Edge?
>> 
>> In case b) I think they should be equal, in both cases we don't need to
> wait
>> for network, the PE2 can locally choose to redirect to PE3 until it stops
>> receiving packets.
>> 
>> But I'm not sure if this new mechanism makes a) better, does PE1 still
> need
>> to know about PE2 failure, or can the network itself move traffic to PE3
>> before PE1 knows PE2 has failed? It might, because there is same IP, but
> I'm
>> not sure.
>> 
> 
> Yes with this one you don't need to tune IGP to propagate the info about
> egress node failure all the way to ingress PEs (so the ingress PE can switch
> to alternate path e.g. using PIC "core") (where this info propagation might
> be slowed down significantly in multi-AS environments with BGP-LS between
> AS-es).
> This feature allows the P node directly adjacent to the failed egress PE
> node to initiate the failover to an alternate PE, which as you can see
> significantly reduces the convergence time.
> 
> 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. 
> 
> @James is on my todo list so maybe we can exchange notes, (I plan on using
> it in RSVP-TE environment so the added complexity will be only marginal). 
> Yes I've been waiting for this feature for quite some time in cisco (got
> promises that maybe on SR) -maybe you can dig some of the old threads I had
> with Oliver Boehmer on this
> 
> adam
> 
> netconsultings.com
> ::carrier-class solutions for the telecommunications industry::
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp