Re: MPLS patches

[David Young <dyoung%pobox.com@localhost>]

On Fri, Jan 04, 2008 at 01:42:19PM +0200, Mihai Chelaru wrote:
> David Young wrote:
> >MPLS decap/encap appears to be intricately entwined with ether_output,
> >ip_output, ip_input, et cetera.  That doesn't seem right.  Instead, I
> >think that there should be a pseudo-interface, mpls0, whose input/output
> >routines do decap/encap, respectively.  This de-clutters the IPv4/IPv6
> >stacks and the ethernet code, and it provides a location for tapping
> >packets with tcpdump before encapsulation and after decapsulation.
> >
> 
> Hi,
> 
> I had an idea at one moment to create an pseudo-interface for every 
> neighbor and route packets through those pseudo-interfaces. Also one 
> single interface was a pre-option. But I don't think this will be very 
> intuitive and I didn't see any vendor reporting something similar to 
> this so I assume no one does it.

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 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.

> 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?

> Btw, tcpdump decapsulates the MPLS frames and reports the inner IP 
> packets generating an output like this:
> 
> 13:32:20.880484 MPLS (label 20, exp 0, [S], ttl 64)
>         IP (tos 0x0, ttl 64, id 17838, offset 0, flags [none], proto 
> UDP (17), length 71) 193.28.151.120.50013 > 193.28.151.5.53: [udp sum 
> ok] 29453+ PTR? 2.116.208.68.in-addr.arpa. (43)
> 
> Are you interested in catching IP packets before shim push/pop for some 
> other reasons ?

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.)

> >There are several fragments of code like this,
> >
> >        if (m->m_len < sizeof (struct ip) &&
> >            (m = m_pullup(m, sizeof(struct ip))) == NULL)
> >                return ENOBUFS;
> >
> >that should be written like this,
> >
> >        if (M_UNWRITABLE(m, sizeof(struct ip)) &&
> >            (m = m_pullup(m, sizeof(struct ip))) == NULL)
> >                return ENOBUFS;
> >
> >instead.
> 
> I'm not sure about that. True, I should check M_READONLY but in a 
> mandatory way where I actually want to write data into that mbuf. But 
> should I check if it's readonly for cases like the m_push_inet{6}() 
> where I prepend and modify only the prepended data ?

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.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24