Re: [mpls-linux-devel] More comments on Jamal's spec

[James R. L. <jl...@mi...>]

Comments in line.

On Mon, Feb 16, 2004 at 06:47:27PM +0100, Ramon Casellas wrote:
> On 16 Feb 2004, Jamal Hadi Salim wrote:
> 
> > On Sun, 2004-02-15 at 05:36, Ramon Casellas wrote:
> 
> 
> > Some comments:
> 
> Ok. I'll do it asap.
> 
> (nhlfeid ;) so when we prefix it there is just one underscore... agreed?
> :)
> 
> 
> 
> 
> >
> > What would be useful in this document as well is to describe the
> > interface between the kernel and user space. i.e describe the packets
> 
> Agreed. I'll take care of this.
> 
> 
> 
> 
> > For how we document this typically look at:
> > http://www.faqs.org/rfcs/rfc3549.html

:-)  Nice example :-)

> 
> ok.
> 
> 
> 
> 
> 
> 
> > Ok. So we may need some extra speacilized NHLFE entries. I am not a big
> > fan of the two step process unless you guys really insist - then we can
> > go and convince davem.
> 
> 
> Well, the problem with CR-LDP and/or RSVP is that it is a 'ping-pong' set
> up process, and you usually need to define a 'prestate'. Another
> possibility is to consider RSVP as using the unsollicited downstream
> label distribution and only process the RSVP-RESV message from control
> space (when the message comes up from your downstream router), I am not
> sure about this though.

The state that is being stores is only in the control plane, not the
forwarding plan.  The real reason you want to be able to modify
existing entries of for the fail-over cases.  This is also a reason why
a clean layer of indirection is required.  Imaging 1000's of VC or VPN
labels associated with one tunnel label. Now imagine that tunnel label
changing (fast re-route, primary/backup tunnel, etc).  In our
implementation VC and VPN are out-label which have have a FWD instruction
which all point to the same out-label. The out-label contains a PUSH
instructions.  By changing just one PUSH instruction you in essence fail over
to another tunnel label.

> 
> 
> > My opinion is lets have 3 new speacial NHLFEs:
> 
> > - something that sends the packet to a blackhole which will work for
> > such a scenarion as above.
> 
> A 'disabled' NHLFE. I think that this can be useful, for example for
> liberal retention mode.

Not needed.  Just because the signaling protocol is holding label
state does not mean it must be installed in the forwardin plane.  Only
active segments and cross connects should be installed.

> > - Another one will send the packet to user space via netlink. This may
> > also be used for resolving what you have above.
> 
> So we can conform to the RFC (although sometimes it is just IETF jargon)
> But the question is 'which packet?' I assume that it is the first packet
> that according to the FIB_RES should be mapped to a NHLFEid that just does
> not exist. Don't we risk flooding userspace? Should it be only the first
> packet? what a bout a single netlink event (in plain english: hey, I don't
> know what to do with this FEC, can you do something about it?)

Why would you want to do this?  Are you trying to enable flow based
label allocation?  Eveyone has decided this is a bad idea (example NHRP).
I could see needing to support MPLS sockets, where the sock addr is a in
or out segment (or both) and all packets rx'd on the in segment
goto the socket or all data written to the socket get tx'd on the
out-segment.

> > - A third one is for locally destined packets. I was not sure whether
> > this should just be a flag which says neighbor = local or not.

The correct way it to utilize the same instruction for pop/lookup
and pop/rx locally.  That way tunnel in segments do not need to
change when VC or VPN labels are associated with them.  Plus it is
not always a clear case of always being stacked or not.

> IIRC, locally destined packets means that the LSR is egress (for all
> hierarchical levels) and pops the last packet. As one possibility, the
> default action should be just call IP module packet reception if we just
> popped the last label, so the packet is locally delivered or forwarded per
> dest address.

The lowest level label cannot dictate that (except for router alert, but
in that case the stack above the RA is sent up as data).  If the lowest
level label say pop, you MUST pop and lookup the next level.  The only time
you can pop-all is in the error cases (and that is even questionable).

> 
> Thanks,
> 
> R.
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> mpls-linux-devel mailing list
> mpl...@li...
> https://lists.sourceforge.net/lists/listinfo/mpls-linux-devel

-- 
James R. Leu
jl...@mi...