Subject: Re: [MEXT] flow binding draft 2

From: Christian Kaas-Petersen <[email-masked]>
Date: Mon, 11 May 2009 09:22:37 +0000 (GMT)

If two rules can have the same PRI, then a kind of 
hierarchical classifier is constructed: At the top level the
PRI is used, at the bottom level a yet unspecified mechanism is 
used to select amongst the rules with the same PRI.

Decisions about which rules overlap and which don't will
become more and more complex over time when the "language"
for expressing the rules become more and more complex.
Binary filters is one such language, but other languages
have been mentioned.

Unless there is a good use case describing the need for
two or more rules with the same PRI, as an implementer I
should like to stick to the simplest case of uniqueness of PRI
values, and in case a new rule is sent using a PRI already assigned
to another rule, such a rule should not be installed,
and an error code should be returned to the mobile node.

Christian

--- Den søn 10/5/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] flow binding draft 2
> Til: "Hesham Soliman" <[email-masked]>
> Cc: "Julien Laganier" <[email-masked]>, [email-masked]
> Dato: søndag 10. maj 2009 14.36
> 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
> 
> 
> On Fri, May 8, 2009 at 2:04 PM, Hesham Soliman <[email-masked]>
> wrote:
> >
> >>> => 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
> >
> >
> >
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 

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