David Young wrote:
Last night, I scanned the web for MPLS configuration examples, and all that I found was Cisco IOS, which was not very compelling, and a discussion on an OpenSolaris forum which, albeit vague, did mention an MPLS pseudo-interface, <https://www.opensolaris.org/jive/thread.jspa?messageID=33315>.
I don't think this project got anywhere near design finishing. I did also read the rest of the threads in that category.
I don't think that the word "intuitive" really applies to MPLS, and it is a vague word that deserves to be defined in any discussion, <http://www.asktog.com/papers/raskinintuit.html>. I think that it will be helpful if MPLS uses familiar abstractions in familiar ways; using a pseudo-interface to add/subtract encapsulation is familiar to users of VLANs and tunnels.
Hehe, nice lecture, still I don't think that Picard(or was it Data ?) or a lady that didn't know how to handle the mouse is an appropiate example in this case. Anyhow, I'll try to explain below in detail why using encap/decap interface(s) is not something I'd like.
Also this raises another problem: I could do this if NetBSD would have a clear difference between control and forwarding but this is not the case and I don't want to change the ifa/p for a route without a very strong reason.
You seem to have a precise meaning in mind, but what you have written is vague. Can you elaborate on this lack of control/forwarding separation as it applies to ifa/ifp and MPLS?
Because you want to use an interface [X] that will be seen from control plane, I quickly see some problems:
- No control coming from interface regarding encapsulation (think about cell-mode) - if one set a route to point to an interface:next-hop pair, he expects that to be honored. This will not be the case with these interfaces (route interface will be changed to mplsX) - double lookup on non-MPLS encapsulation: in order to have a reason for MPLS PI to exist we need to route-lookup once for INET in order to deliver that packet to MPLS PI, and once in MPLS PI code in order to know how and where should I deliver the frame from MPLS point of view. - I'll end up keeping a mirror of all routing tables where I should keep the PROTO->MPLS associations (remember, we need to separate PROTO from MPLS in PROTO routing table in order to keep reason for MPLS pseudo-interface existence, where PROTO may be INET or something else). So, mpls_interface will get a packet, together with it's adress family and relookup in that address family mirror table to see how it should be encapsulated.
- double lookup for MPLS encapsulated packets that we receive.
- shim-pop-pushed instead of MPLS swapping. Fast label swapping is
considered one of the MPLS advantages. Also RFC3031 explicitly calls the
forwarding mechanism "Label Swapping"
- loss of forwarding speed
- it will not simplify the code in ether_output() because we still need
to handle AF_MPLS frames there
[X] - How many pseudo-interfaces do you want anyway ? These are the options as they come to my mind right now: - only one used for both decap and encap. decap if packet is not tagged, encap else. Still this is no good solution if you want to tap because you'll see here both in and out. Also you'll really have no idea where that packet comes from and where it goes and you'll have packets coming from mpls0 and going out to mpls0. - one pseudo-interface per non-pseudo-interface. This seems more appropiate as we may know where that packet comes and where it goes. Also, I think I can live with information passed via tags between pseudo-interfaces and real-interfaces. But this case raises another question: if we do it for MPLS why don't we do it for every ethernet protocol ? Since when an interface should be used only for carrying IP only frames ?
- one decap interface and one pseudo-interface per neighbour
- one pseudo-interface per non-pseudo-interface and one PI per neighbour
Personally I don't like the latter two, because I don't want to pollute
interface space with one iface per neighbour. Think how it will be to
create an interface per OSPF neighbour for example. Also, their
management will be almost impossible and I don't think that ldp daemon
should mix with this interface management(including but not restricted
to creating/destroying). For all the cases, someone that worked with
MPLS on Cisco or Junipers for example, will not feel "familiar" with
these pseudo-interfaces.
Yes, I am. I also believe it makes the system a lot more transparent and comprehensible to use a pseudo-interface. We have the opportunity to apply a packet filter or to tap packets. Tapping packets is an essential aid for troubleshooting. (IMO, a deficiency of IPSec in NetBSD is that it does not use pseudo-interfaces, even when it does tunnel-like things like IPSEC_NAT_T.)
Note that MPLS is not encrypting packets and tcpdump prints the inner packets for common cases, so payload tapping is still possible.
But there is another problem: you asked for this pseduo-interface(s) because you expect to tap packets on it(them). But you can't really know what you will tap because MPLS shim doesn't contain information regarding the inner protocol. Tcpdump may only guess here after a protocol analysis but there are a lot of non-IP[6] things that can live inside an MPLS frame.
No, you don't need to use it if you will only read the data. I suggest extracting a const pointer to the data with mtod, then
I'll constify where is the case. -- Thanks, Mihai