"Pedro A. Aranda Gutiérrez" writes: > > 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. > > > Yes, but here I'd rather have a clear API creating the LSP's on one side > and a daemon running RSVP on the other. The daemon handles the > PATH and RESV message and uses the API to create the LSPs. This way > we can piggyback different protocols (OSPF-TE, CR-LDP) and in a modular > way à la Quagga/Zebra
Yep; that (having a good programming interface) makes a lot of sense to me. I don't think that dladm is necessarily that interface, but something is needed. The more interesting part (to me at least) is how to get RSVP-TE working. It needs to have its fingers in very deep inside OSPF (to get the SPF tree that OSPF normally discards), but also has some serious design issues on its own (handling many thousands of timers efficiently is not trivial). > > 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. > > > > > OK, that's the other way to proceed. Maybe my view is biased by (more or > less) > immediate project needs ;-) ;-} It sounds like we're essentially saying the same things. I guess the next step is writing up a proposal. I'll send one to opensolaris-discuss and see what happens. -- 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]
