Subject: [MEXT] flow binding draft 2

From: Christian Kaas-Petersen <[email-masked]>
Date: Fri, 1 May 2009 11:39:03 +0000 (GMT)

Having read draft-ietf-mext-flow-binding-02, I should like to be
informed about two design rationales.

The first is related to the PRO field in the Flow Identification Mobility
Option.  The mobile node must explicitly inform if it is an Add or a
Modify operation; the mobile node does implicitly inform if it is a
delete operation.  In principle there is no need for the PRO field.
There are three cases.

(a) If a FID-value is absent in BU and
    present in Flow Binding List        => remove
(b) If a FID-value is present in BU and
    absent in Flow Binding List         => add
(c) If a FID-value is present in BU and
    present in Flow Binding List        => modify

With these cases PRO field can be removed.  Alternatively, one could take
the other extreme, also explicitly naming the FID-values to be removed.

The document has made an in-between choice.  I'm not suggesing a change,
I'm looking for an explanation.

The other item relates to what in section 4.4 is denoted a "valid BID".
When a BU wants to insert a FID-entry, and this FID-entry refers to one
or more BID-values, all of those BID values must be found in the
BID Entries List, and thus an entry will always achieve the Active state.
However, at later times BID-entries may be removed, and so a state may
change to Inactive.  What is reason for a state not being allowed
Inactive to start with?  Again, I'm just looking for an explanation.

A few minor points.

 * Abstract: uses the word "peer" as a short term for correspondent node,
   home agent, and mobility anchor point.  In general, a mobile node's
   peers are all the nodes with which it has TCP/UDP sessions.  I think
   the term "peer" has a too wide interpretation.

 * Section 4.1, in the description of BID-PRI field, the words "a higher
   number" assumes reading the 7-bit field as an unsigned integer.

 * Section 4.2, in FID description, 8-bit should be 16-bit.

 * Section 4.2, in 1 Forward, a forward reference for Binding Reference
   sub-option would be helpful when reading this document first time.

 * Section 4.3, in Option Type, I think a copy from the section 4.2.1.

 * Section 4.4, para 2, one of the words "change" or "modify" should be
   enough.

 * Section 4.4, Action bullet: "PRO field" to be replaced with
   "Action field".

 * Section 4.4, para just above Ordered Flow Binding Entries, "three flow
   bindings" to become "four flow bindings".

Christian

      Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 1 May 2009 13:04:25 +0100

Hi Christian,

Wow, very quick turnaround, and a good review, thanks!

Marcelo, are you counting? :-)

See comments inline...

> the other extreme, also explicitly naming the FID-values to be removed.

GT> You are right that instead of ADD/MOFIDY we can always overwrite
existing FID with new FIDs when they already exists and add them when
the do not exists.  The reason, however, we left the ADD/MODIFY is to
make it easier for the MN and HA to catch errors e.g., cases where the
MN things its adding something new but the FID actually already
exists. Or the case where the MN thinks its modifying something but
the HA has no record of that.
Unlike ADD and MODIFY, the REMOVE value is creating more trouble than
it is worth. Given the soft-state nature of the protocol it is
important to refresh all FIDs in all BUs, so if an FID is not included
in a BU it MUST be removed. The PRO=REMOVE, then creates two ways of
doing the same thing (remove FID by not including it in BU, or by
setting PRO=REMOVE), which is something we wanted to avoid

GT>> Again, I think your proposal to drop PRO is not unreasonable, it
is just that RPO field provides an error detection functions which we
think could be useful.

> I'm looking for an explanation.

GT> I hope the above satisfies you?

> Inactive to start with?  Again, I'm just looking for an explanation.

GT> It is not clear why the MN would create an entry that is inactive
to begin with. It seems to me that the entry can always be created
when the MN actually needs it. The reason Inactive FIDs are defined in
the draft is to handle the case where BIDs are subsequently removed.
Without the inactive FID concept this would mean an implicit removal
of FIDs pointing to the removed BID. That again could cause confusion
since it would create two ways of removing an FID entries (remove FID
by not including it in BU, or by removing all of the BIDs associated
with it)

GT> So, we could allow the MN to add an inactive FID entry, but the
added complication does not seem to provide useful flexibility.

> A few minor points.

GT> All of your minor points are welcome and will be corrected in the
next version of the draft.

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 1 May 2009 07:59:52 -0700 (PDT)

Hi Hesham,
  Here are a few of my observations:

-Flow Binding definition in Sec. 3 became circular, I thought previous definition was OK.
-My biggest concern is there has been an artificial attempt in this version to introduce/increase dependency on MCoA draft. 
I would like to ask why?
I would like to ask Hesham if he personally agrees, pointing to the fact that he made public comments contrary to this?

  Note this is not a full review.

Regards,

Behcet

________________________________
From: Christian Kaas-Petersen <[email-masked]>
To: [email-masked]
Sent: Friday, May 1, 2009 6:39:03 AM
Subject: [MEXT] flow binding draft 2

A few minor points.

Christian

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 02 May 2009 12:47:03 +1000

Hi Behcet

> -My biggest concern is there has been an artificial attempt in this version to
> introduce/increase dependency on MCoA draft.

=> First, "introduce" and "increase" are not synonyms so which one did you
want? We certainly didn't introduce this in this rev. Support for MCoA was
included in 2006 if I remember correctly. I did ask the question in the last
meeting to see if people had any opinions on mandating the use of MCoA and
received no feedback. So the authors discussed it and we thought it was
easiest to mandate it and avoid confusion.
You mention that it's your biggest concern; why is that?

> I would like to ask why?
> I would like to ask Hesham if he personally agrees, pointing to the fact that
> he made public comments contrary to this?

=> Which public comments are you referring to? As far as I remember I was
not convinced in 2006 that adding MCoA was necessary but I was convinced by
people on the list that it was a good idea so we agreed to include it back
then. What comments are you referring to?
Anyway, I'm not a politician; so I can say something and be proven wrong and
accept that. I'm still not sure why you think this is a concern for the
draft.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Mon, 04 May 2009 15:12:50 +0800

Hello

I do think it is necessary to keep the REMOVE operation. In
my understanding, the explicit REMOVE operation can avoid 
that, once a certain flow is added/modified, all the flows have 
to be updated. In addition, you mentioned implicit REMOVE 
operation (remove FID by not including it in reg-BU) should be 
disallowed. 

Secondly, from the draft's description and your explanation, 
I don't find that the Inactive status is similar meaningful. 
It has to be updated to active state if the inactive flow is 
enabled to be used. 
Maybe the only reason why the Inactive status exists is 
the confusion of Remove operation (two ways) you mentioned. 
However, I don't think this reason is very good. The general
operation of BID deletion could be: when a BID is being 
deleted, MN and HA both should modify its associated 
FIDs to refer new BID or delete them.

B.R.
Yungui  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Tsirtsis
> Sent: Friday, May 01, 2009 8:04 PM
> To: Christian Kaas-Petersen
> Cc: [email-masked]
> Subject: Re: [MEXT] flow binding draft 2
> 
> Hi Christian,
> 
> > Option. ?The mobile node must explicitly inform if it is an Add or a
> > delete operation. ?In principle there is no need for the PRO field.
> > There are three cases.
> >
> > ? ?present in Flow Binding List ? ? ? ?=> remove
> > ? ?absent in Flow Binding List ? ? ? ? => add
> > ? ?present in Flow Binding List ? ? ? ?=> modify
> >
> > With these cases PRO field can be removed. ?Alternatively, 
> one could take
> > The document has made an in-between choice. ?I'm not 
> suggesing a change,
> > change to Inactive. ?What is reason for a state not being allowed
> > Inactive to start with? ?Again, I'm just looking for an explanation.
> >
> 
> > ?* Abstract: uses the word "peer" as a short term for 
> correspondent node,
> > ? home agent, and mobility anchor point. ?In general, a 
> mobile node's
> > ? peers are all the nodes with which it has TCP/UDP 
> sessions. ?I think
> > ? the term "peer" has a too wide interpretation.
> >
> > ?* Section 4.1, in the description of BID-PRI field, the 
> words "a higher
> > ? number" assumes reading the 7-bit field as an unsigned integer.
> >
> > ?* Section 4.2, in FID description, 8-bit should be 16-bit.
> >
> > ?* Section 4.2, in 1 Forward, a forward reference for 
> Binding Reference
> > ? sub-option would be helpful when reading this document first time.
> >
> > ?* Section 4.3, in Option Type, I think a copy from the 
> section 4.2.1.
> >
> > ?* Section 4.4, para 2, one of the words "change" or 
> "modify" should be
> > ? enough.
> >
> > ?* Section 4.4, Action bullet: "PRO field" to be replaced with
> > ? "Action field".
> >
> > ?* Section 4.4, para just above Ordered Flow Binding 
> Entries, "three flow
> > ? bindings" to become "four flow bindings".
> >
> > Christian
> >
> >
> >
> >
> > ? ? ?Find din nye laptop p? kelkoo.dk. Se de gode tilbud 
> her - http://dk.yahoo.com/r/pat/mm

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 4 May 2009 09:38:09 +0100

inline

> operation (remove FID by not including it in reg-BU) should be

GT> As I already explained in the exchange with Christian, an explicit
REMOVE operation is indeed possible. It is not, however, preferable
since it would result in two ways of removing an FID. It is not good
design practice to have multiple ways of doing the same thing, and in
this case there is no reason to do so.

> FIDs to refer new BID or delete them.

GT> Again, as I already explained the inactive state is there for the
same reasons i.e., to avoid two ways of doing the same thing.

Regards
George

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 May 2009 11:48:23 -0700 (PDT)

Hi Hesham,
  You sounded like there was nothing new in this version as to MCoA draft .
You added binding identifier mobility option in Sec. 4.1 which comes even before the main option of flow identification mobility option.
  There is probably no need to discuss these things more again, I am OK with the previous versions in which there is an optional binding reference sub-option and I am OK with an informative reference to the MCoA draft.
  Yes I was referring to the 2006 discussions.

Regards,

Behcet

________________________________
From: Hesham Soliman <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Christian Kaas-Petersen <[email-masked]>; [email-masked]
Sent: Friday, May 1, 2009 9:47:03 PM
Subject: Re: [MEXT] flow binding draft 2

Hi Behcet

Hesham

> Inactive to start with?  Again, I'm just looking for an explanation..
> 
> A few minor points.
>

---

From: Yungui Wang <[email-masked]>
Date: Tue, 05 May 2009 08:58:05 +0800

Hello

I agree with you that "not do the same thing with multiple 
ways". However,  I don't think new version of this draft is 
good designed on the REMOVE operation.  You could try 
to implement a simple example:
One MN has added 100 flows to HA. Following one 
additional flow is dynamically to be added, it has to also 
carry the previous 100 flows to HA.
Do you think it is indeed acceptable?

There are two ways which are usually designed for 
session/binding deletion for your information:
1, explicit REMOVE operation; or
2, add parameter: lifetime of FID; 
    BU(FID, lifetime=0), =>  delete the FID.

In this way, below nits can be avoided in this draft:
i)  implicit REMOVE operation;
ii) useless Inactive state;

B.R.
Yungui

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Monday, May 04, 2009 4:38 PM
> To: [email-masked]
> Cc: Christian Kaas-Petersen; [email-masked]
> >> the do not exists. ?The reason, however, we left the 
> ADD/MODIFY is to

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 05 May 2009 13:27:54 +1000

> carry the previous 100 flows to HA.

=> No it doesn't, because it only sends the summary option in addition to
the new FID.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Tue, 05 May 2009 12:38:36 +0800

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Tuesday, May 05, 2009 11:28 AM
> To: [email-masked]; 'George Tsirtsis'
> Cc: [email-masked]
> => No it doesn't, because it only sends the summary option in 
> addition to the new FID.

The issue is not solved. Just make the wasted size reduced 
to 100*2bytes. Maybe, a wildcard flag can be defined for all 
the flows of the MN. Then it could only waste 2 byte to patch 
the hole. 

Don't you think that all that new features (FID Summary 
Mobility Option, Inactive state, FID always presented in 
re-reg BU, etc) introduced in the new version is mainly
to get the implicit REMOVE operation?

I don't think it is perfect, personally support your old version 
with explicit REMOVE operation.

B.R.
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 05 May 2009 14:55:06 +1000

> to get the implicit REMOVE operation?

=> Not at all. The Summary option was introduced to do two things:
1. Save bytes on refreshes
2. Allow for incremental bindings in cases where not all the bindings can be
included in the same message.

You're suggesting that we simply only add new bindings in the BU and that
there is no need to include FID indices in the BU to refresh them. So how do
you refresh bindings? What if the MN rebooted and lost all state and became
out of sync with the HA? What happens then?

> with explicit REMOVE operation.

=> The explicit remove is not an issue and can be added but it was never
intended to replace the function of the summary option.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Tue, 05 May 2009 14:18:54 +0800

Please see inline.

B.R.
Yungui

> Sent: Tuesday, May 05, 2009 12:55 PM
> there is no need to include FID indices in the BU to refresh 
> them. 

Yes. Further, if flow is not changed, no FID is included in
the re-reg BU.

> So how do you refresh bindings? 

We don't need to refresh flow bindings. Since flow have no 
lifetime and are binding to CoA(BID), it is not 
necessary to refresh them. We can just refresh CoA(BID).

> What if the MN rebooted and lost all 
> state and became
> out of sync with the HA? 

Since MN reboots, it will re-register all its bindings and flows. 
Maybe re-using the 'overwrite' flag in the MCoA could eliminate 
your worry.

> What happens then?

See above. Summary option is not needed yet.

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 05 May 2009 16:23:33 +1000

> necessary to refresh them. We can just refresh CoA(BID).

=> Of course they have a lifetime, it's the lifetime of the BU.
> Since MN reboots, it will re-register all its bindings and flows.

=> How?? Are you saying the MN somehow remembers what flows it had before
reboot? Even if it did, if a connection no longer exists it won't need a
binding. Makes no sense to me.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 7 May 2009 16:56:43 +0200

Hello George,

I looked at the draft and it is in very good shape. I have a quick 
question regarding the FID Priority:

      FID-PRI

         This is an 8-bit priority field to indicate the priority of a
         particular option.  This field is needed in cases where two
         different flow descriptions in two different options overlap.
         The priority field decides which policy should be in those
         cases.  A lower number in this field indicates a higher
         priority.

Shouldn't we made explicit that each FID is assigned a unique priority?

--julien

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 May 2009 17:17:25 +0100

Two FIDs can have the same FID-PRI as long as they do not overlap. If
one rules says match all UDP and the other says match all TCP, then
the rules do not overlap and the can have the same FID-PRI since the
result will be the same no matter which order they are looked at.

If two rules overlap, however, they need different FID-PRI since then
the MN needs to define which one to be looked at first. e.g., one
rules is match all UDP and the other is match sourceAddr=IPx then the
rules overlap since there might be packets that are UDP and also have
sourceAddr=IPx. In this case the order is important so the FID-PRI
should be different. If the FID-PRI is the same then it means that the
rules will be put in whatever order the received decide (which could
be random).

If this is not well described in the draft we can probably expand on
it...I have the sense I wrote again about this recently but I cannot
remember if it was on the mailing list or in some other context; my
brain's efficiency goes down as the week progresses :-/

George

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 7 May 2009 18:27:04 +0200

George, Julien,

How can you make sure that two rules won't overlap?
In the example you mention it is obvious, but if you are going into  
more complicated rule, I am not sure we can always know which rule can  
overlap.

I think we should avoid to have the same FID-PRI for different FIDs  
just to make sure (and then clarify it in the draft).

Nicolas

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 May 2009 17:35:35 +0100

Hmmm,

We could require different FID-PRI for each rule but all the
classifiers I know of (in several different OSs) allow such priorities
to be the same for the reasons I described.
I am not sure why we would want to do this differently. It would
likely confuse people familiar with classifiers without any reason.

George

On Thu, May 7, 2009 at 5:27 PM, Nicolas Montavont <[email-masked]> wrote:
> In the example you mention it is obvious, but if you are going into more
> complicated rule, I am not sure we can always know which rule can overlap.
>
> I think we should avoid to have the same FID-PRI for different FIDs just to
> make sure (and then clarify it in the draft).
>
> Nicolas
>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 08 May 2009 12:21:30 +1000

You're all correct, but I still don't see the issue, you always need to make
sure that the receiver can break a tie, whichever option we choose. So if
two rules overlap and have the same PRI (for whatever reason) the receiver
just picks one over the other.
The counter question to Nicolas' question below is: how can you really be
sure, as a sender, that your priorities are always correct? :) you can't.
Esepcially if the rule encompasses a lot of connections.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 May 2009 11:23:53 +0200

Hi George,

On Thursday 07 May 2009, George Tsirtsis wrote:
> should be different. If the FID-PRI is the same then it means that
> the rules will be put in whatever order the received decide (which
> could be random).

Can agree with the above, but this put a requirement on both ends to be 
able to determine whether or not there's an overlap for every duple of 
rules with same priority within the ruleset, and generate an error if 
there is indeed an overlap. This puts an additional computational 
burden on the mobile node to provide some flexibility for which I do 
not see any clear benefit. I thus believe FID priority should be 
unique. If somebody can come up with a scenario outlining the value of 
specifying rules with same priority, I am happy to keep that 
flexibility.

--julien

> >         This is an 8-bit priority field to indicate the
> > priority of a         particular option.  This field is needed
> > in cases where two         different flow descriptions in two
> > different options overlap.         The priority field decides
> > which policy should be in those         cases.  A lower number
> > in this field indicates a higher         priority.
> >

-- 
--julien

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 08 May 2009 19:45:29 +1000

Julien,

> specifying rules with same priority, I am happy to keep that

=> Like I said earlier, the graceful way of handling this is for the
receiver to break the tie. We need to require this capability anyway for the
receiver, that's why I don't see a need for unique PRI. Furthermore, there
can be cases where the MN simply doesn't care and allows the HA to decide
which one goes where.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Fri, 8 May 2009 14:10:04 +0200

Hesham,

On Friday 08 May 2009, Hesham Soliman wrote:
> >> Two FIDs can have the same FID-PRI as long as they do not overlap.
> >> If one rules says match all UDP and the other says match all TCP,
> >> then the rules do not overlap and the can have the same FID-PRI
> >> since the result will be the same no matter which order they are
> >> looked at.
> >>
> >> If two rules overlap, however, they need different FID-PRI since
> >> then the MN needs to define which one to be looked at first. e.g.,
> >> one rules is match all UDP and the other is match sourceAddr=IPx
> >> then the rules overlap since there might be packets that are UDP
> >> and also have sourceAddr=IPx. In this case the order is important
> >> so the FID-PRI should be different. If the FID-PRI is the same
> >> then it means that the rules will be put in whatever order the
> >> received decide (which could be random).
> >
> > Can agree with the above, but this put a requirement on both ends
> > to be able to determine whether or not there's an overlap for every
> > duple of rules with same priority within the ruleset, and generate
> > an error if there is indeed an overlap. This puts an additional
> > computational burden on the mobile node to provide some flexibility
> > for which I do not see any clear benefit. I thus believe FID
> > priority should be unique. If somebody can come up with a scenario
> > outlining the value of specifying rules with same priority, I am
> > happy to keep that flexibility.
>
> receiver to break the tie. We need to require this capability anyway
> for the receiver, that's why I don't see a need for unique PRI.

I could live with a tie break mechanism but, as a sender I wouldn't like 
to believe the tie was broke left while the sender actually broke it 
right. Thus if we rely on tie break, I'd rather have us specify how 
that works, which in turns imply that we define a sub-order among rules 
with same priority. I do not see the point but...

The simplest sub-ordering scheme I can come up with is, for every set of 
rules with same priority: the earliest rule established prevails on 
other, while rule A is earlier than rule B if 1) rule A in is a BU send 
before the BU that contains rule B, or 2) rule A is placed before rule 
B in the same BU.

To me this is more complex while the end result is not that different 
from rules with unique priorities, since in both case we do define a 
total order amongst rules.

In one case (tie break) the total order depends on the combination of a 
tie break mechanism and the ruleset, while in the other case (unique 
priorities) the total order depends uniquely on the ruleset. 

Thus I'd favor the later since it is explicit and I highly value 
expliciteness in protocol designs. Maybe this only me...

If anyone has a clear benefit of tie break in mind, could he speak up?

> Furthermore, there can be cases where the MN simply doesn't care and
> allows the HA to decide which one goes where.

I do not understand why would the MN put forth two overlapping rules in 
the first place if it doesn't care...

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 08 May 2009 23:04:46 +1000

> with same priority. I do not see the point but...

=> I agree there would be no point in doing that but the question is why is
the sender sending the same priority? May be it doesn't care. So what if
they broke the tie differently?

> total order amongst rules.

=> I think if we have to make it unique then unique PRI is the way to do it.
But my point is that doesn't eliminate the need for a tie breaker as a
graceful fallback. I can't see the harm in a different tie break at either
end. What am I missing?

> the first place if it doesn't care...

=> Because it's installing the rule and it doesn't care *now*. May be later
it will change it. I don't have a concrete example but given that this is
done by upper layers I'd rather err on the side of flexibility provided that
no harm is done. So my question to you is: What harm do you see?

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Sun, 10 May 2009 13:36:54 +0100

Julien,

One thing to note is that there is no way you can put together a
classifier without knowing exactly what order the rules need to be
placed in the list and without understanding which ones overlap and
which are not. The MN MUST be able to do this, otherwise there is no
way to impose the desired behaviour.

Now also consider that whether we require a unique PRI or not, the MN
again will have to know the above. If you require unique PRI, the MN
will have to decide the order of overlapping rules. If we allow more
than one rule to have the same PRI, the MN will have to decide which
rules are not overlapping and thus they can take the same value.

So, either way, it makes no difference to the complexity of the MN.

On the HA side it is also easy either way. Rules are ordered according
to PRI. Rules with the same PRI will be placed in a random order
between them, since it makes no difference.

And just for fun, here is an example of the value of allowing rules
with same PRI. Say you have 3 rules with PRI 1, 2, and 3. Now you want
to add a rule which needs to be placed between 1 and 3, and does not
overlap with 2.
If you require unique  PRIs, you will have to renumber 3 to 4 and add
the new rule as a new 3; ending up with PRI 1, 2, 3, and 4. If you
allow for non-unique PRIs you just add the new rule with PRI 2,
resulting in 1, 2, 2, 3.

Again, I am not saying the above presents a significant advantage but
only that this is how all classifiers work in existing implementations
and thus we should not do something different unless we have a really
good reason, which IMO we do not.

Does this help?

George

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 11:40:47 +0200

Hi George,

> way to impose the desired behaviour.

You can build a classifier in which rules are ordered and the classifier 
needs not to determine overlaps, which is incidentaly what IPsec does, 
see this excerpt from 4301:

   The SPD is an ordered database, consistent with the use of Access
   Control Lists (ACLs) or packet filters in firewalls, routers, etc.
   The ordering requirement arises because entries often will overlap
   due to the presence of (non-trivial) ranges as values for selectors.
   Thus, a user or administrator MUST be able to order the entries to
   express a desired access control policy.  There is no way to impose a
   general, canonical order on SPD entries, because of the allowed use
   of wildcards for selector values and because the different types of
   selectors are not hierarchically related.

In that sense the priority is just a way to express within the MN - HA 
signalling, and the priority needs not to be exposed to ULPs.

> rules are not overlapping and thus they can take the same value.

As above, overlapping is irrelevant once we require ordered rules.

> So, either way, it makes no difference to the complexity of the MN.

I disagree. Ordered list is just simple since I do not need to determine 
overlaps b/w rules. 

> On the HA side it is also easy either way. Rules are ordered
> according to PRI. Rules with the same PRI will be placed in a random
> order between them, since it makes no difference.

Hmmm... makes no difference with what? with another random order?

> with same PRI. Say you have 3 rules with PRI 1, 2, and 3. Now you
> want to add a rule which needs to be placed between 1 and 3, and does
> not overlap with 2.

For a start one would use rule numbered 10, 20 and 30, then if you need 
a new rule b/w 10 and 30, you pick 15, or 25, depending whether you 
want to prioritize over 20 or not.

If you ever end up with a full interval [10-20] then you can start to 
renumber.

Note that all of these priorities can be kept entirely internal to MIPv6 
and hidden from ULPs if an appropriate API is devised. The ULP needs 
not to care about which priority is in use, it only cares about the 
order. 

A strawman API could look like:

  get_ordered_ruleset(ruleset *rs);
  insert_rule_in_ruleset(ruleset *rs, rule *rule_below, rule *new_rule);
  modify_rule_in_ruleset(ruleset *rs, rule *old_rule, rule *new_rule);
  delete_rule_in_ruleset(ruleset *rs, rule *rule);

> only that this is how all classifiers work in existing
> implementations and thus we should not do something different unless
> we have a really good reason, which IMO we do not.

Some classifiers may work as you say, but others (including IPsec and 
some firewalls) do not, thus I disagree we would be doing something 
different by requiring a priority to be unique, i.e., requiring the 
ruleset to be ordered. As to the reason to do ordered ruleset, we have 
one: simplicity.

--julien

> >>> => Like I said earlier, the graceful way of handling this is for
> >>> the receiver to break the tie. We need to require this capability
> >>> anyway for the receiver, that's why I don't see a need for unique
> >>> PRI.
> >>
> >> I could live with a tie break mechanism but, as a sender I
> >> wouldn't like to believe the tie was broke left while the sender
> >> actually broke it right. Thus if we rely on tie break, I'd rather
> >> have us specify how that works, which in turns imply that we
> >> define a sub-order among rules with same priority. I do not see
> >> the point but...
> >
> > => I agree there would be no point in doing that but the question
> > is why is the sender sending the same priority? May be it doesn't
> > care. So what if they broke the tie differently?
> >
> >> The simplest sub-ordering scheme I can come up with is, for every
> >> set of rules with same priority: the earliest rule established
> >> prevails on other, while rule A is earlier than rule B if 1) rule
> >> A in is a BU send before the BU that contains rule B, or 2) rule A
> >> is placed before rule B in the same BU.
> >>
> >> To me this is more complex while the end result is not that
> >> different from rules with unique priorities, since in both case we
> >> do define a total order amongst rules.
> >
> > => I think if we have to make it unique then unique PRI is the way
> > to do it. But my point is that doesn't eliminate the need for a tie
> > breaker as a graceful fallback. I can't see the harm in a different
> > tie break at either end. What am I missing?
> >
> >>> Furthermore, there can be cases where the MN simply doesn't care
> >>> and allows the HA to decide which one goes where.
> >>
> >> I do not understand why would the MN put forth two overlapping
> >> rules in the first place if it doesn't care...
> >
> > => Because it's installing the rule and it doesn't care *now*. May
> > be later it will change it. I don't have a concrete example but
> > given that this is done by upper layers I'd rather err on the side
> > of flexibility provided that no harm is done. So my question to you
> > is: What harm do you see?
> >
> > Hesham
> >
> >> --julien

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 11 May 2009 14:26:22 +0100

> signalling, and the priority needs not to be exposed to ULPs.

GT> I am sure I lost your point because what I understand from the
text you quote exactly the same point I am making i.e., when you put
together a classifier you need to understand when rules overlap. What
do ULPs have to do with anything?

> I disagree. Ordered list is just simple since I do not need to determine

GT> I think we are getting horribly confused. What I propose is that
rules are ordered. Overlapping rules should have different PRI to
indicate the order. It is non-overlapping rules that are next to each
other that do not need different PRIs since the order does not matter.

> Hmmm... makes no difference with what? with another random order?

GT> It makes no different whether all rules have different PRIs or
some have the same PRI.

> want to prioritize over 20 or not.

GT> of course, it was just an example.

> ruleset to be ordered. As to the reason to do ordered ruleset, we have

GT> Julien, there is no difference at the level of simplicity that I
can see. Lets put this differently. Do you agree that for the receiver
i.e., the HA/CN whether some rules have the same PRI or not it makes
no difference? i.e., it is no simpler or complicated to implement that
HA/CN part of this? If yes, then it is up to the implementer of the MN
to decide whether he/she wants to use the same PRI for non-overlapping
rules (as the draft suggests) or if all rules have different PRIs (as
you/Christian seem to prefer). This way we leave it flexible without
hurting interoperability.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 17:56:57 +0200

Hi George,

On Monday 11 May 2009, George Tsirtsis wrote:
> >> placed in the list and without understanding which ones overlap
> >> and which are not. The MN MUST be able to do this, otherwise there
> >> is no way to impose the desired behaviour.
> >
> > You can build a classifier in which rules are ordered and the
> > classifier needs not to determine overlaps, which is incidentaly
> > what IPsec does, see this excerpt from 4301:
> >
> >   The SPD is an ordered database, consistent with the use of
> > Access   Control Lists (ACLs) or packet filters in firewalls,
> > routers, etc.   The ordering requirement arises because entries
> > often will overlap   due to the presence of (non-trivial) ranges
> > as values for selectors.   Thus, a user or administrator MUST be
> > able to order the entries to   express a desired access control
> > policy.  There is no way to impose a   general, canonical order
> > on SPD entries, because of the allowed use   of wildcards for
> > selector values and because the different types of   selectors are
> > not hierarchically related.
> >
> > In that sense the priority is just a way to express within the MN -
> > HA signalling, and the priority needs not to be exposed to ULPs.
>

(Sorry, forget the ULPs)

When I read the 4301 excerpt, it says *all* rules are ordered 
(overlapping or not), precisely to avoid issues with what to do when 
there's an overlap. Thus there's no need for an implementation to 
determine whether or not there's an overlap because the ordering solve 
the issues.

More below:

> >> Now also consider that whether we require a unique PRI or not, the
> >> MN again will have to know the above. If you require unique PRI,
> >> the MN will have to decide the order of overlapping rules. If we
> >> allow more than one rule to have the same PRI, the MN will have to
> >> decide which rules are not overlapping and thus they can take the
> >> same value.
> >
> > I disagree. Ordered list is just simple since I do not need to
> > determine overlaps b/w rules.
>
> rules are ordered. 

So it seems we both agree that rules are ordered, but...

> Overlapping rules should have different PRI to 

then you're saying non-overlapping rules need not to be ordered because 
it does not matter. So three things:

1. To me this is in contradiction with the fact that rules are ordered. 
What you're saying is that there's a partial order only.

2. It means you need a way to determine whether rules are overlapping or 
not, otherwise how do you enforce that different PRIs are assigned to 
overlapping rules? Or you do not enforce it at all? I'm confused.

3. I disagree that it doesn not matter that rules have same priority 
when rules are not overlapping because the MN and HA might end up with 
different way of breaking the tie (as Hesham put it IIRC), thus MN and 
HA will have different ordered list. If the MN request a specific 
ordered ruleset, the HA should have the same ordered ruleset, not a 
different one that you pretend is equivalent...

> >> according to PRI. Rules with the same PRI will be placed in a
> >> random order between them, since it makes no difference.
> >

See above - I believe there's a difference.

[...]

> >> Again, I am not saying the above presents a significant advantage
> >> but only that this is how all classifiers work in existing
> >> implementations and thus we should not do something different
> >> unless we have a really good reason, which IMO we do not.
> >
> > Some classifiers may work as you say, but others (including IPsec
> > and some firewalls) do not, thus I disagree we would be doing
> > something different by requiring a priority to be unique, i.e.,
> > requiring the ruleset to be ordered. As to the reason to do ordered
> > ruleset, we have one: simplicity.
>
> can see. Lets put this differently. Do you agree that for the
> receiver i.e., the HA/CN whether some rules have the same PRI or not
> it makes no difference? i.e., it is no simpler or complicated to
> implement that HA/CN part of this? If yes, then it is up to the
> implementer of the MN to decide whether he/she wants to use the same
> PRI for non-overlapping rules (as the draft suggests) or if all rules
> have different PRIs (as you/Christian seem to prefer). This way we
> leave it flexible without hurting interoperability.

I do not agree it makes no difference because 1) you need to detect 
overlapping rules to pop-up an error when they are set-up, and 2) for 
non-overlapping rules, the MN cannot determine in a deterministic way 
in which way they are ordered by the HA/CN, and vice versa. This is a 
key difference I'd need to highlight with what happens on a local 
classifier (e.g. a firewall) w.r.t priorities, in which case there's no 
ambiguity on the order in which rule with same priorities are 
handled -- they are handled in the order in which they were added. 
Quoting from ipfw(8) "Multiple rules can have the same number, in which 
case they are checked (and listed) according to the order in which they 
have been added."

Does that help? Or are we indeed standing by antipodes?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 02:01:21 +1000

> handled 

=> You didn't answer my question about the harm done when the tie is broken
differently on either side. What harm do you see?

Hesham

-- they are handled in the order in which they were added.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 18:07:59 +0200

On Monday 11 May 2009, Hesham Soliman wrote:
> > overlapping rules to pop-up an error when they are set-up, and 2)
> > for non-overlapping rules, the MN cannot determine in a
> > deterministic way in which way they are ordered by the HA/CN, and
> > vice versa. This is a key difference I'd need to highlight with
> > what happens on a local classifier (e.g. a firewall) w.r.t
> > priorities, in which case there's no ambiguity on the order in
> > which rule with same priorities are handled
>
> => You didn't answer my question about the harm done when the tie is
> broken differently on either side. 

Sorry Hesham, overlooked that.

> What harm do you see? 

It is not deterministic and not explicit. An implementor could suppose 
that the order in which he breaks the tie is the logical one (e.g. 
first rule added prevails as often) and expect that order to be 
followed by its peer implementation. 

--julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 11 May 2009 18:12:46 +0200

On Monday 11 May 2009, Hesham Soliman wrote:
> broken differently on either side. What harm do you see?

Silly to reply to myself, but I after more thinking I concluded there is 
no harm indeed. Sorry that it took me so long to get that point. So 2) 
above no longers hold. 

How about 1)... do you agree that overlapping rules requires an 
implementation to take all duple of rule with same priority and check 
whether they overlap or not?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 02:15:06 +1000

> followed by its peer implementation.

=> Yes I understand that this may well happen, but what's the consequence of
that? What you describe above is not in itself harmful.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 02:17:59 +1000

> whether they overlap or not?

=> Yes, I agree with that. However, I agree with George that you will have
to do that anyway to avoid giving the wrong PRIs for overlapping rules. I
mean, if there is overlap then you need to prioritise what happens to the
traffic falling in that overlap. And you cant do that without determining
that an overlap exists. Does that make sense?

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 May 2009 14:53:18 +0200

Hi Hesham,

On Monday 11 May 2009, Hesham Soliman wrote:
> >>> I do not agree it makes no difference because 1) you need to
> >>> detect overlapping rules to pop-up an error when they are set-up,
> >>> and 2) for non-overlapping rules, the MN cannot determine in a
> >> => You didn't answer my question about the harm done when the tie
> >> is broken differently on either side. What harm do you see?
> >
> > Silly to reply to myself, but I after more thinking I concluded
> > there is no harm indeed. Sorry that it took me so long to get that
> > point. So 2) above no longers hold.
> >
> > implementation to take all duple of rule with same priority and
> > check whether they overlap or not?
>
> => Yes, I agree with that. However, I agree with George that you will
> have to do that anyway to avoid giving the wrong PRIs for overlapping
> rules. I mean, if there is overlap then you need to prioritise what
> happens to the traffic falling in that overlap. And you cant do that
> without determining that an overlap exists. Does that make sense?

It seems we're making progress. 

I agree that the overlap needs to be determined at some level, but I 
think we disagree on the level. 

I think the choice of a specific ordering of overlapping rules doesn't 
belong to the MIPv6 layer. In my view it is a policy problem and has to 
be sorted by a much more complex machinery than the MIPv6 stack, maybe 
a human being and common sense are required.

The MIPv6 layer should simply have to deal with an ordered set of rules, 
which might overlap or not, not the problem of the MIPv6 layer since 
they are ordered.

The situation would then be similar to that of a firewall or an IPsec 
SPD. The administrator has to determine an order for rules based on a 
given policy, then the stack simply enforces it.

Am I making any sense?

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 23:11:07 +1000

Hi Julien,

> a human being and common sense are required.

=> I'm not sure about a human being :) but I agree with you that it's done
on a higher layer. MIPv6 doesn't know what policies are needed by the apps
...etc

> which might overlap or not, not the problem of the MIPv6 layer since

=> Agreed. 

> given policy, then the stack simply enforces it.

=> Yes. The question is related to how MIPv6 translates the order that it
was given by others. I'm happy with the logic above, however, I always get
stuck on (potentially silly?) corner cases. For instance, we were discussing
mobile routers when we were updating the draft and how in some cases they
can potentially send policies for a very large group of MNs. Now, it is
possible that the PRI field runs out of space in those cases. It is also
very likely that the rules don't overlap across different MNs. So, in a
scenario like that it is worth reusing the PRI field for rules that don't
overlap. We can also make it very large I suppose.

In any case, I agree with your functional breakdown above and don't see a
problem with making it unique except for the problem above. Do you think
it's an issue? If others can think of any other scenarios please let us
know. Absent that, I was going to suggest that _at least_ overlapping rules
must have unique PRIs.
It's a but difficult to be concrete about scenarios when we don't have an
API to a policy engine to work with.

Either way, I think we need to make this requirement, or context clear in
the draft (I mean where the filters are created and ordered ...etc).

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Wed, 13 May 2009 15:07:48 +0200

Hi Hesham,

On Tuesday 12 May 2009, Hesham Soliman wrote:
> > I agree that the overlap needs to be determined at some level, but
> > I think we disagree on the level.
> >
> > I think the choice of a specific ordering of overlapping rules
> > doesn't belong to the MIPv6 layer. In my view it is a policy
> > problem and has to be sorted by a much more complex machinery than
> > the MIPv6 stack, maybe a human being and common sense are required.
>
> => I'm not sure about a human being :) but I agree with you that it's
> done on a higher layer. MIPv6 doesn't know what policies are needed
> by the apps ...etc
>
> > The MIPv6 layer should simply have to deal with an ordered set of
> > rules, which might overlap or not, not the problem of the MIPv6
> > layer since they are ordered.
>
> => Agreed.
>
> > The situation would then be similar to that of a firewall or an
> > IPsec SPD. The administrator has to determine an order for rules
> > based on a given policy, then the stack simply enforces it.
> >
> > Am I making any sense?
>
> => Yes. The question is related to how MIPv6 translates the order
> that it was given by others. I'm happy with the logic above, however,
> I always get stuck on (potentially silly?) corner cases. For
> instance, we were discussing mobile routers when we were updating the
> draft and how in some cases they can potentially send policies for a
> very large group of MNs. Now, it is possible that the PRI field runs
> out of space in those cases. It is also very likely that the rules
> don't overlap across different MNs. So, in a scenario like that it is
> worth reusing the PRI field for rules that don't overlap. We can also
> make it very large I suppose.

Thanks for pointing out the usecase, I see now.

> In any case, I agree with your functional breakdown above and don't
> see a problem with making it unique except for the problem above. Do
> you think it's an issue? If others can think of any other scenarios
> please let us know. Absent that, I was going to suggest that _at
> least_ overlapping rules must have unique PRIs.
> It's a but difficult to be concrete about scenarios when we don't
> have an API to a policy engine to work with.

The part that disturb me is the fact that if you say "overlapping rules 
must have unique PRIs" then I somehow need to be able to determine the 
overlaps so that I know what to do with the priorities. I'd prefer that 
we make it all or nothing, that is:

1. Rules (overlapping or not) have unique PRIs, or

2. Rules (overlapping or not) can have same PRIs, rule with priority P 
established earlier prevail over rules with same priority P established 
latter.

In this way an implementation would not be required to determine whether 
there's an overlap or not.

That would of course not preclude the operator, administrator, 
application or MIP stack to determine whether there's an overlap and 
what to do with it.

> Either way, I think we need to make this requirement, or context
> clear in the draft (I mean where the filters are created and ordered
> ...etc).

Sounds like a plan.

Thanks for discussion Hesham.

--julien