Subject: RE: [Monami6] timeslot at IETF68

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 7 Mar 2007 12:51:39 +0800

Hi,

[snip]
> Usually it's the other way round. In order for people to prepare for
> the discussion, a draft is useful, and it's too late now to produce a
> new one. So, is there a draft to read, if no draft, a report or
> something ? [/snip]

Currently, no documentation is available for the WG. The motivation for such
presentation is there exist  use case in which a multihomed host requires
additional help in order to perform the flow filtering when attached to a
multihomed router.

The following can be used by the audience to get some information on what
will be presented.

Consider the following scenario (as mentioned by Heikki)

                                              +------+
                     3G Cellular       |         |
                                  /--------|  I      |     +----------+
                  CoA-3G /             |  N    |----| HA-MR |
         +----+     +----+             |  T    |     +----------+
         | MN |----| MR |            |  E     |
         +----+     +----+             |  R    |     +----------+
            CoA-WLAN \             |  N   |----| HA-MN |
                                   \--------|  E    |      +---------+
                         802.11g         |  T    |
                                              +-----+

Here, the Mobile Router, MR, has two different egress interfaces: a 3G
cellular interface with a Care-of Address of CoA-3G, and a 802.11g interface
with a Care-of Address of CoA-WLAN.  A Visiting Mobile Node, MN, is
currently attached to the mobile network of MR.  HA-MR is the home agent of
MR and HA-MN is the home agent of MN.

"Flow Bindings in Mobile IPv6" (draft-soliman-monami6-flow-binding-02) aims
to bind flows by introducing a new option, known as Flow Identification
option, in the Binding Update and Binding Acknowledgement messages.  With
this, a Mobile Node can bind one flow to an interface while maintaining the
reception of other flows on another interface.  Flow bindings would
therefore be useful in cases where the Mobile Node is connected to different
access technologies with different characteristics.

However, when we apply the flow filtering mechanism stated in Monami6 to
NEMO, the fact that the tunnel ends at the Mobile Router whereas the traffic
ends at Mobile Network Node cause problem with flow filtering.  On one hand,
while the Mobile Router has multiple egress paths, it cannot perform
efficient flow filtering since the Mobile Router has no way to know the
traffic requirements of Mobile Network Node's flows.  On the other hand, the
Mobile Network Node has no way of knowing the existence of multiple paths
(and their network characteristics) to start flow filtering.

Thierry mentioned in the ML that this issue is also being worked out by the
automotive industry, within ISO TC204 WG16 (using SNMPv3). The solution is
part of the CALM standard which is supposed to be deployed in vehicles for
ITS applications. They do not necessarily need an IETF standard, and don't
even try, though they do reuse some of the existing standards like NEMO
Basic Support, etc.

Furthermore, Alex highlighted that the NEMO WG is rechartering to identify
requirements for Route Optimization.  One possible requirement may be that
MR sends to VMN what are the subnets to which it connects.  At that point
the flow bindings should be established by VMN somehow. This may be a
solution to the problem in which VMN knows nothing about MR decisions.

Because packets tunneling and traffic session terminate at different nodes
in a mobile network, the flow binding mechanism currently developed by the
Monami6 WG cannot be used without modification. Thus, the purpose of the
presentation is to attempt to gather requirements to provide a suitable
solution to be adopted by the flow binding mechanism designed for Monami6.

Regards,
Benjamin Lim

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Mar 2007 10:33:46 +0100

Benjamin, the description you wrote below sounds very meaningful to me, 
about the problem of MR doing flow bindings and LFN being unaware of 
that, while LFN should be aware because it is the end of the communication.

I think you could write a separate mail only with the correct picture 
and the paragraphs that sound like problem statement, avoid statements 
about who said what, and I will reply to that mail with comments.

I think from that on it will be very easy to put that initially agreed 
text in a short draft form and then a presentation slot can be requested 
(although the draft-00 deadline has passed the draft can be published on
  the Internet temporarily until published by RFC Editor after the IETF
  meeting).

Alex

> solution to be adopted by the flow binding mechanism designed for Monami6.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Benjamin Lim" <[email-masked]>
Date: Wed, 7 Mar 2007 18:03:32 +0800

Hi Alex,

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2007 5:34 PM
> To: Benjamin Lim
> Cc: Monami6 WG
> Subject: Re: [Monami6] timeslot at IETF68
> 
[Ben] The MN shown in the diagram below need not be a LFN. As stated in the
text, I'm showing that a VMN that is attached to MR facing the problem of
doing flow filtering efficiently.
 
>   the Internet temporarily until published by RFC Editor after the IETF
[Ben] Comments made by the members of the mailing list would most definitely
be left out if a draft is to be written on this topic. But for now, I'm
attempting to summarize some points that has been made in the mailing list
on this topic. My apologies if I have offended anyone when putting names to
comments.

Regards,
Benjamin Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Mar 2007 11:27:33 +0100

Benjamin Lim wrote:
> Hi Alex,
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Wednesday, March 07, 
>> 2007 5:34 PM To: Benjamin Lim Cc: Monami6 WG Subject: Re: [Monami6]
>>  timeslot at IETF68
>> 
>> Benjamin, the description you wrote below sounds very meaningful to
>>  me, about the problem of MR doing flow bindings and LFN being 
>> unaware of that, while LFN should be aware because it is the end of
>>  the
> communication. [Ben] The MN shown in the diagram below need not be a 
> LFN. As stated in the text, I'm showing that a VMN that is attached 
> to MR facing the problem of doing flow filtering efficiently.

Ok.

>> I think you could write a separate mail only with the correct 
>> picture and the paragraphs that sound like problem statement, avoid
>>  statements about who said what, and I will reply to that mail with
>>  comments.
>> 
>> I think from that on it will be very easy to put that initially 
>> agreed text in a short draft form and then a presentation slot can 
>> be requested (although the draft-00 deadline has passed the draft 
>> can be published on the Internet temporarily until published by RFC
>> Editor after the IETF meeting).
>> 
> [Ben] Comments made by the members of the mailing list would most 
> definitely be left out if a draft is to be written on this topic.

That's fine, thanks, I think administrative comments (like conditions
for Chair to allow a timeslot, or like NEMO RO is being chartered)
should be left out of the document; but comments on the problem
statement itself should be put in.

> But for now, I'm attempting to summarize some points that has been 
> made in the mailing list on this topic.

That's fine, thanks.

There was discussion on the int-area mailing list too about the
necessity of allowing the LFN to know the flow bindings decisions made
by MR.  Apart from the supportive comments, there was discussion showing
that usually the network does make decisions about how to route traffic
for endnodes (in general, when not using MCoA).

Typically, a router chooses a path to forward a packet based on (at
least) link up/down events in the various intermediary links; the
endnode is not aware of that.  This would translate into allowing MR to
do same kind of operation for LFN: MR decides flow for this LFN goes on 
a certain path and flows for another LFN to another path, without LFN 
being aware of that.

However, I would remark that in the usual case (non-MCoA), intermediary 
routers rarely if ever look at port numbers or addresses within tunnels 
to make such decisions.  They mostly look at the outer base header.  If 
an endnode application encapsulates a packet the intermediary router 
will not look in the encapsulated base header and thus the endnode keeps 
control.  If an endnode sets a port number the intermediary routers 
don't look at them.

Thanks for your comments and pushing on this.  I support describing the 
problem of MR making flow-binding decisions on behalf of a unaware LFN.

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 7 Mar 2007 16:26:53 +0100

Hi,

>  the Internet temporarily until published by RFC Editor after the IETF

Here Alex you are proposing something with is going against IETF rules
(though it is widely developed). 

BTW: I'm not sure a problem statement is needed, the problem is easy to
understand and is explained already in
draft-ietf-nemo-multihoming-issues. What is more questionable is the
possible solutions to achieve this, the pros and cons of each.

So, to this day, though a solution to this problem is interesting, I
still don't see what's new the slot could bring. This is why I'm
requesting for input material where Nicolas and I could clearly see the
benefit of allocating the slot.

Thierry.

-- 
Thierry ERNST, PhD 
INRIA Rocquencourt France Project-Team IMARA / JRU LARA
http://www.lara.prd.fr +33 1 39 63 59 30 (office)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Mar 2007 16:37:36 +0100

Thierry Ernst wrote:
>>  the communication.
>>  can be published on the Internet temporarily until published by
>> RFC Editor after the IETF meeting).
> 
> Here Alex you are proposing something with is going against IETF 
> rules (though it is widely developed).

I understand, thanks for pointing it out.  Good sane practice has a
draft published prior to meeting - yes and I support.  Would one please
post the documented rules along these lines so I know next time not
break these again.

> BTW: I'm not sure a problem statement is needed, the problem is easy
>  to understand and is explained already in 
> draft-ietf-nemo-multihoming-issues.

Please would you point section number dealing with the problem of MR
making flow-binding decisions on behalf of unaware LFN, or similar on 
which I could comment, thanks.

> What is more questionable is the possible solutions to achieve this,
> the pros and cons of each.

Right, I have no idea right now.

> requesting for input material where Nicolas and I could clearly see 
> the benefit of allocating the slot.

Dear Chairs, it is obviously a Chair decision to allow a slot or not, a
decision I'll respect.

I was not talking solution and I don't really have a solution in mind.

But I see people talking about exactly this problem in MONAMI6 and on
the [email-masked] and on the int-area list.   Besides the problem
was mentioned last time in the MONAMI6 meeting minutes, on mike and
re-reading of documents was suggested - a thing that happened.

I think this is enough support to acknowledge this problem has been
discussed extensively prior to this meeting.

Indeed, unfortunately there's currently no draft about this particular
problem.

Alex
PS: the problem is with a MR making flow binding decisions on behalf of
     of a unaware LFN, the LFN should at least be aware.