Sebastien Roy writes:
> > Probably not.
> 
> It shouldn't be modeled as a data-link, or dladm wouldn't be the right 
> tool to manipulate MPLS tunnels?

Possibly both, I think.  Actually, I'm not quite sure how MPLS would
map into the dladm world.

With MPLS, you can have multiple tunnel-like objects, but what they
represent is dependent on how they're used.

If you're building a VPN out of MPLS tunnels (a possible application),
then the tunnel endpoints do look to IP like links, just like IP-IP
tunnels or VLANs, and thus the representation in dladm is pretty
obvious.

If you're doing TE [Traffic Engineering], things are murkier.  An MPLS
tunnel could have a FEC [Forwarding Equivalency Class] attached that
says (in effect) "when going to 1.2.3.4 and with DSCP 14 [AF13], push
two labels {10,20} and send to L2 address 4:5:6:7:8:9".  That doesn't
look at all like a link to me.  Nor would it be managed as one.

In some ways, MPLS behaves as a network-layer-ish thing.  It sits atop
all the 802 stuff as its own Ethertype (if you have VLANs, each VLAN
can run MPLS independently), and is in parallel with IP.  (In fact,
you typically need to have IPv4 plumbed on the same link so that you
can run at least LDP.)

(Aside: MPLS has a zillion and one deployment scenarios.  LDP, run
over TCP, is how labels are supposed to be managed between peers on a
network.  CR-LDP and RSVP-TE are two TE extensions that can be used to
signal up and down labels along a path -- an LSP [Label Switched Path]
-- between two nodes in a larger internet.  CR-LDP runs on TCP and is
more [to me] ATM-ish, while RSVP runs on raw IP and is a little more
Internet-ish.  Those in turn can be driven by offline TE computations,
BGP next-hop resolution, and VPN configuration, as well as modified by
complex policy rules.)

So, at a guess, I think that LSPs with intentionally VPN-like
behaviors should map into links in dladm, but that MPLS itself should
not necessarily map every LSP or label allocation into dladm.

> > In order to be reasonably functional, there needs to be
> > some way to control an inbound label map, LSP mappings, and label
> > actions.
> 
> If MPLS tunnels are a kind of data-link, and if there could be a way for 
> dladm to interface with a more complex set of configuration for a type 
> of data-link, then would this set of requirements still preclude the 
> data-link aspects of MPLS tunnels from being manipulated using dladm?

As long as the LSP space is split between link-like uses and non-link-
like uses, I think it's fine for dladm to manage the link-like ones.

> > It definitely doesn't look very much like "regular" VLANs or IP-IP
> > tunnels at the lower levels.
> > 
> > I've actually put some thought into this off-and-on (because I wrote
> > an MPLS implementation in a former life).  Perhaps this should be a
> > new Open Solaris project under networking.
> 
> Sounds good to me.  While we're at it, we might as well create a GRE 
> project. :-)

Not really related ... but sure!

-- 
James Carlson, KISS Network                    <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to