Please see inline.
> On 2018-Jul-15, at 15:02, James Bensley <jwbens...@gmail.com> wrote: > > On 15 July 2018 at 11:12, <adamv0...@netconsultings.com> wrote: >> @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 > > Thanks Adam. Interesting, I'm in a split mind - It looks helpful in > certain scenarios where HA/FRR is required end-to-end (i.e. CE-PE, > PE-P, P-P, PE-PE etc.). There are still "black spots" in existing FRR > mechanisms however, this feature seems too complex for widespread > deployment to me (i.e. using this for every L3 VPN customer seems too > much additional complexity) [Krzysztof] Complexity is not related to the number of L3VPNs (context-ID can be shared for NLRIs from different L3VPNs), but is releated how regular CEs are connected to PE pairs. If you have say 100 PEs, and CE can connect to any two PEs out of 100 PEs, you have potentially 100*(100-1)/2 = 5k pairs (5k context-IDs), and complicated BGP export policies on PEs to set next-hop to appropriate context-ID depending on the CE connectivity. When PE1 advertised prefixes from CE1, connected to PE1/PE2, CE2 connected to PE1/PE3, CE3 connected to PE1/PE3 … CE100 connected to PE1/PE100 you would need to set the next-hop to different context-ID (ctx-id1 … ctx-id-100) associated with each PE1/PE2…PE1/PE100 pairs. If, on the other hand, you allow CE connectivity to strict pairs only (PE1/PE2, PE3/PE4, …PE99/PE100), no complex policies are needed, since PE1 will advertise prefixes from all locally attached CEs (given the fact, all locally attached CEs are also connected to PE2 exclusively) to the same context-ID (regardless how many L3VPNs are there). So, that is easy. Typically, what I have seen the deployments, the reality is somewhere in between. Most of the CEs are connected to strict pairs, but some times you have exceptions, and some CEs are connected to ‘ad-hoc’ PE pairs. More exceptions you have -> more complex are the policies manipulating next-hop. > but, if like us you provide VoIP to the > emergency services for example, then in those specific cases it seems > it could be a reasonable exception for some added complexity, to fill > in the end-to-end FRR black spots. > > Interesting what you say about Cisco - I'll reach our to our SE during > the week to see if he can shed any light on this. Seeing as only > Juniper seem to support draft-minto and we're mixed C/J network it's a > definite no go without multi-vendor support. Having said that > though… [Krzysztof] This is not entirely true. The draft defines following functions: * Primary PE * Backup PE * PLR * Protector (There is no ‘collector’ function defined in the draft). For the first 3 functions (Primary PE, Backup PE, PLR) no special support is needed -> these functions are supported by Cisco as well. So, in mixed Juniper/Cisco deployments, instead of using distributed model (combined protector/backup PE), you can use centralized model, where you specifically designate couple of routers to act as protectors (these routers must be Juniper routers), and only these protectors inject protector context ID to IGP (while primary connected ID, which can be defined as secondary IP address on loopback interface on Cisco PEs, is injected by primary PE). In such setup, backup PE doesn’t inject any context ID into IGP. So, what happens during primary PE failure is following: * PLR (node directly connected to primary PE) redirect the traffic (by the means of FRR) to protector * once the packet arrives to protector, protector swaps the service label allocated by primary PE to the service label allocated by backup PE * protector sends the packet with translated service label to backup PE So, and the end, the packet arrives to the backup PE, with the service label allocated by backup PE. So, backup PE is not even aware of any tricks done by the protector. Also, another beauty of centralized protector model is, your policies manipulating next-hops are very simply, regardless how the CEs are connected to PEs. > > On 15 July 2018 at 12:55, Krzysztof Szarkowicz <kszarkow...@gmail.com> wrote: >> Hi, >> >> Egress protection was presented at NANOG71: >> >> 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 >> >> Another bing name, who implemented it in the network, was mentioned at NANOG >> (check the preso). They are using it for L3VPN protection. > > Thanks for the info Krzysztof. I will read through the slides during > the week - eating cake and sun bathing right now... > > I was originally refering to > draft-minto-2547-egress-node-fast-protection-03, is > draft-shen-mpls-egress-protection-framework-07 majorly different off > the top of your head? I'll read that draft during the week as well as > your slides and check for my self, looking at the table of contents > though there seems to be clear overlap. [Krzysztof] In the meantime, these drafts migrated to draft-ietf-mpls-egress-protection-framework, so please look just at draft-ietf-mpls-egress-protection-framework. The current version is draft-ietf-mpls-egress-protection-framework-01 (expiring Dec 2018). Also, in my book (MPLS in the SDN Era), there is detailed discussion of egress node protection concepts, including configurations, show outputs, and how to use egress protection in mixed Cisco/Juniper enviornment. > So we have Juniper + France Telecom on draft-minto and Juniper + > Huawei + Orange + RtBrick + T-Systems/DTAG on the drat-shen document, > all using this/these feature(s) on Juniper. So which draft is > implemented in the Juniper.net documents I linked, anyone know? [Krzysztof] Juniper implements draft-ietf-mpls-egress-protection-framework. I am not in the position to comment on what is implemented by other vendors/operators. Deutsche Telekom (DT) is co-authoring the draft-ietf-mpls-egress-protection-framework, and the world-wide first ever deployment of MPLS egress protection for L3VPNs (as mentioned in NANOG71 slide deck) was implemented at DT couple of years ago. It works perfectly since then, giving ~50 ms failover during PE failures. > It makes me feel very confident that opening these features to testing > in our lab wouldn't be a waste of time, all operators are an order of > magnitude larger than us, maybe even two orders. However, without > Cisco support is a no go - we can't have vendor specific technologies > so we definitely need to give Cisco a bump. [Krzysztof] As I mentioned already, you can use ‘centralized’ protector model, where only few protectors must be Juniper. All PEs can be mixed Juniper/Cisco routers. The largest MPLS egress node protection deployment to date uses centralized protector model, if that helps :-). Also, if you want to discuss any confidential issues specific to your particular network design, you can reach me at my Juniper e-mail as well. > > Cheers, > James. > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
