Re: MPLS patches

[Mihai Chelaru <kefren%netbsd.org@localhost>]

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