Re: [mpls-linux-devel] DaveM - mpls_nhlfe_hash_code()

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

Comments in line

On Fri, Feb 20, 2004 at 08:20:17AM +0100, Ramon Casellas wrote:
> On Fri, 20 Feb 2004, James R. Leu wrote:
> 
> 
> 
> > That and we should never build the hash based on the label to begin with.
> > This all goes back whether or not the label for a out-segment can change.
> 
> I see. So the lookup basically reduces to the nhlfeid itself, which to me
> seems fine.
> 
> 
> > Labelspace has no meaning when talking about NHLFE or out-segments.
> > Labelspaces are meant to help the LSR manage the labels it advertises,
> > in otherwords its ILM or in-segments.
> 
> Agreed. We did not use labelspaces for moi objects.
> 
> 
> 
> >
> > I think nhlfeids should be globally unique.
> 
> Agreed.
> 
> 
> > That is fine if every out-segment is responsible for sending
> > the PDU (ie needs the oif and neighbour), but if you build hiearchy via
> > indirection, then there are out-segments which do not actually send the PDU,
> > they just hand it off to another out-segment to continue processing, thus
> > they do not need a oif or neighbour.
> 
> Well, I agree :) (I have been working with you before ;)) but what would
> you suggest to do? Jamal? comments? I think I should start gathering a
> list of potential changes + arguments, so we can later justify them to the
> original author of the code... Otherwise, I wont be able to remember why
> we change this or that

I think that is a fine idea.  Lets only change what we absolutly
have to, but note why other more significant changes should be made.

> 
> 
> >
> > >
> > > Another question: why is the struct postfixed with _route? what's the
> > > point of calling it mpls_nhlfe_route and not plain mpls_nhlfe?
> >
> > It is a side effect of an MPLS implementation that used IPv4 as a roadmap.
> 
> Ok, can be easily fixed :P

True
s/mpls_nhlfe_route/mpls_out_info^H^H^H^H^H^H^H^nhlfe/
;-)

> R.

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