Subject: [MEXT] [Fwd: RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt]

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 26 Jun 2009 23:26:13 +0200

I am forwarding the TSV directorate review of the document. Please 
address the comments received.
Thanks, marcelo

-------- Mensaje original --------
Asunto: 	RE: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt
Fecha: 	Wed, 24 Jun 2009 09:02:00 -0500
De: 	Eddy, Wesley M. (GRC-MS00)[Verizon] <[email-masked]>
Para: 	Lars Eggert <[email-masked]>, TSV Dir <[email-masked]>
CC: 	Marcelo Bagnulo Braun <[email-masked]>, Jari Arkko 
<[email-masked]>, Julien Laganier 
<[email-masked]>
Referencias: 	<[email-masked]> <[email-masked]> 
<[email-masked]>

I reviewed draft-ietf-mext-flow-binding-02 from a TSV perspective, and
I've followed some of the MEXT mailing list threads around it.  Overall,
I think what's in the draft doesn't have major problems, and some of the
proposals in this area that do have big TSV problems seem to be getting
well-contained on the MEXT list.  The one thing that needs to be discussed
more between TSV and MEXT is the "n-cast" action (below).

For the TSV perspective, the definition of flow descriptors and the
possible actions performed on flows are of primary concern.  This
document actually punts on the definition of flow descriptors, and
the actions it defines are limited to:

- forward
- discard
- n-cast (replicate and forward to multiple addresses)

Of these, n-cast is the one that bears some consideration.  Obviously
it can cause some duplication and reordering, so you would have to be
careful to only do it for applications and transports that could handle
that.  It may have some interesting concerns for traditional means of
PMTUD, congestion control, and other transport mechanisms that try
to estimate path state and don't factor in the possibility that packets
are being replicated across multiple paths.  I don't fully understand
the motivation for n-cast, beyond the possibility of a handover with
reduced packet loss or something like that, so the pros and cons should
be weighed carefully, I believe.

Additionally, some mostly editorial comments:

1 - In the abstract and some other places there's a notion of "uplink"
    and "downlink" conveyed.  I know we mean "outbound from the MN" and
    "inbound to the MN", so maybe we should say that instead?

2 - "Nemo" is usually "NEMO", in my experience, and would have to be
    changed throughout the document.

3 - The definitions of "Flow" and "Flow Description" are a bit circular
    in section 3.

4 - status field code 129 in flow identification option should probably
    be "malformed" or "unparseable" rather than "poorly formed"

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

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Lars Eggert
>Sent: Monday, June 15, 2009 7:06 AM
>To: TSV Dir
>Cc: Marcelo Bagnulo Braun; Jari Arkko; Julien Laganier
>Subject: Re: [tsv-dir] TSV review of draft-ietf-mext-flow-binding-02.txt
>
>Hi,
>
>would someone please volunteer to perform this review for our friends
>over in INT?
>
>Thanks,
>Lars
>
>On 2009-6-9, at 22:06, Jari Arkko wrote:
>
>> And the primary question that I would like to have an answer for is:
>> does this approach fly? If there's a major problem somewhere, we would
>> like to know now when we can still change the approach.
>>
>> Jari
>>
>> marcelo bagnulo braun wrote:
>>> Hi Lars,
>>>
>>> Our AD (Jari) has asked to request a TSV review of
>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-flow-binding-
>02.txt
>>> .
>>> This document defines the transport of filter rules to  bind flows to
>>> different CoAs/interfaces.
>>> the format for the flow description is not yet agreed, but in order
>>> to
>>> have an idea, there are two documents proposing a format for that:
>>> http://tools.ietf.org/id/draft-tsirtsis-mext-binary-filters-00.txt
>>> and
>>> http://tools.ietf.org/id/draft-larsson-mext-flow-distribution-rules-
>02.txt
>>>
>>>
>>> We understand that the TSV review is critical for this document,
>>> since
>>> it deals with flows and how to define them, and it also involves
>>> transporting a potentially larger piece of data than other MIP
>>> extensions and aspects related to congestion control and
>>> fragmentations of such messages may be relevant.
>>>
>>> So, if you could provide a review before the document reaches the
>>> IESG, it would help to deal with any potential issue in an early
>>> stage.
>>>
>>> thanks, marcelo
>>>
>>>
>>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 27 Jun 2009 14:37:56 +1000

Thanks for the review. I agree with you that we need to place cautions
around the n-cast action and will do so based on the recommendaitons below.
Specifically, mention that the MN should ensure that it is applied to
appropriate transport layers that can handle potential
re-ordering/duplications and mention that it's best applied to handover
scenarios or scenarios where a redundant link is needed.

Other editorials will be done as suggested. We already have suggestions for
the circular definition.

Hesham