mpls-linux-devel — Mailig list for discussing the development of MPLS on Linux

Re: [mpls-linux-devel] Hi all

[Jamal H. S. <ha...@zn...>]

Hi guys,

didnt mean to desert you - things have been extremely hectic. Still are
(both at work and home). So i hope you wont mind me being intermittent.
I will try my best to respond when i believe its high priority like in
this case.

Scary - It compiles just fine for me.

Substitute that nhl to be nhp - its what it should be.

------
[root@jzny 261-mod]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-conectiva-linux/3.2.2/specs
Configured with: /usr/src/rpm/BUILD/gcc-3.2.2/configure --prefix=/usr
--bindir=/usr/bin --libdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --enable-shared
--enable-threads=posix --enable-haifa --enable-libgcj
--enable-languages=c,c++,f77,objc,java --with-system-zlib
--with-gxx_include_dir=/usr/include/c++/3.2.2
--host=i386-conectiva-linux
Thread model: posix
gcc version 3.2.2
---------

I susbtituted that nhl with nhx and it still compiled.
Now i am thinking that the code is not being hit; so i substitute with:

-----
..
..
#ifdef CONFIG_NET_MPLS
#error  "testing CONFIG_NET_MPLS"
                        //gw = fib_get_attr32(RTNH_DATA(nhx), attrlen,
RTA_MPLS_FEC);
                        //if (gw && gw != nh->nh_mpls_fec)
                        //      return 1;
#end
...
...
----------

and the compile doesnt bail out.
Why did yours work?
Can you replace with the above #error and see if still compiles?

cheers,
jamal

On Mon, 2004-02-23 at 05:25, Ramon Casellas wrote:
> I've started some changes, but the current version does not compile:
> net/ipv4/fib_semantics.c: In function `fib_nh_match':
> net/ipv4/fib_semantics.c:351: error: `nhl' undeclared (first use in this 
> function)
> net/ipv4/fib_semantics.c:351: error: (Each undeclared identifier is 
> reported only once
> net/ipv4/fib_semantics.c:351: error: for each function it appears in.)
> make[2]: *** [net/ipv4/fib_semantics.o] Error 1
> make[1]: *** [net/ipv4] Error 2
> 
> Looks like a trivial fix:
> #ifdef CONFIG_NET_MPLS
>                         gw = fib_get_attr32(RTNH_DATA(nhl), attrlen, 
> RTA_MPLS_FEC);
>                         if (gw && gw != nh->nh_mpls_fec)
>                                 return 1;
> #endif
> 
> but I wonder Jamal, did you compile it before sending the patch ? :)
> 
> regards,
> R.
> 
> 
> 
> // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> // Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...
> // Tel: +33 (0)1 45 81 75 88                 Fax: +33 (0)1 45 81 71 58
> // 37/39 rue Dareau 75014 Paris   --    http://perso.enst.fr/~casellas
> 
> 
> -------------------------------------------------------
> 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

[mpls-linux-devel] Hi all

[Ramon C. <cas...@in...>]

I've started some changes, but the current version does not compile:
net/ipv4/fib_semantics.c: In function `fib_nh_match':
net/ipv4/fib_semantics.c:351: error: `nhl' undeclared (first use in this 
function)
net/ipv4/fib_semantics.c:351: error: (Each undeclared identifier is 
reported only once
net/ipv4/fib_semantics.c:351: error: for each function it appears in.)
make[2]: *** [net/ipv4/fib_semantics.o] Error 1
make[1]: *** [net/ipv4] Error 2

Looks like a trivial fix:
#ifdef CONFIG_NET_MPLS
                        gw = fib_get_attr32(RTNH_DATA(nhl), attrlen, 
RTA_MPLS_FEC);
                        if (gw && gw != nh->nh_mpls_fec)
                                return 1;
#endif

but I wonder Jamal, did you compile it before sending the patch ? :)

regards,
R.



// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Ramon Casellas - GET/ENST/INFRES/RHD/A508 - cas...@in...
// Tel: +33 (0)1 45 81 75 88                 Fax: +33 (0)1 45 81 71 58
// 37/39 rue Dareau 75014 Paris   --    http://perso.enst.fr/~casellas

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...

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

[Ramon C. <cas...@in...>]

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


>
> >
> > 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
R.

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

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

Comments in line

On Fri, Feb 20, 2004 at 07:19:19AM +0100, Ramon Casellas wrote:
> 
> Morning,
> 
> 
> 
> On Thu, 19 Feb 2004, James R. Leu wrote:
> 
> > I see a minor flaw we need to fix in the DaveM code.
> > If I read the code correctly, the hash for the NHLFE is
> > calculated using the out-going label and the out-going ifindex.
> 
> (Unless I'm on crack, the hash is computed using only
> the label) I think you mean actually the list walk, where each list entry
> is compared to the nhlfe_id and the ifindex.
> 
> 
> > If this is the case, then we get an unresolvable collision when 2
> > or more peers off of the same interface allocate the same label
> > (which is perfectly valid).
> 
> Indeed.
> 
> 
> > Either we can add the nexthop address
> > as part of the search criteria (yuck!) or just aknowledge that
> 
> IMHO it is not needed.
> 
> 
> > NHLFE's have a unique index which is not detemined by the contents of
> > it.  The second fits well with the LSR MIB in which the out-segments
> > have an arbitrary unique index.
> 
> Right, I see your point... I always assumed that. (Did I imply the
> contrary on any of my prev emails?)  Unless I'm wrong, for me the nhlfe_id
> is a unique identifier (I called them indexes once ;)) The user is aware
> of the contents of the nhlfe when she sets the mappings, but thats all.
> 
> In summary, if I understand you correcly, code should be:
> 
>         list_for_each_entry(walk, &mpls_nhlfe_hash[hash], mr_hash) {
>                 if (walk->mr_nhlfeid   == nhlfeid)
>                          r = walk;

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.
> 
> and two more things:
> * either the nhlfeids are _globally_ unique (in that case we don't need
> the space argument) or
> * nhlfeids are unique in a given labelspace if ((..) && space ==

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.

I think nhlfeids should be globally unique.

> my vote: the oif should not be used as a key for nhlfe lookup. Moreover...
> the current code (although correct since it is the user that sets that) is
> kinda strange... given that IIRC the rfc states that the neighbour (and
> subsequently the oif) should be obtained from the NHLF table (not be used
> to look it up), and not be IGP constrained. Anyway, I assume it is an
> implementation detail and that it is more convenient to have it in the
> FIB_RES (in out_dev) and that in any case the actual neighbour is held by
> the nhlfe and it is bound using mpls_bind_neighbour.(I liked
> more the idea of having the NH and the oif in the nhlfe itself more
> concretely, in the set opcode)....

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.

> 
> 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.

> 
> 
> 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...

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

[Ramon C. <cas...@in...>]

Morning,



On Thu, 19 Feb 2004, James R. Leu wrote:

> I see a minor flaw we need to fix in the DaveM code.
> If I read the code correctly, the hash for the NHLFE is
> calculated using the out-going label and the out-going ifindex.

(Unless I'm on crack, the hash is computed using only
the label) I think you mean actually the list walk, where each list entry
is compared to the nhlfe_id and the ifindex.


> If this is the case, then we get an unresolvable collision when 2
> or more peers off of the same interface allocate the same label
> (which is perfectly valid).

Indeed.


> Either we can add the nexthop address
> as part of the search criteria (yuck!) or just aknowledge that

IMHO it is not needed.


> NHLFE's have a unique index which is not detemined by the contents of
> it.  The second fits well with the LSR MIB in which the out-segments
> have an arbitrary unique index.

Right, I see your point... I always assumed that. (Did I imply the
contrary on any of my prev emails?)  Unless I'm wrong, for me the nhlfe_id
is a unique identifier (I called them indexes once ;)) The user is aware
of the contents of the nhlfe when she sets the mappings, but thats all.

In summary, if I understand you correcly, code should be:

        list_for_each_entry(walk, &mpls_nhlfe_hash[hash], mr_hash) {
                if (walk->mr_nhlfeid   == nhlfeid)
                         r = walk;

and two more things:
* either the nhlfeids are _globally_ unique (in that case we don't need
the space argument) or
* nhlfeids are unique in a given labelspace if ((..) && space ==

my vote: the oif should not be used as a key for nhlfe lookup. Moreover...
the current code (although correct since it is the user that sets that) is
kinda strange... given that IIRC the rfc states that the neighbour (and
subsequently the oif) should be obtained from the NHLF table (not be used
to look it up), and not be IGP constrained. Anyway, I assume it is an
implementation detail and that it is more convenient to have it in the
FIB_RES (in out_dev) and that in any case the actual neighbour is held by
the nhlfe and it is bound using mpls_bind_neighbour.(I liked
more the idea of having the NH and the oif in the nhlfe itself more
concretely, in the set opcode)....

Another question: why is the struct postfixed with _route? what's the
point of calling it mpls_nhlfe_route and not plain mpls_nhlfe?


Thanks,
R.

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

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

I see a minor flaw we need to fix in the DaveM code.

If I read the code correctly, the hash for the NHLFE is
calculated using the out-going label and the out-going ifindex.
If this is the case, then we get an unresolvable collision when 2
or more peers off of the same interface allocate the same label
(which is perfectly valid).  Either we can add the nexthop address
as part of the search criteria (yuck!) or just aknowledge that
NHLFE's have a unique index which is not detemined by the contents of
it.  The second fits well with the LSR MIB in which the out-segments
have an arbitrary unique index.

What do you guys think?

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

Re: [mpls-linux-devel] interesting article

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

Disclaimer: I'm not a bookreviewer or anything like that so take my impression
with a grain of salt:

It was interesting.  I'm not sure what he was trying to do with the article.
I think he wanted to write about all sorts of cool hardware-techy-stuff,
but found he had to explain too much about how these MPLS services work.
Which he really didn't go into that deep, but he did try and get one main
idea across, all labels above the tunnel label only have meaning to the
indirectly connect devices that exchanged the information.  The result is
that he ran out of room to talk about anything 'cool' :-)
His tables of NHLFE, ILM, FTN are an absolute horror to look at.

On Wed, Feb 18, 2004 at 09:50:29PM -0500, Jamal Hadi Salim wrote:
> Someone pointed this article to me today:
> 
> http://www.commsdesign.com/showArticle.jhtml?articleID=16505029
> 
> Looks like the author knows what he is talking about. Didnt fully read
> it.
> 
> cheers,
> jamal
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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...

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

On Thu, Feb 19, 2004 at 09:26:01AM -0500, Jamal Hadi Salim wrote:
> On Wed, 2004-02-18 at 23:28, James R. Leu wrote:
> [..]
> > > Note, as i described earlier, we should be able to just look at
> > > anything on the packet with the u32 classifier which can be activated
> > > before MPLS ILM is consulted. Also based on the top label we can
> > > do a classification again to peek into further packet data before making 
> > > a decision the next hop.
> > 
> > What do that work for ILM which are just a swap?  It should only be done
> > when needed, otherwise what's the point of the LS in MPLS?
> > 
> 
> I was thinking more of you would use the u32 to detect which flows and
> use flowid to help in in the m-hop.
> We could always do this later in addition to what you are proposing.
> Your proposal is the quickest way to get us there.
> BTW, look at my earlier email (Ramon reached a similar conclusion)
> on the algorithm plugins for selecting the Nhops. If we agree on that
> algorithm plugin, lets have someone raise their hand to implememt.
> If neitehr of you guys raise your hands i can take it.

Since it is a nice modular piece.  Maybe Ramon or you can work on it.
I'll focus on the dst stacking stuff.

> > I'll make the change.  I'll send it to the list for review. I'd just
> > like to note that by ignoring hierachy, we're designing/developing by only
> > looking at about 25% of the requirements.  As I'm sure your familiar with,
> > it usually requires a re-spin to support the other 75% :-)
> 
> Sorry, didnt mean ignore it in the design - unless it overcomplicates
> things immensely. What i meant is when we sell it to Davem (which i dont
> see as a complication given the dst stacking is useful) is not to sell
> the LSP hierachies to start with. But lets see the code then we can make
> the call. Please do factor in the hierachies.

The key for implementing hierachy is indirection and the realization that
not all traffic that arrives on a particular in-segment gets the same actions
applied (this goes back to the idea that the meaning of 'pop' is determined
by which position in the stack it is being applied to).

> 
> cheers,
> jamal
> 
> 
> 
> 
> -------------------------------------------------------
> 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...

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

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

Comments in line

On Thu, Feb 19, 2004 at 09:17:26AM -0500, Jamal Hadi Salim wrote:
> On Wed, 2004-02-18 at 23:14, James R. Leu wrote:
>  
> > > > For how we document this typically look at:
> > > > http://www.faqs.org/rfcs/rfc3549.html
> > 
> > :-)  Nice example :-)
> 
> ;-> We could have written a better draft; maybe a revise of that to
> include the MPLs messages.
> 
> > > 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.
> > 
> 
> But how much execution advantage would you really gain by only changing
> one piece at a time?
> The most expensive thing in updating that table would be
> crossing from user space to kernel. i.e it doesnt matter how much
> data you are sending. Am i off?

I think you missed the point.  A single instruction change would fail the
1000's of VC or VPN labels over to the new tunnel.  Think how you handle a
BPG next hop change when 100K routes are using that same BGP next hop.

> > > 
> > > > - 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.
> 
> Explain the cross-connect part. Is this related to the indirection you
> are refering to?
> Leaving label retention for a second: Is the idea of a blackhole
> neighbor useful?

Signaling protocols running on an LSR needs to keep track of how
in-segments and out-segments are related.  The cross connect is the term
used to refer to that relationship (I'm using terms from the LSR MIB).
Protocols that run in DoD ordered control will not issue an in-segment
until it has recieved an out-segment or has determined it is the egress of
the LSP.  At the time the in-segment is issued the forwarding plan is
installed and the cross connect is made.  So no I do not think a blackhole
is needed, but having it can't hurt.

> 
> > > > - 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.
> 
> I think ability to program this is valuable.
> One good reason could be for debugging or handling exceptions. Of course
> such a feature could be (ab)used like you say for flow based label
> allocation (in which case - bless those who want to use a misfeature).

I think the best way to handle this and RA is via MPLS sockets.  How does
IPv4 handle RA?  Userland has to create a socket which registers for it.
I think the MPLS RA should be handled the same.  How do other L2ish protocols
handle the passing of PDUs to userland.  The only example I can think of is
ATM.  It uses sockets to accomplish this.  I have nothing against using
netlink, but I just think we should use mechanisms that people are use to.

> > > > - 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.
> 
> so a pop/rx locally would be equivalent to remove all labels if theres
> more than one, correct?

You can only pop/rx locally for the label with the BOS.  All others must be
pop lookup. (ofcoures the lookup could say swap, or RA in which case we
are no longer in the 'pop/lookup' loop)

> > > 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).
> 
> So what you are saying is let whoever programmed the instructions shoot
> themselves. i.e they could have specified pop, rx-local, am i correct?

What I'm saying is that the meaning of 'pop' is derived from which
position in the stack it is being applied to.

> 
> BTW, you mention RAs above - which would be considered exceptions. I
> think this is an example of a packet that could be sent via netlink as
> well.
> Note with distributed control where the control plane may be one
> ethernet hop away, this is useful (wrap the RA into a netlink packet and
> shve it onto the control board - at least thats what netlink2 is
> preaching)

See my comments above.

> 
> cheers,
> jamal
> 

In general I have the feeling something isn't clicking.  Am I explaining
these issue well or should backup and approach each one in depth?

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

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

[Jamal H. S. <ha...@zn...>]

On Wed, 2004-02-18 at 23:28, James R. Leu wrote:
[..]
> > Note, as i described earlier, we should be able to just look at
> > anything on the packet with the u32 classifier which can be activated
> > before MPLS ILM is consulted. Also based on the top label we can
> > do a classification again to peek into further packet data before making 
> > a decision the next hop.
> 
> What do that work for ILM which are just a swap?  It should only be done
> when needed, otherwise what's the point of the LS in MPLS?
> 

I was thinking more of you would use the u32 to detect which flows and
use flowid to help in in the m-hop.
We could always do this later in addition to what you are proposing.
Your proposal is the quickest way to get us there.
BTW, look at my earlier email (Ramon reached a similar conclusion)
on the algorithm plugins for selecting the Nhops. If we agree on that
algorithm plugin, lets have someone raise their hand to implememt.
If neitehr of you guys raise your hands i can take it.

> I'll make the change.  I'll send it to the list for review. I'd just
> like to note that by ignoring hierachy, we're designing/developing by only
> looking at about 25% of the requirements.  As I'm sure your familiar with,
> it usually requires a re-spin to support the other 75% :-)

Sorry, didnt mean ignore it in the design - unless it overcomplicates
things immensely. What i meant is when we sell it to Davem (which i dont
see as a complication given the dst stacking is useful) is not to sell
the LSP hierachies to start with. But lets see the code then we can make
the call. Please do factor in the hierachies.

cheers,
jamal

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

[Jamal H. S. <ha...@zn...>]

On Wed, 2004-02-18 at 23:14, James R. Leu wrote:
 
> > > For how we document this typically look at:
> > > http://www.faqs.org/rfcs/rfc3549.html
> 
> :-)  Nice example :-)

;-> We could have written a better draft; maybe a revise of that to
include the MPLs messages.

> > 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.
> 

But how much execution advantage would you really gain by only changing
one piece at a time?
The most expensive thing in updating that table would be
crossing from user space to kernel. i.e it doesnt matter how much
data you are sending. Am i off?

> > 
> > > - 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.

Explain the cross-connect part. Is this related to the indirection you
are refering to?
Leaving label retention for a second: Is the idea of a blackhole
neighbor useful?

> > > - 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.

I think ability to program this is valuable.
One good reason could be for debugging or handling exceptions. Of course
such a feature could be (ab)used like you say for flow based label
allocation (in which case - bless those who want to use a misfeature).

> > > - 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.

so a pop/rx locally would be equivalent to remove all labels if theres
more than one, correct?

> > 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).

So what you are saying is let whoever programmed the instructions shoot
themselves. i.e they could have specified pop, rx-local, am i correct?

BTW, you mention RAs above - which would be considered exceptions. I
think this is an example of a packet that could be sent via netlink as
well.
Note with distributed control where the control plane may be one
ethernet hop away, this is useful (wrap the RA into a netlink packet and
shve it onto the control board - at least thats what netlink2 is
preaching)

cheers,
jamal

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

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

Comments in line

On Sun, Feb 15, 2004 at 08:41:51AM +0100, Ramon Casellas wrote:
> 
> 
> Jamal,
> 
> Glad to know your wife is pregnant. Best wishes :)
> 
> 
> 
> On 14 Feb 2004, Jamal Hadi Salim wrote:
> 
> > IIRC correclty from those old days, there exists some form of LDP
> > implementation. That could be part of the userspace tools or safer
> > separate.
> 
> James,
> 
> How do you see porting LDP portable to this version?

My LDP implementation has an abstraction layer.  It is just a matter
of porting the abstraction layer to the new API.

> 
> 
> 
> 
> > You have access to the patches. What more do you want?
> > OK, Set up a CVS repository. I am old fashioned and dont use it very
> > much. I still refuse to use bitkeeper. The easiest thing for me is
> > people send me patches and i merge them. Again i dont care if its CVS.
> > Maybe we can try something more exciting like that competition to
> > bitkeeper;->
> 
> James,
> 
> What about adding a new kernel version to the p4 repository?
> something like mpls-kernel-dm with the docs and patches, giving
> write access to J.R.L., J.H.S, D.S.M, R.C ? I am working on the spec doc
> and other docs. Later I want to start documenting DaveM with kerneldoc.
> Thoughts?
> 
> 
> 
> 
> 
> > Edit the doc and send an update ;->
> 
> Working on it
> 
> 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...

Re: [mpls-linux-devel] Re: 2.6 Spec: Random comments.

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

Comments in line.

On Mon, Feb 16, 2004 at 09:19:49AM -0500, Jamal Hadi Salim wrote:
> On Sun, 2004-02-15 at 02:25, James R. Leu wrote:
> 
> > It could be any protocol we map onto an LSP (ie ethernet/atm/fr over MPLS),
> > you just have to add a protocol driver for it.
> 
> And the reason you want to do it at the protocol level is because
> you can classify better?

To avoid packet re-ordering.  By using IPv4 header info, packets that
are apart of the same flow will take the same path.  Similar with IPv6
and ethernet over mpls (use src dst mac addrs for hash)

> 
> > The ECMP feature only help you at the ingress LER.  You need something
> > to handle load balancing in the core of the MPLS domain.
> 
> Agreed, so in my earlier email i said we had no control over ECMP
> i.e at the mercy of linux V4/6 ECMP. 
> At the ILM level on the other hand (for LSRs) we do have more control.

We have the oppurtunity for more control :-)

> > ECMP example:
> > 
> 
>                        -------             -------                    
>                       |       |           |       |                     
>             .--1G-----| LSR 1 |---100M----| LSR 2 |----1G---.
>            /          |       |           |       |          \          
>  ---------/            -------             -------            \--------
> | Ingress |                                                   | Ingress
> |
> |   LER   |                                                   |   LER  
> |
>  ---------\            -------             -------            /--------
>            \          |       |           |       |          /          
>             `--1G-----| LSR 3 |---100M----| LSR 4 |----1G---'
>                       |       |           |       |                     
>                        -------             -------
> 
> > 
> > In the above case ECMP will allow a max traffic of 200M between
> > ingress and egress.
> 
> Ok
> 
> > Load balancing example:
> > 
>  ---------             -------             -------             --------
> |         |           |       |---100M----|       |           |        |
> | Ingress |----1G-----| LSR 1 |---100M----| LSR 2 |----1G-----| Egress |
> |   LER   |           |       |---100M----|       |           |   LER  |
>  ---------             -------             -------             --------
> > 
> > 
> > 
> > Without load balancing LDP would create 1 LSP for traffic going
> > from ingress to egress.  The max traffic you could sent from ingress
> > to egress is 100M.  With load balancing LDP still sets up 1 LSP from
> > igress to egress, but when LSR2 advertises a label to LSR1, LSR1 realizes
> > it has 3 adj to LSR2 and creates 3 NHLFEs, on on each of the links. It then
> > uses some mechanism to load balance traffic arriving on it's 1 ILM onto
> > the 3 NHLFEs.  In the single label case, looking at the protocol ID
> > associated with the ILM and doing a little layer violation ;-) and we
> > can do per flow hashing and map flows to the various NHLFEs.  Now the
> > max traffic between ingress and egress is 300M.
> > 
> 
> Gotcha. so that balancing is done at the ILM level, correct?

yes.

> So that little violation or peeking is i take it the reason you want
> the protocol extension to be added?

It makes the layer violation less of a hack, and more deterministic.
I actually have my own idea, which still has a layer violation, but not
nearly as nastly as what the draft states.

> > > > The task is trival if the stack only has one label, for more then one label
> > > > we would have to be creative.  Hashing the label stack, or use the PW ID
> > > > (suggestion in PWE3 WG which adds a word after the labelstack to indicate
> > > > what protocol lies below.)  The PW ID could be used to lookup the protocol
> > > > driver to generate the hash.
> > > 
> > > Point me to some doc if you dont mind. Is this for some of the VPN
> > > encapsulations?
> > http://www.ietf.org/internet-drafts/draft-allan-mpls-pid-00.txt
> 
> I'll read the draft; i know the author from my nortel days.
> If i understood correctly, this is now introducing an extra piece
> of data in the packet? 

yes.

> Note, as i described earlier, we should be able to just look at
> anything on the packet with the u32 classifier which can be activated
> before MPLS ILM is consulted. Also based on the top label we can
> do a classification again to peek into further packet data before making 
> a decision the next hop.

What do that work for ILM which are just a swap?  It should only be done
when needed, otherwise what's the point of the LS in MPLS?

> 
> > > > Or of course we could just add an options for which algo to use.
> > > 
> > > Note what i suggested is only for ILM level; And there you could add any
> > > algorithms you want. With the protocol driver are you suggesting to do
> > > something at the IPV4/6 FTN level only?
> > 
> > To be able to load balance and guarentee packet order, you need to know
> > what is underneath the label stack.  With just one label it is trivial to
> > figure out what is under the label stack.  With more then one, it isn't
> > so easy (the LSR that needs to do the load balancing was not involved in the
> > signaling of any of the labels past the first one).  Currently vendors do
> > some nasty hacking.  Look at the first nibble after the label stack, if it
> > is a 4, they assume IPv4.  They build the appropriate hash and use that
> > to select the outgoing NHLFE.
> 
> Why cant you look? Is this because ASICS are already built?
> You know precisely where the label stack is going to end, no?
> Can you not then offset to that position and figure what the next
> data level is?

You can look, but how do you know what is there?  It could be a MAC
address, it could be voice data it could be anything.  If you mis-interpret
it, you could end-up re-ordering voice packets ... not good.  So in simple
terms it comes down to deteministically _not_ re-ordering packets :-)

> 
> 
> > Since we use the childs output pointer, IPv4|6 don't care if it is MPLS.
> > I suppose the same check for child could be made in MPLS output, then yes
> > you could have more the one child stacked.  I'm not sure if this would
> > be very optimal for create hierarchical LSPs (I think that is what
> > your eluding to).
> 
> Ok, that sounds reasonable. For starters dont even talk about hierachical
> LSPs ;-> Out challenge is to get rid of dst->mpls .. then go to David
> with this one change - I think its above 5% value add;->. 
> Are you going to make the change?

I'll make the change.  I'll send it to the list for review. I'd just
like to note that by ignoring hierachy, we're designing/developing by only
looking at about 25% of the requirements.  As I'm sure your familiar with,
it usually requires a re-spin to support the other 75% :-)

> 
> cheers,
> jamal
> 

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

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...

[mpls-linux-devel] interesting article

[Jamal H. S. <ha...@zn...>]

Someone pointed this article to me today:

http://www.commsdesign.com/showArticle.jhtml?articleID=16505029

Looks like the author knows what he is talking about. Didnt fully read
it.

cheers,
jamal

Re: [mpls-linux-devel] UML + mpls-kernel-davem?

[Jamal H. S. <ha...@zn...>]

On Tue, 2004-02-17 at 16:34, James R. Leu wrote:
> On Tue, Feb 17, 2004 at 02:39:28PM -0500, Jamal Hadi Salim wrote:
> > Sneaking in here;
> > I would have no problem on using UML if i can get a HOWTO on setting
> > up for MPLS testing.
> > 
> 
> The stuff I posted so far is not to that level.  I will spend some time
> tomorrow making a howto.

I have downloaded things; Treat me as a novice. Didnt know my cable
modem was this fast ;-> Getting about 250KB/sec. 
The time i tried uml it was pretty cool running it off gdb; is this
something that can be done with your setup?

cheers,
jamal

Re: [mpls-linux-devel] UML + mpls-kernel-davem?

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

On Tue, Feb 17, 2004 at 02:39:28PM -0500, Jamal Hadi Salim wrote:
> Sneaking in here;
> I would have no problem on using UML if i can get a HOWTO on setting
> up for MPLS testing.
> 

The stuff I posted so far is not to that level.  I will spend some time
tomorrow making a howto.

> cheers,
> jamal
> 
> On Tue, 2004-02-17 at 14:24, James R. Leu wrote:
> > On Tue, Feb 17, 2004 at 07:26:59PM +0100, Ramon Casellas wrote:
> > > On Tue, 17 Feb 2004, James R. Leu wrote:
> > > 
> > > > I keep a personal client in which I have the latest working UML patch
> > > > applied.  Would you guys like that submitted as part of the mpls-kernel-davem
> > > > branch?   I only update the kernel and the UML patch when I have them working.
> > > >
> > > 
> > > For me it's fine, as long as it is later possible to isolate the patches.
> > > 
> > > Thanks.
> > 
> > We would be able to generate a MPLS only patch.  It might have a bit
> > of line number 'skew' but that would be about it.
> > 
> > I'm going to add the UML patch to my base 2.6 kernel.  mpls-kernel-davem
> > is a branch from the tree, so I can integrate the UML change down to it.
> > To produce a MPLS only patch, we just diff the base 2.6 (with UML) with
> > the mpls-kernel-davem 2.6 (with UML).
> > 
> > Does that sound good?
> > 
> > > > Any thoughts?
> > > Yep! I'm very much interested in your setup (root files, .config, etc) I
> > > would appreciate downloading them from ftp
> > 
> > I've uploaded all the the files.  They're not ready for newbies to use, but
> > you guys are smart enough to knwo where to start and ask questions from there.
> > 
> > ftp://nero.doit.wisc.edu/pub/uml/
> > 
> > > -------------------------------------------------------
> > > 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
> 
> 
> 
> -------------------------------------------------------
> 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...

Re: [mpls-linux-devel] UML + mpls-kernel-davem?

[Jamal H. S. <ha...@zn...>]

Sneaking in here;
I would have no problem on using UML if i can get a HOWTO on setting
up for MPLS testing.

cheers,
jamal

On Tue, 2004-02-17 at 14:24, James R. Leu wrote:
> On Tue, Feb 17, 2004 at 07:26:59PM +0100, Ramon Casellas wrote:
> > On Tue, 17 Feb 2004, James R. Leu wrote:
> > 
> > > I keep a personal client in which I have the latest working UML patch
> > > applied.  Would you guys like that submitted as part of the mpls-kernel-davem
> > > branch?   I only update the kernel and the UML patch when I have them working.
> > >
> > 
> > For me it's fine, as long as it is later possible to isolate the patches.
> > 
> > Thanks.
> 
> We would be able to generate a MPLS only patch.  It might have a bit
> of line number 'skew' but that would be about it.
> 
> I'm going to add the UML patch to my base 2.6 kernel.  mpls-kernel-davem
> is a branch from the tree, so I can integrate the UML change down to it.
> To produce a MPLS only patch, we just diff the base 2.6 (with UML) with
> the mpls-kernel-davem 2.6 (with UML).
> 
> Does that sound good?
> 
> > > Any thoughts?
> > Yep! I'm very much interested in your setup (root files, .config, etc) I
> > would appreciate downloading them from ftp
> 
> I've uploaded all the the files.  They're not ready for newbies to use, but
> you guys are smart enough to knwo where to start and ask questions from there.
> 
> ftp://nero.doit.wisc.edu/pub/uml/
> 
> > -------------------------------------------------------
> > 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

Re: [mpls-linux-devel] UML + mpls-kernel-davem?

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

On Tue, Feb 17, 2004 at 07:26:59PM +0100, Ramon Casellas wrote:
> On Tue, 17 Feb 2004, James R. Leu wrote:
> 
> > I keep a personal client in which I have the latest working UML patch
> > applied.  Would you guys like that submitted as part of the mpls-kernel-davem
> > branch?   I only update the kernel and the UML patch when I have them working.
> >
> 
> For me it's fine, as long as it is later possible to isolate the patches.
> 
> Thanks.

We would be able to generate a MPLS only patch.  It might have a bit
of line number 'skew' but that would be about it.

I'm going to add the UML patch to my base 2.6 kernel.  mpls-kernel-davem
is a branch from the tree, so I can integrate the UML change down to it.
To produce a MPLS only patch, we just diff the base 2.6 (with UML) with
the mpls-kernel-davem 2.6 (with UML).

Does that sound good?

> > Any thoughts?
> Yep! I'm very much interested in your setup (root files, .config, etc) I
> would appreciate downloading them from ftp

I've uploaded all the the files.  They're not ready for newbies to use, but
you guys are smart enough to knwo where to start and ask questions from there.

ftp://nero.doit.wisc.edu/pub/uml/

> -------------------------------------------------------
> 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...

Re: [mpls-linux-devel] UML + mpls-kernel-davem?

[Ramon C. <cas...@in...>]

On Tue, 17 Feb 2004, James R. Leu wrote:

> I keep a personal client in which I have the latest working UML patch
> applied.  Would you guys like that submitted as part of the mpls-kernel-davem
> branch?   I only update the kernel and the UML patch when I have them working.
>

For me it's fine, as long as it is later possible to isolate the patches.

Thanks.



> Any thoughts?
Yep! I'm very much interested in your setup (root files, .config, etc) I
would appreciate downloading them from ftp

[mpls-linux-devel] UML + mpls-kernel-davem?

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

I keep a personal client in which I have the latest working UML patch
applied.  Would you guys like that submitted as part of the mpls-kernel-davem
branch?   I only update the kernel and the UML patch when I have them working.

Any thoughts?

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

Re: [mpls-linux-devel] DaveM code in p4

[Ramon C. <cas...@in...>]

On Tue, 17 Feb 2004, James R. Leu wrote:

> I've created a branch for the development of the DaveM code.
>
> Map //depot/mpls-kernel-davem/... into a client and you should be good


Thanks! I can start now my documenting paranoia :p

R.

[mpls-linux-devel] DaveM code in p4

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

I've created a branch for the development of the DaveM code.

Map //depot/mpls-kernel-davem/... into a client and you should be good
to go.  If you have no idea what this means and your interested in
helping out, take a look at:

http://perforce.com/perforce/doc.032/manuals/p4guide/index.html
and
http://mpls-linux.sourceforge.net/

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

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

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

On Mon, Feb 16, 2004 at 04:41:37PM -0500, Jamal Hadi Salim wrote:
> BTW, I am fine with whatever you guys end up picking for the
> code repository; you will have to teach me about its usage.
> p4 sounds good.
> Also James i know you are a big fan of UML - i am trying to see if it
> valubale - getting tired of hanging my laptop (though i run ext3 these
> days ;->); so if you can share your setup on a test environment i would
> appreaciate it.
> I looked at Qemu it does look very interesting; any thoughts on that?

I never tied Qemu, but your right it does look interesting.
I'll put my UML environment on a ftp server some place for your
to download.  It consists of a couple of scripts I thew together and
some rh8.0 files systems.  I'll arrange that this evening.

> On Mon, 2004-02-16 at 12:47, Ramon Casellas wrote:
> > On 16 Feb 2004, Jamal Hadi Salim wrote:
> 
> > 
> > 
> > > 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.
> > 
> 
> Could something in user space be responsible for maintaining the
> prestate? When full state is available, it gets downloaded to the
> kernel.
> 
> > > 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.
> > 
> 
> Ok, so we could add something this:
> l2c mpls nhlfe add dev eth0 proto ipv4 nhlfeid 3 blackhole
> 
> > 
> > > - 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?)
> 
> Well, something along the same lines. Example:
> 
> l2c mpls nhlfe add dev eth0 proto ipv4 nhlfeid 4 control-redirect 
> 
> The above could be a result of intentional policy  such as preceeded by:
> 
> l2c mpls ilm add dev eth0 label 9 nhlfeid 4 
> 
> or as a result of it being the default NHLFE rule which gets consulted
> because bothing else was found, example:
> l2c mpls nhlfe add dev eth0 nhlfeid 4 default control-redirect
> 
> Thoughts?
> 
> > > - 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.
> > 
> > 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.
> 
> If the last label has been popped then it would make sense to redirect
> to the stack. The one that i was worried about is it having a stack of 
> labels hiding a local host IP packet. Can we assume that the user can
> shoot themselves in the feet and we wouldnt care?
> 
> cheers,
> jamal
> 
> 
> 
> -------------------------------------------------------
> 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...