Subject: Re: [MEXT] offline Re: binary filters draft 0

From: Julien Laganier <[email-masked]>
Date: Thu, 7 May 2009 17:21:37 +0200

On Thursday 07 May 2009, George Tsirtsis wrote:
> Hey Julien,
>
> I think what you propose is still difficult.
> This is already a very complex option given that all fields are
> optional and their presence is indicated by flags.
> Then at the end of the option we have pointers of which we can have
> many. Calculating the length of each of these is already tricky, but
> adding a 2nd type of pointer makes it even harder.
> How do you know which type of pointer it is? 

Two solutions, either 1) a pointer is typed with the first bit 
indicating its type (0 is byte-word-range, 1 is bit-pattern), or 2) we 
include two fields in the base header to indicate the number of 
byte-word-range pointers, and another to indicate the number of 
bit-pattern pointers.
 
> and how do you know the length of the 2nd one given your format?

The 2nd one has a fixed length since it only indicates matching on a 
pattern on one byte: 2(offset) + 1(mask) + 1 (value) = 4.

> Do you really think any of this is necessary or did the pointers idea
> just excited your imagination? :-)

Am I allowed to reply "both" :-)

Since I do not see the above as overly complex it could make sense to 
allow for possible future usages. But I would not insist if nobody 
thinks it's useful (and see below)

I've been searching and I found one that might or might not look 
realistic :-) 

Suppose we have an SCTP assocation running a multiple streams running 
inside, I'd like to be able to n-cast only the SCTP packets that 
contains only unordered data chunks, as indicated by the U bit within a 
data chunk:

      The (U)nordered bit, if set to '1', indicates that this is an
      unordered DATA chunk, and there is no Stream Sequence Number
      assigned to this DATA chunk.  Therefore, the receiver MUST ignore
      the Stream Sequence Number field.

> To be honest, the pointers are probably just a 'cool' thing that is
> likely to be used *very* infrequently. The only reason I came up with
> it is to remove the perception that binary filters are inflexible,
> when compared to Conny's text based filters.

Should we remove the pointers all together then?

--julien

> On Thu, May 7, 2009 at 3:15 PM, Julien Laganier
>
> <[email-masked]> wrote:
> > On Thursday 07 May 2009, Julien Laganier wrote:
> >> > Hi Julien,
> >> >
> >> > This is not a bad idea. We are increasing complexity though. One
> >> > thing that bothers me with bit based pointers is byte alignment,
> >> > which can no longer be assured.
> >> >
> >> > I think we should be careful not to go crazy with these.
> >> > Pointers, in their current simple form, already give increased
> >> > flexibility to the binary filters.
> >> >
> >> > If this flexibility proves insufficient some time in the future,
> >> > we can always come back and define another flow description
> >> > sub-option that it either allows for more complex pointers or
> >> > offers more flexibility in some other way.
> >> >
> >> > For now, I would prefer to keep it relatively simple.
> >> >
> >> > Thoughts?
> >> >
> >> > George
> >>
> >> Hello Georges,
> >>
> >> You're right - this one-size-fits-all pointer is way too complex.
> >> How about defining two pointers, a "bit pattern" to match on some
> >> bits on a byte boundary, and a "byte-word-range" one to match some
> >> byte-aligned field on a range basis.
> >>
> >> Rough strawmans would look like:
> >
> > Of course I messed up the second one for bit mattern, see an update
> > below.
> >
> >       0                   1                  
> > 2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3
> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
> >            |           Offset              |  
> >  Length     |    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |      Start Value ...                      
> >                    |    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |               |         End Value ...    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >                              Figure 2a: Byte Word
> > Range Pointer
> >
> >       0                   1                  
> > 2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3
> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1                    
> >  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          
> >            |           Offset              |  
> >  Mask       |    
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     |   Value       |
> >     +-+-+-+-+-+-+-+-+
> >
> >                              Figure 2b: Bit pattern
> > Pointer
> >
> > --julien

-- 
--julien

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 May 2009 16:54:28 +0100

Julien already assured me he is not in the habit of forwarding private
e-mails back to the public list :-)
In any case, I took this off line to see if I can resolve the issues
directly with Julien before coming back to the list so, no harm done.

It seems that the granularity of pointers needs to be discussed
further which is fine.

We also need to discuss whether the granularity of the pointers
described in the draft provide sufficient flexibility, in which case I
believe that text based flow description offers little further
advantage.

I maintain that such flexibility, whether provided by pointers or by
other means, is something that is not often going to be needed. At
least pointers, and the fact that multiple of them can be present in
the binary flow description, provide a powerful way of matching
virtually any field in the packet, in the rare case this is necessary;
while limitting verbosity in all cases.

Thoughts?
George

On Thu, May 7, 2009 at 4:21 PM, Julien Laganier
<[email-masked]> wrote:
>> > Â  Â  Â  0 Â  Â  Â  Â  Â  Â  Â  Â  Â  1 Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > 2 Â  Â  Â  Â  Â  Â  Â  Â  Â  3 Â  Â  Â  0 1 2 3 4 5 6 7 8 9 0 1 2 3
>> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > Â +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Â  Â  Â  Â  Â
>> > Â  Â  Â  Â  Â  Â | Â  Â  Â  Â  Â  Offset Â  Â  Â  Â  Â  Â  Â | Â
>> > Â Length Â  Â  | Â  Â
>> > Â +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > Â  Â  Â | Â  Â  Â Start Value ... Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â | Â  Â
>> > Â +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > Â  Â  Â | Â  Â  Â  Â  Â  Â  Â  | Â  Â  Â  Â  End Value ... Â  Â
>> > Â +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> >
>> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Figure 2a: Byte Word
>> > Range Pointer
>> >
>> > Â  Â  Â  0 Â  Â  Â  Â  Â  Â  Â  Â  Â  1 Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > 2 Â  Â  Â  Â  Â  Â  Â  Â  Â  3 Â  Â  Â  0 1 2 3 4 5 6 7 8 9 0 1 2 3
>> > 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > Â +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Â  Â  Â  Â  Â
>> > Â  Â  Â  Â  Â  Â | Â  Â  Â  Â  Â  Offset Â  Â  Â  Â  Â  Â  Â | Â
>> > Â Mask Â  Â Â  Â | Â  Â
>> > Â  Â  | Â  Value Â  Â  Â  |
>> > Â  Â  +-+-+-+-+-+-+-+-+
>> > Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â Figure 2b: Bit pattern
>> > Pointer
>> >
>> > --julien
>
>
>
> --
> --julien
>

---

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

I agree that pointers are not going to be an essential, or frequently used,
feature as far as we know today. On the other hand, allowing the capability
is not very problematic. All the fields in the filter are optional anyway,
so I don't see too much of a problem in allowing this and the worste outcome
could be that it's never used.
I don't have a strong opinion on which form of pointer to allow, but FWIW,
the second option that Julien sent makes more sense than the first one he
sent :)

Hesham

> Julien already assured me he is not in the habit of forwarding private
e-mails
> back to the public list :-)
In any case, I took this off line to see if I can
> resolve the issues
directly with Julien before coming back to the list so, no
> harm done.

It seems that the granularity of pointers needs to be
> discussed
further which is fine.

We also need to discuss whether the
> granularity of the pointers
described in the draft provide sufficient
> flexibility, in which case I
believe that text based flow description offers
> little further
advantage.

I maintain that such flexibility, whether provided
> by pointers or by
other means, is something that is not often going to be
> needed. At
least pointers, and the fact that multiple of them can be present
> in
virtually
> any field in the packet, in the rare case this is necessary;
while limitting
> verbosity in all cases.

Thoughts?
George

On Thu, May 7, 2009 at 4:21 PM,
> Julien Laganier
<[email-masked]> wrote:
>> Then at
> the end of the option we have pointers of which we can have
>> many.
> Calculating the length of each of these is already tricky, but
>> adding a 2nd
> bit-pattern
> pointers.
>> Do you
> really think any of this is necessary or did the pointers idea
>> just excited
> your imagination? :-)
>
> Since I do not
> see the above as overly complex it could make sense to
> allow for possible
> future usages. But I would not insist if nobody
>> To be honest, the
> pointers are probably just a 'cool' thing that is
>> likely to be used *very*
> infrequently. The only reason I came up with
>> >> > This is not a bad
> idea. We are increasing complexity though. One
>> >> > thing that bothers me
> with bit based pointers is byte alignment,
>> >> > which can no longer be
> assured.
>> >> >
>> >> > If this
> flexibility proves insufficient some time in the future,
>> >> > we can always
> come back and define another flow description
>> >> > sub-option that it
> either allows for more complex pointers or
>> >> Hello
> Georges,
>> > Â  Â 
> Â | Â  Â  Â Start Value ... Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â
>> > Â  Â  Â  Â 
> Â  Â  Â  Â  Â  Â | Â  Â
>> >
>> > Â  Â 
> Â | Â  Â  Â  Â  Â  Â  Â  | Â  Â  Â  Â  End Value ... Â  Â
>> >
>> > 2 Â  Â  Â  Â  Â 
> Â  Â  Â  Â  3 Â  Â  Â  0 1 2 3 4 5 6 7 8 9 0 1 2 3
>> > 4 5 6 7 8 9 0 1 2 3 4
>> > Â  Â 
> Â  Â  Â  Â | Â  Â  Â  Â  Â  Offset Â  Â  Â  Â  Â  Â  Â | Â
>> > Â Mask Â  Â Â 
> Â | Â  Â
>> > 
>> > Â  Â  |
> Â  Value Â  Â  Â  |
_______________________________________________
MEXT mailing
> list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Yungui Wang <[email-masked]>
Date: Fri, 08 May 2009 11:30:30 +0800

Hello

Two comments.

1.The unit length is 8-octet in the FID mobility option. 
It is very possible that the real option in BU may be 
not n*8 octet. Thus, a new pad sub-option may 
need to be defined in the draft.

2.The FID mobility option is a common mobility option. 
As discussed before, either MN or HA may initiate the 
flow binding in a certain case. (Personally I think it is 
possible for HA to initiate flow binding). That's, either 
MN or HA may assign FID(s) for different flows. 
However, in this case, the FID may be overlapped 
when both MN and HA are initiating different flows. 
So I think avoiding said collision should be considered.

B.R.  
Yungui

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 08 May 2009 14:56:06 +1000

> flow binding in a certain case.

=> No, only the MN can initiate it.

(Personally I think it is
> So I think avoiding said collision should be considered.

=> The collision is not possible because only the MN initiates it.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Fri, 08 May 2009 15:20:25 +0800

Hello

Please see solution requirement from MEXT charter...
''
- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].
"

And some requirements from 3GPP 23.861 for your information.
"
...
- It should be possible for the operator to enable and control the 
simultaneous usage of multiple accesses.
- It should be possible for the operator to enable and control the 
flow mobility.
...
"

Above information makes me believe it is possible that HA may 
initiate the flow binding. What do you assure that only MN does? 

B.R.  
Yungui

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Friday, May 08, 2009 12:56 PM
> To: [email-masked]; 'George Tsirtsis'
> Cc: [email-masked]; 'Julien Laganier'
> Subject: Re: new pad sub-option and flow identifier assignment
> 
> 
> >

---

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

> transport [both Standard Track].

=> We're not talking about policies in this draft, we're talking about
transporting filters. We discussed this many times. Policies can associate a
flow on with a link layer, interface ...etc on a high level. Filters install
instances of such policies. It's not the same thing.

> - It should be possible for the operator to enable and control the

=> That's fine but:
1. "control" is meaningless to me, and,
2. We are developing a spec for the entire Internet.

An operator's HA can communicate policies all day to the MN, but installing
filters from the MN to HA is what we define in the spec. Control can mean
many things and if by that "control" the HA would reject a BU that doesn't
comply to its policies that's fine by me.

> initiate the flow binding. What do you assure that only MN does?

=> This is how MIPv6 works and the right way of doing things if you want
them to work in multi-access environments. It's not about what's possible,
it's about the best way of doing it.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Mon, 11 May 2009 09:04:35 +0800

Hello 

> Sent: Friday, May 08, 2009 5:52 PM

Thanks for your explanation, you are very good at basic accept.
Of course, policy is not flow filter. However, flow filter can be 
generated based on policy. For example, in 3GPP, when PCC 
rules(policy) are downloaded to HA from PCRF, HA can generate 
flow filters. What I adduced was blow point 
> > A "Flow/binding policies exchange" solution for an exchange of
> > policies from ... and from the
> > Care-of Address and Home Agent address.
for I was doubting your point "only the MN can initiate it(flow binding)".

> 2. We are developing a spec for the entire Internet.

Yeah, I agree you 'We are developing a spec for the entire Internet.'
However, if this spec can't address the basic requirements, I don't 
think it is mature. Here, HA initiating flow binding/handover is the 
just one of the basic requirements. 

> filters from the MN to HA is what we define in the spec. 

We should meet requirement from Charater and actual operation. 
Obviously, according to Charter and actual operation, installing 
flow filters from HA to MN should be addressed too.

> Control can mean

That's your personal understanding. In my mind, here "Control" 
means that HA can not only reject a BU, but also initiate a flow
binding/handover based on policy, etc. 

B.R.
Yungui

---

From: Michael Eriksson <[email-masked]>
Date: Mon, 11 May 2009 13:43:28 +0200

> believe that text based flow description offers little further

Well, a text format has a number of advantages:

- It is easier to generate (think printf).

- It is less complex (cf. your bit vector).

- Static flow rules are simple, just edit them the with your favorite
  text editor.

- It is easier to debug. IETF has a history of text protocols (SMTP,
  NNTP, HTTP, SIP, ...), and that is for a good reason.

- It is easier to extend.

On the other hand, what advantages would you say a binary format has?
The only one that I can think of is that it may save a few bytes in
some cases, but I fail to see any reasonable use case where this would
matter at all.

Regards,
Michael

---

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

Hello Michael,

On Monday 11 May 2009, Michael Eriksson wrote:
> > described in the draft provide sufficient flexibility, in which
> > case I believe that text based flow description offers little
> > further advantage.
>

In my view this is a blanket statement. IMHO memcpy() et al. are simpler 
than printf.

> - It is less complex (cf. your bit vector).

Again, IMHO a blanket statement. I'd rather parse a well defined simple 
binary format than text. The bit and byte vector I proposed are 
straightforward and simple in my view.

> - Static flow rules are simple, just edit them the with your favorite

The average user is never going to edit any flow rules, thus I do not 
think that the ability to edit them with a text editor is key (My mom 
doesn't know what text is -- she uses Word :-). Even if it was, one can 
simply build a tool that takes binary and output text and vice versa.

>   NNTP, HTTP, SIP, ...), and that is for a good reason.

To me this looks like comparing apple and oranges. The protocols you're 
citing above are all application layer protocol. We are talking here 
about a network layer protocol. Do you know many network layer (or even 
transport) IETF protocols that use text encoding?

> - It is easier to extend.

Again, IMHO a blanket statememt, and YMMV.

> some cases, but I fail to see any reasonable use case where this
> would matter at all.

See above, I disagree with you that a text format is at advantages over 
a binary format. 

In my view the binary format only has advantages, it is simpler to 
generate, to parse, it conforms to the way IETF builds network layer 
protocols, and as you note, has a more bandwidth efficient encoding. 

--julien

---

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

I second Julien on this. You seem to be thinking of this as some user
level protocol where the user will take his mobile device and start
punching in flow descriptors by hand. This is far from reality in the
use cases I am looking at.
Instead, Mobile IP is a low level protocol that has more to do with
routing protocols than HTTP and SIP.

I think there is merit in a text based classifier and as I have said
before I am not opposed to such flow descriptors be optionally
supported. I would consider using such a flow descriptor in some
scenarios, e.g., semi-stable connectivity scenarios (i.e, multihoming,
rather than full mobility), where I also happen to want high
flexibility and regular user input. But this cannot be the default
usecase for MIP. MIP is a mobility protocol that should allow fast
handoffs changing situations using a small set of possible
links/accesses and a limitted number of apps. In this case I want
binary format to handle a small number of rules as efficiently as
possible.

George

---

From: Michael Eriksson <[email-masked]>
Date: Mon, 11 May 2009 20:54:24 +0200

> In my view this is a blanket statement. IMHO memcpy() et al. are simpler 

I can't see how this is simpler than printf. With printf you normally
just need one single statement to output a complete rule.

> straightforward and simple in my view.

There are well established methods for parsing text with formal
grammars (e.g., by using lex and yacc). Binary parsing is ad hoc, hand
coded and rather error prone.

If you want more arguments for why the binary format is more complex,
see the ongoing discussion on how the HA should select between
overlapping binary rules. For the text format, this is trivial: The
rules are evaluated in strict order.

> simply build a tool that takes binary and output text and vice versa.

OK, I don't expect your mother to edit her flow rules :-). But maybe
trained experts will. In your case, you would have to start with
defining the text format. And then develop and debug the tool. Doesn't
that seem a bit awkward?

> transport) IETF protocols that use text encoding?

No, exchanging flow rules is not a network layer protocol! It is a
network control protocol, and is done on the "application" layer (or
the control plane, as it is called in other architectures).

> Again, IMHO a blanket statememt, and YMMV.

No, compare the versions -00 and -01 of
draft-larsson-mext-flow-distribution-rules for instance. We added
support for IPv4 in -01, with very minimal changes to the language.

Your binary format, on the other hand, has two completely separate
formats for IPv4 and IPv6 rules.

> protocols, and as you note, has a more bandwidth efficient encoding. 

I obviously disagree with most of these views (and even object to your
reasoning regarding the "network layer protocol"). The binary format
may at times be somewhat more compact, but I still fail to see any
reasonable use cases where this would matter at all.

Regards,
Michael

---

From: Michael Eriksson <[email-masked]>
Date: Mon, 11 May 2009 21:44:57 +0200

> routing protocols than HTTP and SIP.

No, I think that there are (mainly) two cases:

- A Connection Manager determines the rules to use. This of course
  takes some high level "intelligence", and it can be easier for such
  a module to output its decisions in a high level text format (with
  printf) than to intermix decision making with bitfiddling.

- A semi-static case, where rules are hardcoded by humans. Of course
  not the end users (unless they are certified nerds), but by someone
  who is managing the network connectivity of the device.

For both these cases, a text format is more suitable.

> flexibility and regular user input.

It's nice that you see that the text format does have its merits.

I agree that we should start with just one rule format, but shouldn't
that be the most useful one?

> But this cannot be the default usecase for MIP. MIP is a mobility
> protocol that should allow fast handoffs changing situations using a
> small set of possible links/accesses and a limitted number of apps.
> In this case I want binary format to handle a small number of rules
> as efficiently as possible.

We are trying to define a control protocol. It is used at the
"application" level (or control plane as it is called in other
architectures).

I think you are vastly suboptimizing when arguing that a binary format
is "more efficient". Some questions:

- How often do you think that these flow routing rules will be
  updated?

- How much bandwidth is available between the rule updates? That is,
  how much of the available bandwidth will be used for rule updates?

- How much higher (if any) do you think the cost is to encode and
  parse a text format compared to a binary format? What is the
  relation between this cost and the cost to determine (at MN) and
  install (at HA) these rules?

If you really want to be more efficient, I think that you should focus
on separating the rule updates from the binding updates.
Resending/refreshing all rules, whether in binary or text format, at
every handover is wasteful -- both in terms of transmitted bytes and
computing effort.

Regards,
Michael

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 11 May 2009 21:19:27 +0100

> rules are evaluated in strict order.

GT> It is good to have a debate about this but please take some care
with your arguments so we can converge one of these days. The
discussion about ordering rules is independent from the binary vs text
based debate. The PRI field is part of the FID option and will apply
equally to binary and text filter rules which will be in sub-options.
Ordering of such rules has the same issues no matter what you do to
code them. e,g, if your aim is to have a rule that matches all TCP
flows and another rule to match all flows from IPAddr=IPx, these rules
will overlap and thus their relative order will matter, whether you
code them in text or in binary.

George

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 May 2009 16:25:47 -0700 (PDT)

Hi Michael,

[behcet] I think you have draft-eriksson-mext-mipv6-routing-rules-00.txt in mind here. They are used to transport the routing language sentences used to establish the flows. Doing this for every handoff could be wasteful, I agree but flow bindings as in draft-ietf-mext-flow-binding-02.txt need to refreshed for every handoff. Even the rules for which the CoA has changed may need to be retransported.
 
Regards,
 
Behcet

---

From: Michael Eriksson <[email-masked]>
Date: Tue, 12 May 2009 08:15:28 +0200

On Mon, May 11, 2009 at 22:19:27 +0200, George Tsirtsis wrote:
> with your arguments so we can converge one of these days.

OK, I'll try to be careful.

But I do appreciate an open and unrestricted debate with technical
arguments. Previously, some objections to the old solution got quite
weak counter arguments like "[...] departures from the current
agreement", "in theory there is nothing preventing us from [...],
except from the fact that some of us might disagree..." and "Instead
of trying to reinvent the wheel, which will likely be futile, ...".

With the technical arguments on the table, and a good understanding of
all the alternative solutions, we can try to make the best possible
choice of solution. I could live with a binary format, if that is what
people really want when they understand the alternatives.

> The discussion about ordering rules is independent from the binary
> vs text based debate. The PRI field is part of the FID option and
> will apply equally to binary and text filter rules which will be in
> sub-options.

No, it is not -- or at least we don't want it to be. We have already
flagged that:

   The format in the flow-binding draft is very complex, and difficult
   to adapt to other rule formats than what it was originally designed
   for.

http://www.ietf.org/mail-archive/web/mext/current/msg03054.html

We could probably live with the flow-binding draft, but we want the
handling of individual rules to be specific to each flow rule format,
and not be specified in the flow-binding draft which should specify an
OPEN transport format.

> flows and another rule to match all flows from IPAddr=IPx, these
> rules will overlap and thus their relative order will matter,
> whether you code them in text or in binary.

The binary rules transmitted with the flow-binding mechanism has no
inherent order, unless you start to use the PRI field as some kind of
line number (this gives me severe BASIC flashbacks :-)).

The rules in the text format, on the other hand, are inherently
strictly ordered.

Regards,
Michael

---

From: Michael Eriksson <[email-masked]>
Date: Tue, 12 May 2009 08:24:49 +0200

> instances of such policies. It's not the same thing.

Hesham, you keep repeating this, but I think that you are playing with
words. I think that the use of the word "policies" in the charter is a
"vocabulary slip". There has been a lot of confusion between policies,
rules and similar terms. I claim that the charter was meant to say
"flow routing rules" where it says "policies" above.

Some observations:

- One of the WG chairs says that the flow-binding and routing rules
  drafts are meant for the charter item above.

  http://www.ietf.org/mail-archive/web/mext/current/msg03032.html

- The flow-binding draft has been accepted as WG document. What
  charter item would you say motivates this?

- No other work on "policies" has been initiated, even though it is on
  the WG charter.

> it's about the best way of doing it.

No, it is how YOU think that MIPv6 should work. Numerous people are
asking for support to transfer rules from HA to MN, and it is also
specified in the charter.

Regards,
Michael

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 16:34:57 +1000

> "flow routing rules" where it says "policies" above.

=> Please be careful with making such claims. You have zero evidence that
this was the intention in the charter. What works against your
interpretation is a couple of things:
1. The meaning of the word policy and how it's used
2. The fact that this charter was written based on monami6, nemo and mip6
charters and it was intended to inherit their WG docs.

So, you can interpret things as you see fit but I suggest you check those
facts before making strange accusations.

>   charter item would you say motivates this?

=> Please read the above. This was taken out of nemo and the charter was
written to accommodate the exact same docs that were WG items then.

> - No other work on "policies" has been initiated, even though it is on

=> So what? You can start that.

> No, it is how YOU think that MIPv6 should work.

=> It's pretty easy to verify how it works from RFC 3775. I'm not going to
debate a fact.

 Numerous people are
> specified in the charter.

=> The charter says POLICIES not rules. I don't know why you read that as
rules.

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 12 May 2009 16:27:48 +1000

=> FWIW, that discussion was not about flow formats, it was about the flow
bindings draft. We had many technical arguments on it from all points of
view. Like in any project, unless new reasons comes up, we shouldn't change
decisions used as fundamental assumptions.

> The rules in the text format, on the other hand, are inherently

=> But the ordering discussion was about find the order for routing purposes
especially for overlapping flows. It doesn't matter what format the flow is
in, the ordering needs to be done based on 1) determining whether an overlap
exists and 2) how the flows within such overlap get forwarded. I don't
understand how line order comes into this. Regardless of the format used,
this function has to be done.

Hesham

> MEXT mailing list

---

From: Michael Eriksson <[email-masked]>
Date: Tue, 12 May 2009 08:59:38 +0200

> facts before making strange accusations.

I don't think that it is interesting or relevant to be an
archaeologist and try to determine what was chartered in monami6 and
other concluded WGs.

I am focused on the current working group and its charter.

> >   http://www.ietf.org/mail-archive/web/mext/current/msg03032.html

This is pretty obvious evidence of how the charter is interpreted by
the WG chair. Doesn't that matter?

> written to accommodate the exact same docs that were WG items then.

Forget about NEMO, it is no longer active. The flow-binding draft was
accepted as a /mext/ draft. What mext charter item would you say
motivates this?

> => It's pretty easy to verify how it works from RFC 3775. I'm not going to

Come on, we are trying to extend MIPv6. Pointing at the current
specification is not really relevant, is it?

> => The charter says POLICIES not rules. I don't know why you read that as

You are playing with words, Hesham. Try to read the intended meaning
instead, which is obviously what the WG chairs and most other people
are doing.

Regards,
Michael

---

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

> I am focused on the current working group and its charter.

=> You seem to want to interpret meanings as you see fit so sometimes I
think it's important to understand how things ended up the way they are
before drawing conclusions about other people's motives.

> the WG chair. Doesn't that matter?

=> Did you read the message?? It says:

"For this deliverable we have:

draft-ietf-mext-flow-binding-01.txt defines the format part of the last
sentence in the paragraph above.

draft-larsson-mext-flow-distribution-rules and the other binary encoding (we
don't have a draft for this yet, right?) defines the policy format of the
last sentence of the charter paragraph above.

We all agree?

Regards, marcelo"

And yes we all agreed! Yes it includes the flow descriptions in
draft-larsson and the transport in draft-ietf-mext-flow-binding. What
exactly are you against in this message? Or what do you think I disagree
with? I'm really confused by this discussion...

> specification is not really relevant, is it?

=> You need to understand the spec in order to extend it! Of course it's
relevant. If you really understood the spec you would see that it's not
possible for the HA to initiate a binding. Let alone being able to know what
interfaces work on the MN. That's why I keep saying that the HA can send
policies all day long to the MN, but in the end, the MN has to decide what
instances it needs and install those on the HA's BC. Again, we had this
discussion at least twice already in monami6. Just because the WG was merged
doesn't mean the arguments should be forgotten.

> instead, which is obviously what the WG chairs and most other people

=> FYI, I'm not going to respond to future remarks like this one. This is
the second time you make this hollow comment.

Hesham

---

From: Yungui Wang <[email-masked]>
Date: Tue, 12 May 2009 15:31:51 +0800

Hello
 
> > => The charter says POLICIES not rules. I don't know why 
> > you read that as rules.
> 

At this point, I do think so too. In my understanding, below charter text
should be just effecting on flow binding, although I also agree policies 
are not rules. Is it a misunderstanding text? Maybe the writer can give 
a note here. 
"- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address. The solution involves two
specifications, one for the policy format and another for its
transport [both Standard Track].
"

B.R.  
Yungui

---

From: Yungui Wang <[email-masked]>
Date: Tue, 12 May 2009 15:40:02 +0800

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yungui Wang
> Sent: Tuesday, May 12, 2009 3:32 PM
> To: 'Michael Eriksson'; 'Hesham Soliman'
> Cc: [email-masked]
> Subject: Re: [MEXT] new pad sub-option and flow identifier assignment
> 
> Hello
>  
> At this point, I do think so too. 

Sorry, maybe misunderstanding. Here I just agree the last sentence. 
I am not agreeing that "You are playing with words, Hesham." 
On the contrary, I think, Hesham is very good at basis concept as
said before. :)

> In my understanding, below 
> charter text

---

From: "Yuri Ismailov" <[email-masked]>
Date: Tue, 12 May 2009 09:45:16 +0200

Hi all,
This discussion looks quite strange sinse there is a room for different
interpretations of the charter.
Once this is the case, should we sort out the charter so that there will
be a single interpretation of what is meant by policies, rules, etc.?
/yuri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hesham Soliman
Sent: Tuesday, May 12, 2009 9:25 AM
To: Michael Eriksson
Cc: [email-masked]
Subject: Re: [MEXT] new pad sub-option and flow identifier assignment

>> 
>> => Please be careful with making such claims. You have zero evidence 
>> that this was the intention in the charter. What works against your 
>> 1. The meaning of the word policy and how it's used 2. The fact that 
>> this charter was written based on monami6, nemo and mip6 charters and

>> it was intended to inherit their WG docs.
>> 
>> So, you can interpret things as you see fit but I suggest you check 
>> those facts before making strange accusations.
> 

draft-larsson-mext-flow-distribution-rules and the other binary encoding
(we don't have a draft for this yet, right?) defines the policy format
of the last sentence of the charter paragraph above.

We all agree?

Regards, marcelo"

>> => It's pretty easy to verify how it works from RFC 3775. I'm not 
>> going to debate a fact.
> 

=> You need to understand the spec in order to extend it! Of course it's
relevant. If you really understood the spec you would see that it's not
possible for the HA to initiate a binding. Let alone being able to know
what interfaces work on the MN. That's why I keep saying that the HA can
send policies all day long to the MN, but in the end, the MN has to
decide what instances it needs and install those on the HA's BC. Again,
we had this discussion at least twice already in monami6. Just because
the WG was merged doesn't mean the arguments should be forgotten.

>> => The charter says POLICIES not rules. I don't know why you read 
>> that as rules.
> 

=> FYI, I'm not going to respond to future remarks like this one. This
is the second time you make this hollow comment.

Hesham

---

From: Michael Eriksson <[email-masked]>
Date: Tue, 12 May 2009 10:40:22 +0200

> with? I'm really confused by this discussion...

How can you agree that the flow-binding draft is relevant for this
charter item, while you are also saying that the draft handles RULES
and the charter talks about POLICIES?

You also forgot to answer this question:

   The flow-binding draft was accepted as a /mext/ draft. What mext
   charter item would you say motivates this?

> relevant.

But where in the spec does it say that the HA can't send rules to the
MN, while it is OK for the MN to send rules to the HA?

> If you really understood the spec you would see that it's not
> possible for the HA to initiate a binding. Let alone being able to
> know what interfaces work on the MN. That's why I keep saying that
> the HA can send policies all day long to the MN, but in the end, the
> MN has to decide what instances it needs and install those on the
> HA's BC. Again, we had this discussion at least twice already in
> monami6. Just because the WG was merged doesn't mean the arguments
> should be forgotten.

I actually happen to think that I understand the spec, thanks for your
warm consideration...

It is correct that the CoA bindings are unidirectional. But the HA can
of course know what interfaces are working on the MN: It only has to
look in the binding cache! The MN will unregister any non-working CoA.

Regards,
Michael

---

From: Julien Laganier <[email-masked]>
Date: Tue, 12 May 2009 15:05:39 +0200

Hi Michael,

On Monday 11 May 2009, Michael Eriksson wrote:
> > In my view this is a blanket statement. IMHO memcpy() et al. are
> > simpler than printf.
>

and how many statements do you need to parse and validate? Also note 
that the number of statements is pretty much irrelevant since in the 
end what matters is that you have to move words in memory and there the 
printf will not do less...

> > Again, IMHO a blanket statement. I'd rather parse a well defined
> > simple binary format than text. The bit and byte vector I proposed
> > are straightforward and simple in my view.
>
> grammars (e.g., by using lex and yacc). Binary parsing is ad hoc,
> hand coded and rather error prone.

I do no think a network layer stack implementation is the place to 
implement formal grammars, parse and validate regular expressions.

> rules are evaluated in strict order.

I do not see the relevance of the rule ordering in this discussion.

> > > - Static flow rules are simple, just edit them the with your
> > > favorite text editor.
> >
> > The average user is never going to edit any flow rules, thus I do
> > not think that the ability to edit them with a text editor is key
> > (My mom doesn't know what text is -- she uses Word :-). Even if it
> > was, one can simply build a tool that takes binary and output text
> > and vice versa.
>
> defining the text format. And then develop and debug the tool.
> Doesn't that seem a bit awkward?

I don't think it is awkward, that sort of tool exist for IP routing, 
IPsec, firewalls, etc.  and they work nicely everyday in the hand of 
experts.

> > > - It is easier to debug. IETF has a history of text protocols
> > > (SMTP, NNTP, HTTP, SIP, ...), and that is for a good reason.
> >
> > To me this looks like comparing apple and oranges. The protocols
> > you're citing above are all application layer protocol. We are
> > talking here about a network layer protocol. Do you know many
> > network layer (or even transport) IETF protocols that use text
> > encoding?
>

control plane, application... what are talking about?

How are these flow rules different from an IPsec Traffic Selector? Does 
IKE uses text to transfer Traffic Selectors on-the-wire?

--julien

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 12 May 2009 08:59:52 -0500

>Sent: Tuesday, May 12, 2009 9:06 AM
>
> ...
>

I'm in agreement with Julien's position that we deal with binary formats
on the wire and text in the UI just fine in many routing protocol and
security configurations, and that the advantages of a binary format are
stronger than those of text.  The question about how flow rules differ
from the IPsec TS is one that occurred to me immediately when this
discussion first began, and I can see little/no difference myself, so
this further motivates binary to me, as it is more consistent with the
other current practice near this layer.  Though perhaps being IKE-like
isn't a good general goal ... :).

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 11:31:56 +0200

> printf will not do less...

OK, counting the number of statements isn't the best argument :-).

With "simple" I don't mean "more efficient", I mean that it is better
(easier) when developing, debugging and maintaining the system. Saving
a few CPU cycles or bytes just isn't relevant anymore, at least not
for control functions.

In my view, dynamic flow rules will not be generated by the "MIP
stack" itself. They will be determined by a higher level function,
e.g, a connection manager. The connection manager shouldn't even have
to care about what mobility solution is used (MIPv6, shim6, MOBIKE,
...). One of the ideas and explicit goals with our text-based rule
language is that it is mobility mechanism agnostic.

The connection manager will do reasoning at an abstract level. For
that, text output is better. Having it output a MIP-specific binary
format is not very elegant.

Some observations:

- The Android phone does all its network control logic in Java, which
  I think is a very reasonable design. An Android connection manager
  would thus be written in Java, and text output is suitable.

- For a research project, we did a connection manager in Python, which
  is a rather high level language. The connection manager did
  reasoning about what access to use for each flow at an abstract and
  powerful level, and then easily presented the result in the
  text-based flow rules language that we are suggesting.

> implement formal grammars, parse and validate regular expressions.

Why not? Because it is not "efficient" enough? Please note that most
(all?) MIP signaling implementations are user space programs, and are
not involved in packet forwarding.

Also, see my comment above regarding that the rules will not be
generated by the "MIP stack" itself.

> I do not see the relevance of the rule ordering in this discussion.

Well, I think that the rule format used is actually connected to the
issue of rule ordering.

In this regard, the text format has two advantages:

1. The rule order is well defined.
2. The action to be taken at a rule match is given inline.

Thus, rules in the text format are completely self contained.

Your binary format can't be used by itself, it is meant to be used
together with the current flow-binding mechanism. In a sense, it is
guilty by association (sorry). I am just trying to show that the
aspiration for (suboptimal) "efficiency" leads to complex solutions.

> IPsec, firewalls, etc.  and they work nicely everyday in the hand of 

OK. I will just note that you will need yet another tool.

> control plane, application... what are talking about?

The TCP/IP stack has four layers: Link, Internet, Transport and
Application. In that sense, the exchange of flow rules is done at the
application layer (with MH being the transport protocol, of course).

Other architectures (GSM/3GPP for instance) separates user data from
control data in different vertical planes, the user plane and the
control plane. In such an architecture, MH and rule exchange would be
control plane protocols.

What I am really after is that exchanging rules isn't a network layer
function, it is a control function. Thus the balance between
compressing away the last bit and other aspects changes, compared to a
(user plane) network layer protocol.

> IKE uses text to transfer Traffic Selectors on-the-wire?

The fact that IKE is still using a binary format is just a historic
mistake. IKEv3 will be text based when people realize that the 1970's
ended some 30 years ago :-).

Regards,
Michael

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 13 May 2009 02:54:27 -0700

Hi Michael,

One question below

> Michael Eriksson
> Sent: Wednesday, May 13, 2009 12:32 PM
> To: Julien Laganier
> Cc: [email-masked]
> Subject: Re: [MEXT] offline Re: binary filters draft 0
> 

Are you talking about the coding of the API between the connection manager and the MIP stack? I don't this is the point here.

The point is how the MN via the MIP protocol delivers the rules to the HA. This has nothing to do with internal API in the MN.

Thanks
Gerardo

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 11:59:07 +0200

> decisions used as fundamental assumptions.

The flow-binding draft (unfortunately) currently only suits a binary
format similar to what was in your first draft. Thus, I see them as
one solution.

Discussing new ideas and solutions with people who have already made
up there minds (since years back) is not very fruitful.

> this function has to be done.

The procedure you describe above, determining the correct rule order,
would have to be done at the MN. The result of this is an ordered list
of rules. To get the binary flow rules evaluated in the correct order
at the HA, the MN would have to number every rule by using the PRI
field, which will then be used as a rule counter. (Sorry for the BASIC
joke, but BASIC numbers statements in exactly the same way.)

To avoid using the PRI field for a particular rule, you would have to
determine that the rule doesn't overlap with any other rule, and that
the evaluation order therefore doesn't matter for that particular
rule. Doing this overlap check is not trivial.

The text format, on the other hand, does not need to have the rules
numbered when they are transmitted to the HA, since the order is
inherent.

Regards,
Michael

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 13 May 2009 20:35:12 +1000

> format similar to what was in your first draft. Thus, I see them as

=> That's not true. It is orthogonal to the flow descriptor format.
Although, after reading Julien's response earlier I can't see any benefit
for the text format in terms of use or implementation. Probably easier on
the eye to design and spec but I can't see any other benefit.

> numbered when they are transmitted to the HA, since the order is

=> I don't think you're talking about the same thing we were discussing
before. Actually, I don't know what you're talking about.

Determining overlap has to happen whatever format you use. The ordering is a
forwarding priority and has *nothing* to do with the way the rule is
written, it's an inter-rule ordering not intra-rule ordering.

Hesham

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 13:53:18 +0200

On Wed, May 13, 2009 at 02:54:27 -0700, Giaretta, Gerardo wrote:
> Are you talking about the coding of the API between the connection
> manager and the MIP stack? I don't this is the point here.
>
> The point is how the MN via the MIP protocol delivers the rules to
> the HA. This has nothing to do with internal API in the MN.

It is of course an advantage that the same format is used by the
connection manager as in the MIP protocol. The connection manager will
create an array of bytes (the flow rules in ASCII format). All that
the MIP daemon needs to do is to put an MH transport header on this
byte array and send it to the HA.

The MIP daemon does not need to do complex binary packing of invidual
rules, it will just transfer a byte vector. Trivial to implement!

Regards,
Michael

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 13 May 2009 04:55:32 -0700

You are assuming an API which is not standardized so I could claim that other systems use different encoding in the internal communication.

I don't think this should be consider as a differentiating point between the solutions as this is clearly not generic enough and only based on your personal assumptions.

Gerardo

> From: Michael Eriksson [mailto:[email-masked]]
> Sent: Wednesday, May 13, 2009 2:53 PM
> To: Giaretta, Gerardo
> Cc: [email-masked]

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 14:18:06 +0200

> => That's not true. It is orthogonal to the flow descriptor format.

As a co-designer of an alternative flow rule format, I must
unfortunately disagree: the flow-binding draft is not orthogonal to
the rule format, even though it should be.

The text-based rule format doesn't need any of the fields that are
described in the flow-binding draft. All it needs is to get a self
contained byte array (the rules in ASCII format) transferred from MN
to HA. The text format inherently contains information about:

- Rule ordering
- What action to take for a rule match

Handling that in the transport format, which the flow-binding draft
does

1. Makes the wrong assumptions about the flow rule format

2. Does things at the wrong "layer"

> written, it's an inter-rule ordering not intra-rule ordering.

You are mixing up:

1. Determining the order of the rules. This is done at the MN, and is
   independent of the how the rules are expressed (binary or text).
   Determining whether the rules overlap or not is not necessary, as
   long as you sort them in priority order.
   
2. Transfering the ORDERED list of rules from the MN to the HA. This
   is where there is a difference between the text rules and binary
   rules transferred in the flow-binding format.

   - For the text format, this is trivial: Just append them in order.

   - For the binary format, you have two choices:

     - Send them unordered (FID-PRI=0). Not a good idea, since it is
       most likely that the wrong rule will match some flows.

     - Enumerate the rules by using the FID-PRI field as a rule
       numerator (hence my BASIC remark).

     In practice, you will always have to enumerate the rules with the
     FID-PRI field. This is not very elegant, and adds complexity. For
     instance, the rules would have to be sorted according to their
     FID-PRI value after reception, while in the text format they
     always arrives in correct order.

Regards,
Michael

---

From: Julien Laganier <[email-masked]>
Date: Wed, 13 May 2009 14:34:30 +0200

Hi Michael,

On Wednesday 13 May 2009, Michael Eriksson wrote:
> > > I can't see how this is simpler than printf. With printf you
> > > normally just need one single statement to output a complete
> > > rule.
> >
> > and how many statements do you need to parse and validate? Also
> > note that the number of statements is pretty much irrelevant since
> > in the end what matters is that you have to move words in memory
> > and there the printf will not do less...
>

Ok - let's not use it then.

> (easier) when developing, debugging and maintaining the system.

FWIW I don't think it would be reasonable to run in a production 
environment code written by someone who doesn't know how to code a 
byte-and-bit parser :-)

> Saving a few CPU cycles or bytes just isn't relevant anymore, at
> least not for control functions.

It is not because it isn't the number one goal that it is not relevant. 

> language is that it is mobility mechanism agnostic.

You can very well have a mobility protocol agnostic language to describe 
you rules in your implementation. 

What we're talking about here is how the rules are transmitted by MIPv6, 
not how they are transmitted by the Agnostic Protocol.

> format is not very elegant.

Again you can do reasoning in your connection manager at an abstract 
level using text, ideograms or XML. That doesn't translate into the 
need to carry that same text in the MIPv6 protocol. 

> - For a research project, we did a connection manager in Python,
> which is a rather high level language. The connection manager did

See above, there's no contradiction b/w coding in a high level language 
and manipulating text and transporting information in a binary format.

> > > > Again, IMHO a blanket statement. I'd rather parse a well
> > > > defined simple binary format than text. The bit and byte vector
> > > > I proposed are straightforward and simple in my view.
> > >

Why? 

Because that's how things are done. What I recommend is that you find 
out 1) what is most deployed network layer protocol, and 2) which 
encodings its use.

Once you've done the exercise, compare the situation with RFC 3252. On 
my side I do not know any implementation of RFC 3252 in wide use.

> generated by the "MIP stack" itself.

That's internal to your implementation. I am talking about 
bits-on-the-wire. 

Yes, bits!

> > > If you want more arguments for why the binary format is more
> > > complex, see the ongoing discussion on how the HA should select
> > > between overlapping binary rules. For the text format, this is
> > > trivial: The rules are evaluated in strict order.
> >

Same can be done with a binary format. Order of IPsec TS in IKE is well 
defined.

> 2. The action to be taken at a rule match is given inline.

Same can be done with a binary format.

> Thus, rules in the text format are completely self contained.

Same can be done with a binary format.

> aspiration for (suboptimal) "efficiency" leads to complex solutions.

I respectfully disagree.

> > > > The average user is never going to edit any flow rules, thus I
> > > > do not think that the ability to edit them with a text editor
> > > > is key (My mom doesn't know what text is -- she uses Word :-).
> > > > Even if it was, one can simply build a tool that takes binary
> > > > and output text and vice versa.
> > >
> > > OK, I don't expect your mother to edit her flow rules :-). But
> > > maybe trained experts will. In your case, you would have to start
> > > with defining the text format. And then develop and debug the
> > > tool. Doesn't that seem a bit awkward?
> >
> > I don't think it is awkward, that sort of tool exist for IP
> > routing, IPsec, firewalls, etc.  and they work nicely everyday in
> > the hand of experts.
>

Exactly as you need another tool to crunch, resolve, save, edit your 
text rules!

> > > No, exchanging flow rules is not a network layer protocol! It is
> > > a network control protocol, and is done on the "application"
> > > layer (or the control plane, as it is called in other
> > > architectures).
> >

MH is not a transport protocol. It is a network layer mobility (or 
routing) protocol.

> control plane. In such an architecture, MH and rule exchange would be

Thanks for explaining the difference b/w user plane and control plane, I 
am sure this will be useful to many of us. 

As you're mentionning 3GPP I will simply note that the control plane for 
the network mobility core (GTP-C) does not use text encoding. It uses 
binary, because it is network layer control protocols.

> compressing away the last bit and other aspects changes, compared to
> a (user plane) network layer protocol.

Exchanging mobility routing rules is both a control and a network 
protocol thus I do not know what you're after.

> > How are these flow rules different from an IPsec Traffic Selector?
> > Does IKE uses text to transfer Traffic Selectors on-the-wire?
>

Do you mean that RFC 2460 will eventually be superseded by RFC 3252?

Cheers -

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 13 May 2009 14:46:04 +0200

Michael,

On Wednesday 13 May 2009, Michael Eriksson wrote:
> [...]

OTOH, I have the impression that you are mixing things up quite a bit 
here. See below -

>    - For the text format, this is trivial: Just append them in order.

Exactly the same can be done with the binary format: Just append them in 
order in a single BU. 

Defining a priority field is an optimization that allows not sending the 
full ruleset in each BU, thus making it possible to order rules that 
were sent in different BUs. You would need exactly the same for your 
text format were you going to provide the same optimization.

>      In practice, you will always have to enumerate the rules with
> the FID-PRI field. This is not very elegant, and adds complexity. For
> FID-PRI value after reception, while in the text format they always
> arrives in correct order.

See above the point that FID-PRI is required only because there's the 
optimization of sending the full ruleset in each BU.

--julien

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 15:52:37 +0200

On Wed, May 13, 2009 at 04:55:32 -0700, Giaretta, Gerardo wrote:
> You are assuming an API which is not standardized so I could claim
> that other systems use different encoding in the internal
> communication.

By using a text format, you have the /possibility/ to have the same
format between the connection manager and the MIP daemon as in the MIP
signaling. This makes simple but powerful implementations possible,
but you are of course free to use any API you want between the
connection manager and the MIP daemon.

I still think that it is elegant and a relevant advantage that the
rules are expressed in a "high level" text language that is easy for
the connection manager to generate, and that the MIP daemon only have
to do very little to transfer the rules to the MN.

> I don't think this should be consider as a differentiating point
> between the solutions as this is clearly not generic enough and only
> based on your personal assumptions.

I can't see how my "personal assumptions" comes into this. I only show
that a text format can nicely tie together a connection manager with
MIP (or any other mobility mechanism).

Regards,
Michael

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 16:43:14 +0200

> environment code written by someone who doesn't know how to code a 

I, on the other hand, don't think it would be reasonable to run in a
production environment code written by someone who only knows how to
code a byte-and-bit parser :-)

> not how they are transmitted by the Agnostic Protocol.

But then you would have to translate the rules from text to a binary
format before transmission. Are the few saved bits (if any) really
worth the cost in added complexity?

Have you done any ballbark calculations: How many bytes would a binary
format really save? How many percents of the available bandwidth?

> out 1) what is most deployed network layer protocol, and 2) which 

That was one of the weakest arguments I have ever heard! :-) (sorry)

Unfortunately, it is all too common. How could we possibly advance out
of the 1970's if everybody argued like that?

> That's internal to your implementation. I am talking about 

See my reply to Gerardo on why it is nice to use a rule format
suitable for the connection manager all the way to the HA.

> Same can be done with a binary format. Order of IPsec TS in IKE is well 

I agree, but as I said before: Your are guilty by association with the
flow-binding draft, since that is what your binary format targets.
When you define a better transport format (please, please, please do
that!), I will disregard this argument.

> Same can be done with a binary format.

I agree again. Please, please, please design a better transport format
where this would fit!

> Exactly as you need another tool to crunch, resolve, save, edit your 

Oh, you mean Emacs. Fortunately, rms developed that already in the
80's :-).

> MH is not a transport protocol. It is a network layer mobility (or 

We can argue about that, but I don't think it is important. The thing
is that it is not used to transfer user data, and thus it is a
suboptimization to compress out the last bit at the cost of added
complexity.

> am sure this will be useful to many of us. 

Well, you did ask!

> binary, because it is network layer control protocols.

See my comment above about weak arguments :-).

I am trying to teach my kids that "everybody else does that" is not a
good excuse for bad behavior...

> protocol thus I do not know what you're after.

Again: I am after that it is more important to be bit efficient for
"user traffic", of which there is a lot. For control traffic, it is
not very important. Reduced complexity is much more important.

Regards,
Michael

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 13 May 2009 07:50:41 -0700 (PDT)

Hi all,
  I have the same concern as Michael nicely stated below.
I was reading draft-ietf-monami6-mipv6-analysis which provides the basis for all this work. It dates back 2005 or even before. Maybe at that time multihoming was understood as a laptop with two PCMCIA cards. 
  Can we say the same now in view of new user devices that come with several wireless interfaces including Wi-Fi? Can we treat Wi-Fi the same as a cellular interface? 
  We have now a mif WG which is going to study what is available in the current OSes before doing any protocol development.
  Also I don't understand the relationship between this discussion and IKE traffic selectors. IKE is basically Diffie-Hellman protocol and I am not sure if my IPhone uses it?
  
  My suggestion is to have a new overall look at this problem that mext inherited, maybe discuss it in IETF-75 in hopes of a reformulation before moving ahead with the current draft.

Regards,

Behcet 

________________________________
From: Michael Eriksson <[email-masked]>
To: Hesham Soliman <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, May 13, 2009 4:59:07 AM
Subject: Re: [MEXT] offline Re: binary filters draft 0

---

From: Julien Laganier <[email-masked]>
Date: Wed, 13 May 2009 17:45:45 +0200

On Wednesday 13 May 2009, Michael Eriksson wrote:
> > > stack" itself. They will be determined by a higher level
> > > function, e.g, a connection manager. The connection manager
> > > shouldn't even have to care about what mobility solution is used
> > > (MIPv6, shim6, MOBIKE, ...). One of the ideas and explicit goals
> > > with our text-based rule language is that it is mobility
> > > mechanism agnostic.
> >
> > You can very well have a mobility protocol agnostic language to
> > describe you rules in your implementation.
> >
> > What we're talking about here is how the rules are transmitted by
> > MIPv6, not how they are transmitted by the Agnostic Protocol.
>

Since in order to match actual packets the MIPv6 stack will _anyway_ 
have to deal with binary representation of IP addresses, protocol 
numbers, flow labels, port numbers, ICMP types and codes,  IPsec SPIs, 
you will have to pick these elements out of your text rules and 
translate them to binary _anyway_ thus I do not see where is the added 
complexity.

And yes it saves bits. It's not because a resource is cheap that we 
should consume it without regards. For an illustration, see Fallacy #3 
in <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>.

> Have you done any ballbark calculations: How many bytes would a
> binary format really save? How many percents of the available
> bandwidth?

I do not have the charge of the proof since I propose to follow the 
current practice of using binary encoding for network layer protocols.

You are on the other hand free to compute how much complexity is saved 
by translating text to binary in the MIPv6 stack (as pointed out above 
is implied by your proposal) rather than in your connexion manager (as 
I argue you could do if you really want a text based language).

> > > > I do no think a network layer stack implementation is the place
> > > > to implement formal grammars, parse and validate regular
> > > > expressions.
> > >
> > > Why not? Because it is not "efficient" enough? Please note that
> > > most (all?) MIP signaling implementations are user space
> > > programs, and are not involved in packet forwarding.
> >
> > Why?
> >
> > Because that's how things are done. What I recommend is that you
> > find out 1) what is most deployed network layer protocol, and 2)
> > which encodings its use.
>
> Unfortunately, it is all too common. How could we possibly advance
> out of the 1970's if everybody argued like that?

Is this your argument?

Mind you, many bright principles originates in the 70's and are still 
valid today.

It's the right thing to do to follow past design principles unless 
better ones are found. So far you have not provided any valid evidence 
that motivate the need to use text encoding in a network layer 
protocol. 

You keep insisting on the "complexity" of "translat[ing] the rules from 
text to a binary format before transmission" while it is clear that, as 
soon as you introduce a text rule language, translating between binary 
and text is required to match actual packets no matter what rule 
encoding we choose for on-the-wire protocol encoding .

Or do you think everybody will start encode packets following IPoXML 
[RFC3252] so that your MIPv6 stack can match packets using yacc and lex 
too, without translating text rules to binary at all?!

I will not add any more "weak" arguments to this discussion as I believe 
you have used them all already.

Thank you.

--julien

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 14 May 2009 02:06:54 +1000

> look in the binding cache! The MN will unregister any non-working CoA.

=> Oh of course if an entry is in the binding cache then the corresponding
interface, base station, cell load, app preferences and end to end
reachability must all be valid for the lifetime of the binding...makes
perfect sense...These things just don't change once the CoA is in the
binding cache. Of course the binding cache also includes the corresponding
link layer properties associated with the CoA, which also never change. The
all-knowing omnipresent HA can then direct traffic as it sees fit.

Hesham

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 22:01:45 +0200

First, Julien, please excuse me if I offended you with my last mail.
That was not my intention. I think that our discussion had a sound
dose of tounge-in-cheek (which I appreciated), and I thought that you
wouldn't mind a rude joke. I am sincerely sorry.

> translate them to binary _anyway_ thus I do not see where is the added 

Yes, the text will have to be parsed somewhere. But the beatiful thing
with doing it at the HA is that you can completely avoid to encode and
decode the message to and from an ad hoc binary format just for the MN
to HA transport!

> in <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>.

I think that it is funny that you want to save some bytes in a
signaling message that is sent maybe once a minute (at most), when
MIPv6 tunnels every user data packet...

If you really want to save bytes, I think that you should focus on
separating the rule updates from the binding updates.
Resending/refreshing all rules, whether in binary or text format, at
every handover is wasteful -- both in terms of transmitted bytes and
complexity. The same goes for refreshing all bindings just because you
change the rules.

> current practice of using binary encoding for network layer protocols.

It is your argument that the text protocol is too verbose, and that a
binary format is needed.

> I argue you could do if you really want a text based language).

It would save exactly the complexity of encoding and decoding to and
from a binary format. Given the existing suggested binary rule and
transport formats, I would say that that is quite a lot...

> Mind you, many bright principles originates in the 70's and are still 

OK, I should have added one or two smileys, but I thought that was
obvious.

But I actually think that I do have a point about the tendency to
always do things as they have always been done. That is not the way to
make real progress. More of the same is not always the best thing.

In this particular case, the available bandwidth have increased with
about 2 to 3 decimal magnitudes (i.e., a factor of 100 to 1000) in the
13 years that have passed since draft-ietf-mobileip-ipv6-00 was
published in January 1996. Back then we used 28.8 kbps modems and the
9.6 kbps GSM circuit switch data service. Today, we use 8000-100000
kbps fixed accesses at home, and 3G HSPA with 7200 kbps.

> that motivate the need to use text encoding in a network layer 

I am arguing that the text format is a better design. I happen to
think that I actually have put forward some reasonable arguments.

> encoding we choose for on-the-wire protocol encoding .

I think I replied to a similar remark above.

Regards,
Michael

---

From: Michael Eriksson <[email-masked]>
Date: Wed, 13 May 2009 22:10:35 +0200

> all-knowing omnipresent HA can then direct traffic as it sees fit.

Hesham, to me it is plain obvious that the MN can keep the HA in sync
regarding all its knowledge about the status of its interfaces by
sending binding updates. If the MN gets new status information, it
will do a binding update.

I will let your reasoning above pass with merciful silence...

				- o -

I also note that you are not answering this question, which was in the
same mail:

I hope that means that you will no longer keep saying that "policies"
means "rules" when you want it to, but not otherwise (playing with
words, as I irreverently called it).

Regards,
Michael

---

From: Hesham Soliman <[email-masked]>
Date: Thu, 14 May 2009 06:31:45 +1000

> I will let your reasoning above pass with merciful silence...

=> Yes sounds like a reliable way of doing things (of course not).

>    and the charter talks about POLICIES?

=> No I didn't because life is too short and I'm under too much time
pressure to keep repeating myself. My use of the words hasn't changed and
you seem to like quoting what proves your point and ignoring all other
quotes that don't. The draft didn't just sneak into the WG without people
and the chairs knowing full well what it did (and it's not policies it's
transfer of rules). So, I think the (only?) point you may have in this
discussion is that the charter is not worded carefully about the use of
transport of rules. But for that you should address the chairs/AD as it's
not my job.

> words, as I irreverently called it).

=> There is a difference between irreverent and rude. But I think you'll
disagree with me on that too

Hesham