Subject: [Monami6] New draft submitted: draft-larsson-monami6-filter-rules-00.txt

From: "Conny Larsson (KI/EAB)" <[email-masked]>
Date: Tue, 27 Jun 2006 19:06:09 +0200

Dear all,

We have submitted a new draft describing a mechanism that
could be used to direct flows to/from multi-homed nodes.

Below is the URL for the Internet draft: 
<http://www.ietf.org/internet-drafts/draft-park-mis-00.txt>
http://www.ietf.org/internet-drafts/draft-larsson-monami6-filter-rules-00.txt

Here is the abstract:

This document suggests a mechanism that could be used to direct flows
from and to multi-homed nodes.  A clear distinction is made between
policies, filter rules and filters.

In order to be able to use filter rules in a multi-access mobility
context without excessive overhead, it is advantageous to be able to
define match functions and bindings separately, as it is expected
that it may be necessary to update the bindings much more often than
the match functions.  If the binding is expressed in terms of filter
rule identifier and care-of address, the bindings must be updated on
a handover to a new care-of address, while the match function will not.

Regards
Conny Larsson

_______________________________________________
Monami6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/monami6

---

From: Gábor Fekete <[email-masked]>
Date: Tue, 27 Jun 2006 21:49:42 +0300

Hi,

First of all, thank you for writing this draft.

I have found it quite abstract. As I see, this draft is
meant as a guideline for policy solution designers. Is it so?

I understand that you intentionally left out the discussion
of the transferring details. But is it so that it is supposed
to be accompanied by other documents describing
o Specification of Policies
o Specification of Filter Rules?

Anyway, I have some more specific questions.
1. The definition of a "Filter" is not entirely clear to me. Is it so that
   one network node has one single Filter (one single set of Filter
   Rules)?

2. Secion 2.1 Policy says:

  "Both the host and the network have interest in how policies are
   defined and applied.  Consequently the exchange of policies could be
   initiated by either the host or a node in the network."

   and section 2.2 says:

  "Filter rules are generated from (a set of) policies."

   Is it so that only the MN generates Filter Rules out
   of Policies, therefore having such an exchange:

   1. MN <--- policy ------- HA
   2. MN --- filter rule --> HA?

   If not, then it is not clear how can a non-mobile node (e.g. HA or
   CN) generate Filter Rules out of Policies.
   E.g. If a policy says "if WLAN is available then ..." then how can
   the non-mobile node know which IP address of the MN belongs to the
   WLAN interface? Does the draft assume some information exchange
   between the MN and its peer about this?

3. In section 2.2.  Filter rules and Filter:

  "Filter rules are generated from (a set of) policies.  A filter rule
   would be realized as a Packet Filter (PF) and assigned a unique
   filter rule identifier (FRID). ..."

   Then section 2.3 says:

  "The FRID would in this proposal be used as proposed in [I-D.ietf-
   monami6-multiplecoa] (replacing the BID) to create a binding between
   a care-of address and a (set of) filter rule(s). ... "

   But if an FRID uniquely identifies one Filter Rule then how can it
   identify a "set of Filter Rules"?

4. Also in section 2.2.  Filter rules and Filter:

  "A filter rule may only be associated with one care-of address, but a
   care-of address can be associated with multiple filter rules."

   Should not this be "A filter rule __can__ only be associated..." instead?
   As I see, this draft, for Mobile IPv6, depends on ietf-monami6-multiplecoa
   and if a Filter Rule is associated with multiple CoAs then there would be
   multiple BC entries with the same BID (FRID).

Over all, I think this draft should/could be more independent from Mobile IPv6
but then there is not much left in it. Then it may be extended to a fully
functional draft on policy/filter description and exchange (like
draft-mitsuya-monami6-flow-distribution-policy-01.txt) but without any
mobility management protocol dependency.

Regards,
Gabor Fekete

---

From: "Conny Larsson (KI/EAB)" <[email-masked]>
Date: Tue, 27 Jun 2006 22:35:03 +0200

Hi Gábor,

Thank you for reading and commenting on the draft.

See my answers inline.

/Conny

> meant as a guideline for policy solution designers. Is it so?
Our intention was to describe the different mechanisms but also
to discuss the transferring details. Unfortunately we did not
have time to discuss the transferring details.
> o Specification of Filter Rules?
A separate document where handling of Filter Rules are discussed.
>    one network node has one single Filter (one single set of Filter
When writing the draft the definition of filter was
Filter = set of Filter Rules
A mobile node would typically have one filter consisting of a set of
filter rules.
>    between the MN and its peer about this?
The above wording "Filter rules are generated from (a set of) policies."
is wrong. I would rather say  that that the policy decides which
interface (and address) to use for a specific filter rule.

This will be clarified in the next release of the draft.
>    identify a "set of Filter Rules"?
The FRID uniquely identifies the one filter rule. I will clarify this.
The above wording is wrong.
>    multiple BC entries with the same BID (FRID).
I'm thinking of it like this. When sending a Binding Update with the BID 
option
the FRID would be added to this option.

BU {BID-1, CoA-1, [Set-of FRID]}

When a care-of address is changed and a Binding Update is sent it would 
be like

BU {BID-1, CoA-3}

The initial idea was that a filter rule can only be associated with one 
care-of
address. We have also thought of the possibility to have a filter rule
associated with multiple care-of addresses for bi-casting or load balancing.
However, at this stage we stick with "one filter rule one CoA" since I'm not
sure of the implications of having multiple care-of addresses associated 
with
one filter rule.
> mobility management protocol dependency.
We will try to make it more independent of MIPv6, thats the intention.
Further work will be done on the draft.