Learning EVPN? Don't skip Route Type 3

In this post

📚 The trouble with learning RT-3s.
🎥 EVPN-VXLAN Explainer 3 is finally out!

👹 An odd choice?

After many hours of writing, recording, re-recording, and rewriting; I was finally able to release the third video in my EVPN-VXLAN Explainer series (link below). This video deals with one of the aspects of EVPN that took me a while to grasp, but is fundamental to unlocking this protocol; that being Route Type 3.
After my initial decision to tackle RT-3 as the first Route Type that I cover for this series, I started to wonder whether this may seem like an odd choice. RT-2 being the update that most are interested in, thats your actual host update.
However, the more I progressed with the video writing process, the more natural it felt to tackle RT-3s first.
After all, this is the first update that you'll see in the EVPN table or your wireshark capture, with or without end hosts.
RT-3s are fundamental to the operation of EVPN networks, no Route Type 3s, no flooding; and without that, IP networks do not run so well.
But as fundamental as RT-3s are, they do seem to be a little over-looked in EVPN tutorials, or rather, not exactly tackled to any sufficient level in the content I was consuming when first learning EVPN.

😳 The trouble with learning RT-3s

First up, that name; Inclusive Multicast Ethernet Tag route - while that covers the function of the route type, it did throw me off initially because I had mentally consigned multicast to the 'low priority' queue of my learning. This resulted in a 'skip it' approach, which proved to be absolutely the wrong thing to do.
Moreover, those RFCs. Never the easiest way to learn, the RFCs that cover EVPN can be something of a challenge. Rather than a general moan, I'll attempt to provide specific examples, and the trouble starts right from the off with Section 7.3 of RFC 7432, which introduces RT-3s.
The problem I have with this section is that it gives a route layout, but without any real explanation of its use. The text just directs us to Section 11, 12 and 16 to find out more.
Ultimately, the information is all there, but it does leave me questioning why there is no summary of the information covered in those various sections. Something, at least, to point the novice on the right path before having them skip off to three different destinations E.G. RT-3's - they are needed for BUM traffic!

😓 Why is it so hard?

However, this requirement to chase down information is something of a theme with EVPN in general, and RT-3s specifically.
Admittedly, the nature of the technology comes into play, EVPN being a development of BGP and VPLS, there are RFCs upon RFCs that led to this protocol. A certain amount of prior knowledge of networking over the last few decades is required to grasp the basics of EVPN. Nothing unreasonable there.
However, my feeling is we, as a collective group of networkers, have not done a very good job of acknowledging and highlighting this. Hence my attempts here and with my video series. I also spoke about why learning EVPN is so difficult in a ten minute talk, which I later recorded.

🐰 Down the rabbit hole

As a specific example, I definitely felt like I was going down a networking rabbit hole in pursue of one piece of data in the RT-3 packet, that being the PMSI.
The Provider Multicast Service Interface, essentially just a value to indicate the type of tunnel in play, with Aruba's version of EVPN-VXLAN, this is always going to be ingress replication.
Hunting information about the, initally, elusive PMSI is indicative of the trials awaiting the knowledge hungry EVPN novice.
Here's the gist of it:

• RFC 7432 Section 7.3 points to Section 11, Handling of Multi-destination Traffic, as one of the three 'find out more' destinations.

• Section 11.2 casually drops in the the IMET must carry a PMSI to identify the P-tunnel, points to RFC 6514 for more info. Side note: The P-tunnel and its use is not actually explained!

• RFC 6514: BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs - the abstract of which is as follows: 'This document describes the BGP encodings and procedures for exchanging the information elements required by Multicast in MPLS/BGP IP VPNs, as specified in RFC 6513.' Which feels decided outside of the confines of pure EVPN pursuits.

• Section 5 of RFC 6514 deals with the PMSI Tunnel Attribute, and includes the table of values:

  + 0 - No tunnel information present
  + 1 - RSVP-TE P2MP LSP
  + 2 - mLDP P2MP LSP
  + 3 - PIM-SSM Tree
  + 4 - PIM-SM Tree
  + 5 - BIDIR-PIM Tree
  + 6 - Ingress Replication
  + 7 - mLDP MP2MP LSP
  
  

Thus, the information is all technically there, but finding this stuff means having the mental fortitude, and confidence, to jump right out of the world of EVPN and enter into the forest of mLDP MP2MP LSP and PIM-SSM trees to find enlightenment.

⏳ The hourglass of content creation

If I think about the EVPN content I've consumed, the image of an hourglass comes to mind.

There's a lot of content at the bottom; paper-thin 'Learn EVPN right now' level stuff, and there is a decent amount at the top; the RFCs & some written content, for example, but there's not so much in the middle. That slim middle section of content that is going to take you from an inexperienced learner to slightly more comfortable with IMET, PMSI, RTs etc.
To some extent, this is the nature of content creation, those making it are either knocking it out to get the views before moving on to the next buzzword, or those living and breathing this stuff. Their material being an extension of their day-to-day discourse, without much scope for slowing down to explain what a P-tunnel is.

🚶 There and back again

Take heart though, I'm doing what I can to service this slim middle and ground, and I went on a paper chase of RFCs, so you don't have to.
The result is this rather lengthy video about Route Type 3s.

I hope you gain something from the video, until next time.

Joe