All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahide NAKAMURA <nakam@linux-ipv6.org>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [RFC] [PATCH] [XFRM]: Restrict upper layer information by bundle.
Date: Tue, 01 May 2007 01:30:21 +0900	[thread overview]
Message-ID: <20070501011930.AC41.NAKAM@linux-ipv6.org> (raw)
In-Reply-To: <20070430.003437.57159715.davem@davemloft.net>


On Mon, 30 Apr 2007 00:34:37 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Masahide NAKAMURA <nakam@linux-ipv6.org>
> Date: Fri,  6 Apr 2007 16:25:39 +0900
> 
> > On MIPv6 usage, XFRM sub policy is enabled.
> > When main (IPsec) and sub (MIPv6) policy selectors have the same
> > address set but different upper layer information (i.e. protocol
> > number and its ports or type/code), multiple bundle should be created.
> > However, currently we have issue to use the same bundle created for
> > the first time with all flows covered by the case.
> > 
> > It is useful for the bundle to have the upper layer information
> > to be restructured correctly if it does not match with the flow.
> > 
> > 1. Bundle was created by two policies
> > Selector from another policy is added to xfrm_dst.
> > If the flow does not match the selector, it goes to slow path to
> > restructure new bundle by single policy.
> > 
> > 2. Bundle was created by one policy
> > Flow cache is added to xfrm_dst as originated one. If the flow does
> > not match the cache, it goes to slow path to try searching another
> > policy.
> > 
> > Signed-off-by: Masahide NAKAMURA <nakam@linux-ipv6.org>
> 
> This is an OK solution for the problem for now.
> 
> My senses tell me that there is probably some cleaner way to
> handle this problem.  If you come up with a better idea for it,
> please feel free to bounce your ideas to me.

I get it. It is added to my TODOs to find another way (which may include
design level change) to achive it.

Thank you,

-- 
Masahide NAKAMURA


      reply	other threads:[~2007-04-30 16:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-06  7:25 [RFC] [PATCH] [XFRM]: Restrict upper layer information by bundle Masahide NAKAMURA
2007-04-12  5:42 ` Masahide NAKAMURA
2007-04-12  6:24   ` David Miller
2007-04-12  6:53     ` Masahide NAKAMURA
2007-04-30  4:36       ` Masahide NAKAMURA
2007-04-30  5:21         ` David Miller
2007-04-30 16:30           ` Masahide NAKAMURA
2007-04-30  7:34 ` David Miller
2007-04-30 16:30   ` Masahide NAKAMURA [this message]

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=20070501011930.AC41.NAKAM@linux-ipv6.org \
    --to=nakam@linux-ipv6.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.