Post by David YoungLast 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.
Post by David YoungI 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.
Post by David YoungPost by Mihai ChelaruAlso 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.
Post by David YoungYes, 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.
Post by David YoungNo, 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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de