Subject: [MEXT] multiple coa draft 11

From: Christian Kaas-Petersen <[email-masked]>
Date: Thu, 5 Mar 2009 08:20:57 +0000 (GMT)

Hi Ryuji

Reading draft-ietf-monami6-multiplecoa-11, I have some comments and
questions.

 * There was a discussion on the mail-list in relation to draft 10,
   whether two diffent BID-values can map to the same care-of address.
   Draft 11 is not explicit on this.  As the entries in the
   binding cache are separate,
   and can be updated one by one, the benefit of having two BID-values
   point to the same care-of address comes when introducing flow
   identifier: flow identifiers can remain mapped to the same BID-value
   even when care-of addresses change.  It would help implementers
   if the draft somewhere (section 2?) states "Two BID values MAY
   refer to the same care-of address."

 * section 3, second paragraph after Figure 1 "...the home agent
   SHOULD perform the lookup based on only the home address as 
   described in [RFC-3775]."  I don't quite follow the packet
   processing.  To understand better, I have a section at the end
   with specific examples (and questions) of packet processing.

 * section 4.1.  This section says that sequence number is
   common to all bindings related to one home address v6HoA.  Elsewhere,
   notably section 5.6.3, it is clear that also the H-bit is common
   to all bindings, so this is also to be mentioned as a change
   to the binding cache structure.  With the ability to update
   entries separately, I guess each entry has its own lifetime.
   I should like this to be stated explicitly.

 * section 5.3, second paragraph: The paragraph speaks about
   bulk registrations and refers to Figure 7.  However, Figure 7
   includes only a single Binding Identifier mobility option.
   At least two BID options should be shown.

 * section 5.6.2.  In scenario 1, it is clear, that payload packets
   from a correspondent node on the home link to the mobile node
   will always be sent on the home link.  But in the other direction,
   the mobile node will search its binding cache before searching its
   destination cache (see RFC 3775, sec 9.1).  Therefore some traffic
   may leave the mobile node on a foreign link, reach the
   home agent, and finally be sent on the home link to the 
   correspondent node.  I think this should be noted.

   In scenario 2, the home agent proxies for the mobile node, and 
   thus receives all traffic from correspondent nodes on the home
   link.  This has the consequence, that packets between such
   on-link correspondent nodes and the mobile node will traverse the
   link twice.  I think this should be noted.

 * section 5.6.5.  Suppose the mobile node has two interfaces, one
   attached to the home link and another attached to a foreign link.
   The home agent's binding cache could look as follows

       v6HoA BID1 -> v6HoA
       v6HoA BID2 -> v6CoA2
   
   such that flows associated with BID1 are sent on the home link.
   If the mobile node sends a binding update to delete the BID2 entry,
   shall the home agent remove the "BID1"-entry?  Before answering
   this, I have found it difficult to follow packet processing.
   See separate section below.

 * section 5.7, bullet 3, "major packet corruption": I guess, that
   the normal use case is to use ESP protection of binding updates.
   In such a case I should think it difficult to corrupt the packet's
   content (in a major or minor way) still ensuring the ESP verification 
   is succesful.  Actually, the draft needs not speculate about how
   the packet could be formatted wrongly.

 * section 6.1, last paragraph, "If the node does not know the BID,
   it searches for a binding with only the home address.  In such a
   case, the first matched binding is found.": As I understand it, 
   the draft does not specify any ordering of the entries in the
   binding cache, and even with no modifications to the entries,
   the draft does not mandate the entries to retain whatever order 
   they may have.  Thus I think this section really says, that a 
   random entry is picked.  This is not the best choice for TCP traffic
   as mentioned elsewhere in the draft.  Therefore I suggest the
   entries are sorted or searched in a particular order, for example
   such that smaller BID-values are preferred to larger BID-values.

Packet processing

In the following I'll think of the three packets

PACKET 1 is a payload packet destined for v6HoA, and after lookup in a flow filter the packet is associated with BID2.

PACKET 2 is a payload packet destined for v6HoA, and after lookup in a flow filter the packet is associated with BID4.

PACKET 3 is a payload packet destined for v6HoA which, after lookup in a flow filter, could not be associated with a BID-value.  

Suppose the home agent's binding cache for a mobile node has the three entries (three interfaces on three foreign links)

       (1) v6HoA BID1 -> v6CoA1
       (2) v6HoA BID2 -> v6CoA2
       (3) v6HoA BID3 -> v6CoA3

PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2.

PACKET 2 does not match any entry.  Is it dropped?

PACKET 3 will follow the procedure in section 3, ie will use the binding cache entry which was last verified by signaling or by received packets.  As packet flows from the mobile node is random, essentially the payload packet will pick a random entry.  Is this a good solution?

Now suppose the interface with v6CoA3 address becomes attached to the home link.  The mobile node has removed the binding cache's entry 3, and the other two entries are assigned H-bit=1, ie

       (1) v6HoA BID1 -> v6CoA1 H=1
       (2) v6HoA BID2 -> v6CoA2 H=1

PACKET 1 matches entry 2, thus the packet is tunneled to v6CoA2.

PACKET 2 matches no entry, but is it true the H-bit=1 ensures the packet is sent on the home link?

PACKET 3 not clear if the packet is guaranteed sent on home link, or whether it could (ie implementation choice) just as well use the last verified entry.

Christian

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 5 Mar 2009 10:02:44 +0000

Hi Christian, some comments inline...

>   refer to the same care-of address."

GT> You are reading MCoA and thinking Flow Bindings....which is not a
good thing to do :-). The way MCoA and Flow Bindings have been
designed, flow movement is based on mapping FIDs to different BIDs.
BIDs simply identify available CoAs (i.e., available paths). I do not
see why would one point two BIDs to the same CoA.
...
>   this, I have found it difficult to follow packet processing.

GT> Is there any real difference in packet routing whether only the
BID1-entry is in the binding cache or no entry at all i.e., the MN has
deregistered? It seems that the draft suggests that if home
registrations are used for flow movement purposes, it is not necessary
to use deregistrations (See 3rd paragraph in section 5.6.5).

>...

GT> I do not agree with this. The issue with TCP is about sending
packets of a given flow to different CoAs, which could result in
reordering etc and this issue is already indicated in the draft. As
long as a given flow goes on a given BID, however, there is no issue.
Now long time ago any notion of BIT "goodness" or "priority" was
removed from MCoA and I think it is now in flow bindings draft, which
is probably more appropriate.

> Packet processing

GT> your packet processing example is not very good because it assume
flow bindings, which are out of scope here. The MCoA spec should work
without them. The scenario you describe below should either be
re-written without flow bindings in mind, or it should be looked at in
the context of the flow bindings draft instead of this one.

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Mar 2009 08:10:00 -0800 (PST)

Hi all,
  If you look at the figures, esp. Figs. 1, 2, and 3, this draft assumes that a single prefix is assigned to all interfaces of MN. In another draft (draft-jeyatharan-netlmm-multi-interface-ps) this is referred to as single prefix model.
  My question is if we assign the same prefix to all interfaces then aren't we creating at the HA so-called a multi-link subnet (please see RFC 4903 on multi-link subnet issues)?

Regards,

Behcet

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 5 Mar 2009 16:25:18 +0000

It seems to me that all these figures show one home address
(2001:db8::EUI) and a number of different CoAs (care-of address1,
care-of address2).
Where do you see the same prefix being assigned to multiple interfaces?

On Thu, Mar 5, 2009 at 4:10 PM, Behcet Sarikaya
<[email-masked]> wrote:
> Hi all,
>   If you look at the figures, esp. Figs. 1, 2, and 3, this draft assumes
> that a single prefix is assigned to all interfaces of MN. In another draft
> (draft-jeyatharan-netlmm-multi-interface-ps) this is referred to as single
> prefix model.
>   My question is if we assign the same prefix to all interfaces then aren't
> we creating at the HA so-called a multi-link subnet (please see RFC 4903 on
> multi-link subnet issues)?
>
> Regards,
>
> Behcet
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Mar 2009 08:46:54 -0800 (PST)

As I said in figs. 1,2, and 3 the only prefix mentioned is 2001:db8::?

--behcet

________________________________
From: George Tsirtsis <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: RYUJI WAKIKAWA <[email-masked]>; [email-masked]
Sent: Thursday, March 5, 2009 10:25:18 AM
Subject: Re: [MEXT] multiple coa draft 11

---

From: Ryuji Wakikawa <[email-masked]>
Date: Fri, 6 Mar 2009 18:46:55 +0900

Hi Christian,

Thanks for comments.

>   with specific examples (and questions) of packet processing.

When some flow management mechanism  gives BIDX for a data packet,
HA searches the binding with BIDX and the home address.
If there is no binding registered with BIDX, the home agent should  
pick a binding for the data packets.
It should not drop the packets due to binding cache lookup (w/BIDX)  
failure.

>   I should like this to be stated explicitly.

Ok, will update the draft.

>   At least two BID options should be shown.

ok. will fix this.

>   correspondent node.  I think this should be noted.

good point. I will add some texts.

>   link twice.  I think this should be noted.

ok.

>   such that smaller BID-values are preferred to larger BID-values.

This is out of scope in MCoA. It's the task of flow management method  
like flow binding.

> PACKET 1 is a payload packet destined for v6HoA, and after lookup in  
> a flow filter the packet is associated with BID2.
>
> PACKET 2 is a payload packet destined for v6HoA, and after lookup in  
> a flow filter the packet is associated with BID4.
>
> PACKET 3 is a payload packet destined for v6HoA which, after lookup  
> in a flow filter, could not be associated with a BID-value.
>
> Suppose the home agent's binding cache for a mobile node has the  
> three entries (three interfaces on three foreign links)
>
>       (1) v6HoA BID1 -> v6CoA1
>       (2) v6HoA BID2 -> v6CoA2
>       (3) v6HoA BID3 -> v6CoA3
>

NO, the PKT2 will be sent with a last verified binding. (as a result  
of BC lookup without BID)

> PACKET 3 will follow the procedure in section 3, ie will use the  
> binding cache entry which was last verified by signaling or by  
> received packets.  As packet flows from the mobile node is random,  
> essentially the payload packet will pick a random entry.  Is this a  
> good solution?

We have already mentioned the random pickup is not appropriate.
The implementation should be carefully operated this (i.e not use  
random binding).

> Now suppose the interface with v6CoA3 address becomes attached to  
> the home link.  The mobile node has removed the binding cache's  
> entry 3, and the other two entries are assigned H-bit=1, ie
>
> PACKET 3 not clear if the packet is guaranteed sent on home link, or  
> whether it could (ie implementation choice) just as well use the  
> last verified entry.

Which interface MN sends the PKT2 and PKT3 are out of scope in MCoA.
The decision can be made with flow binding.
If there is no such mechanism, HA should use the last verified binding.

thanks
ryuji

>
>
> Christian
>
>
>
>
>
>
>      Trænger du til at se det store billede? Kelkoo giver dig gode  
> tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd