From: "Krishna Kumar" <kumarkr@us.ibm.com>
To: kuznet@ms2.inr.ac.ru
Cc: linux-kernel@vger.kernel.org, linux-net@vger.kernel.org,
netdev@oss.sgi.com
Subject: Re: [PATCH] IPv6 Prefix List support for 2.5.31
Date: Thu, 29 Aug 2002 11:28:15 -0700 [thread overview]
Message-ID: <OF28502B61.D4B55262-ON88256C24.00649637@boulder.ibm.com> (raw)
Hi Alexey,
Thanks for your detailed response. I have included my comments to the
points
you have raised below :
> > - Routing table will have lots of address prefixes that are not
available
> > to the local interface addresses.
>
> Well, all the direct routes are prefixes by definition.
I had written in my previous mail "More code needs to be present to parse
each
entry in this case.", which is what I think you have also implied. Eg, for
each
routing entry, you need to make sure it is the same device, that it is not
a
Link Local destination, and there is no 'next hop' field.
> > - To be a prefix list entry, it should come via an RA.
>
> Wrong. But this does not matter, RA routes may be tagged with a flag.
I disagree about the first part :-) A user can add an address with a new
prefix, but that should not be present in the list of prefixes supported
on that subnet. The prefix list should contain elements that a RA has
advertised as part of the prefixes that the router supports. The RFC is
specific about how prefix list entries are to be created (eg 6.3.4).
Regarding the second point you made about the 'flag', I agree with you, and
I did say something to that effect in my previous mail :
"Then the only solution to figure out that this is not a real
Prefix
entry would involve more code to determine if this is an RA added
routing entry or a manual one."
> > - Also, the search over a longer routing table across all nodes is
more
> > time consuming.
>
> Do you jest? You compare linear search with lookup in radix tree. :-)
Since there is no key to lookup, you have to always walk the entire tree
(the
key is an address/prefix, but we don't have it). I think it would be faster
in
the case where the routing table is very large, and there aren't too many
interfaces (haven't defined "too many" here :-). The number of prefixes on
an
interface is not important for the search property.
The difference is that in case of routing table lookup, you go through the
entire tree and parse each entry, while in the proposed approach, the
linear
search is only done to locate the 'dev' and then the work is more
straightforward - return all entries after getting the correct 'dev'.
I agree that the Prefix List could be implemented on either the idev list
OR
the routing table, we just need to agree which is better place to put the
list.
Thanks,
- KK
next reply other threads:[~2002-08-29 18:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-29 18:28 Krishna Kumar [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-08-28 23:55 Krishna Kumar
2002-08-29 0:32 ` kuznet
2002-08-28 22:05 Krishna Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=OF28502B61.D4B55262-ON88256C24.00649637@boulder.ibm.com \
--to=kumarkr@us.ibm.com \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-net@vger.kernel.org \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®