[Monami6] Question on draft-soliman-monami6-flow-binding-00.txt

Gábor Fekete <feketgai@index.hu> Fri, 14 April 2006 17:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSNb-0004xn-7v; Fri, 14 Apr 2006 13:46:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUSNZ-0004kT-DM for monami6@ietf.org; Fri, 14 Apr 2006 13:46:45 -0400
Received: from posti5.jyu.fi ([130.234.4.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUSNW-0001N9-Td for monami6@ietf.org; Fri, 14 Apr 2006 13:46:43 -0400
Received: from localhost (localhost.localdomain [127.0.0.1]) by posti5.jyu.fi (8.13.6/8.13.6) with ESMTP id k3EHkeJ8006184 for <monami6@ietf.org>; Fri, 14 Apr 2006 20:46:40 +0300
Received: from posti5.jyu.fi ([127.0.0.1]) by localhost (posti5.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06016-10 for <monami6@ietf.org>; Fri, 14 Apr 2006 20:46:39 +0300 (EEST)
Received: from b19c.mylly.jyu.fi (b19c.mylly.jyu.fi [130.234.196.146]) by posti5.jyu.fi (8.13.6/8.13.6) with ESMTP id k3EHka8P006172 for <monami6@ietf.org>; Fri, 14 Apr 2006 20:46:39 +0300
From: Gábor Fekete <feketgai@index.hu>
To: Monami6 WG <monami6@ietf.org>
Subject: [Monami6] Question on draft-soliman-monami6-flow-binding-00.txt
Date: Fri, 14 Apr 2006 20:46:03 +0300
User-Agent: KMail/1.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200604142046.05052.feketgai@index.hu>
X-Virus-Scanned: amavisd-new at cc.jyu.fi
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
X-BeenThere: monami6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Monami6 WG <monami6@ietf.org>
List-Id: Monami6 WG <monami6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/monami6>
List-Post: <mailto:monami6@ietf.org>
List-Help: <mailto:monami6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@ietf.org?subject=subscribe>
Errors-To: monami6-bounces@ietf.org

Hi list,

Some question related to draft-soliman-monami6-flow-binding-00.txt.

1. If the R bit is set in the flow-id option does that
   mean that the Source Address of the flow is the
   destination address of the BU?
2. The flow-id option has the Destination Address
   field. The flow-id is placed in a BU. For me, the BU
   is all about the HoA. The BU tells to the receiver
   what to do with the HoA (e.g. bind to a CoA).
   I think either the Destination Address field should be
   removed in favor of the HoA of the BU, or the flow
   identifier should not be carried in BUs. Any good reason
   this field must be present?
3. In a CN/HA, can two binding cache entries with different
   HoAs have the same FID?
   e.g.:  HoA1-CoA1-FID1
          HoA2-CoA2-FID1
4. Can multiple flow-options be bound to a single BUL entry?
   The draft indicates it but in section 5.1 it does not
   seem that the proposed BUL change supports that.
5. It would be nice to have some conceptual figures of BC and
   BUL to clarify the relation between policies (flow dentifiers)
   and bindings.
6. Action "Discard" is not discussed in section 5.2.1.
7. In section 5.2.2. "Using Alternate Care-Of Address":

   "A mobile node can use an alternate care-of address to issue a Flow
    Identifier for a different Flow Binding."

   Different than what? I do not get it.
8. What does section 5.4 have to do with movement?
9. Section 6 indicates that this draft overlaps with
   draft-wakikawa-mobileip-multiplecoa. So will this draft be changed
   to be a policy extension of draft-wakikawa-mobileip-multiplecoa?
10. Section 6 is quite incomplete and I guess it has quite a bit of
   overlap with section 7. At least some references to the relevant
   HA operations would be good.
11. What happens if HA gets BU with D flag set and it already has
   a different binding with D flag set for the same HoA?
12. Can a Default Binding have a FID?
   If yes then in Section 7.4.2 it should be mentioned. E.g. "If the
   FID in the BU corresponds to the Default Binding then the HA
   deletes all bindings of the HoA."
13. In section 8:
   "... The
   lifetime of the binding is the lifetime of the binding update. ..."
   Why is it mentioned here? Is it important? It's not mentioned for
   HA nor for CN BUs.
14. Section 8:
   "...acknowledgement and includes the flow identification option.  Only
   the first eight octets are required in the option. ..."
   Which option? I guess the flow identification option in the BA. Or not?
15. In Section 10.1:
  "... Care-of address.  In order to differentiate between several bindings
   for the same home address, a Flow Identifier (FID) is used. ..."
   Isn't it the BID rather than the FID?
16. Section 10.3:
  "... several egress interfaces, (ii) when several mobile networks are
   operating the same mobile network, ..."
  Can "several mobile networks" operate a mobile network? Or is it
  "several mobile routers"?

If this draft becomes an add-on for draft-wakikawa-mobileip-multiplecoa and
also bulk-registration for draft-wakikawa-mobileip-multiplecoa is accepted,
I am a bit concerned about the BU packet sizes.

And I just wonder if it was not better to somehow specify flow policies
separately from MIP (or NEMO) and keep it as a general multihoming issue.
For example, there may be several other protocols other than MIP that can
handle multihoming (e.g HIP, DCCP, SCTP) and could benefit from having
policies. Obviously it indicates that policies should not be sent in BUs
but with a separate protocol.
The idea is that we'd have a general policy description and distribution
protocol. The participants in this protocol would then decide what they
do with these policies. The policy description should be such that it could
be mapped to e.g. MIPv6 bindings. For example, again with MIPv6, the
destination address field in the policy descriptor would mean the HoA and
the action for the policy would be the CoA. Then a MIPv6 module at a router
acting as a HA can map this policy to an existing BC entry.
This means that policies are distributed with some extra signaling. But still
it may be useful to other protocols too than MIPv6.
Any ideas/opinions about this?

Regards,
Gabor

_______________________________________________
Monami6 mailing list
Monami6@ietf.org
https://www1.ietf.org/mailman/listinfo/monami6