Pedro A. Aranda writes: > I don't know, since I'm quite new to the inner world of OpenSolaris. But from > my (perhaps) naïve point of view, I see two situations. > > 1) Label Edge Routers: it's were the 'tunnels' are created. > Here is where we have to know _what_ we want the FEC to > mean, i.e. we have to trigger processes for traffic enginnering > related stuff here. > When you want to transport IP packets on top of LSP, I really see a > possibility of triggering the process via dladm. I have to confess that I > have no clue as to what one should do if we wanted to transport > Ethernet frames over it.
I think you'd likely be bridging in that case, and these would still look like links to dladm. That doesn't seem special. The special case is when you're using MPLS for TE. The FEC in this case selects both destination *and* class of traffic. That doesn't really look like any kind of "interface" to me, so representing it as a tunnel in dladm seems wrong. I suppose I could see other solutions here. If the system were redesigned so that interfaces could have duplicate addresses and overlapping subnets that differ only in traffic class, then representing LSPs as tunnels all the time would make sense. That seems to me to be a much more radical change than just allowing special FECs to "cherry pick" some traffic to follow a special path. > 2) Label Switch Routers: this is the point were all the magic of pushing, > popping > etc. is done without necessarily knowing what that should be good for and > what traffic > over the LSP is being transported. They have to run the TE and non-TE routing > protocols. LERs must know how to push and pop as well. They're just not doing any push-AND-pop (swap) action between LSPs. LERs also have to participate in TE behavior, depending on exactly what the deployment is doing with MPLS. In particular, if you're using RSVP-TE, the LER is the one who starts the PATH message. > I really see two different projects here. And if I have to decide what should > be started > first, then I would go for the Label Edge Router first, making sure it > interworks with > commercial LSR platforms and only afterwards would go for the Label Switch > Router > project. I'd suggest otherwise. I think it's far too easy to design an LER-only implementation that doesn't extend well to produce an LSR. I'd rather start with a core design for MPLS (plumbing, ILM, label handling) and produce something on top of that (perhaps LER-only at first), than to design something specifically for the edge case. -- 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]
