Subject: Re: [MEXT] multiple coa draft 11

From: Christian Kaas-Petersen <[email-masked]>
Date: Thu, 5 Mar 2009 10:44:27 +0000 (GMT)

Thanks a lot.  Two further comments inline

--- Den tors 5/3/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] multiple coa draft 11
> Til: "Christian Kaas-Petersen" <[email-masked]>
> Cc: [email-masked]
> Dato: torsdag 5. marts 2009 11.02
> Hi Christian, some comments
> inline...
> 
> On Thu, Mar 5, 2009 at 8:20 AM, Christian Kaas-Petersen
> <[email-masked]>
> wrote:
> >
> >
> > 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."
> >
> 
> 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.

Will it be acceptable to add a statement like "Two BID-values
MUST NOT refer to the same care-of address" to the draft?

> 
> 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.
> 
> > 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.

Do I understand it correct, if I assume having a home agent
supporting multiple CoA (not supporting flow bindings), then
a packet destined for v6HoA can in the first situation be
associated with only one of BID1, BID2, or BID3, whereas
in the second case a packet can be associated with one
of BID1, BID2, or HOME  (How this association is made is
outside the scope of the draft) ?

Christian

      Find din nye laptop på kelkoo.dk. Se de gode tilbud her - http://dk.yahoo.com/r/pat/mm

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 5 Mar 2009 12:38:29 +0000

some more inline...

> MUST NOT refer to the same care-of address" to the draft?

GT2> MUST NOT is only appropriate if the action causes
interoperability problems, which I am not sure it does here. I would
like to hear other opinions though WRT to this since I have not
thought about it in detail for some time. If there is no other
foreseeable use of multiple BIDs pointing to the same CoA then, I
would say something like "more than one BIDs  SHOULD NOT be mapped to
the same CoA".

> outside the scope of the draft) ?

GT2> The basic assumption I think is that without the MN indicating
what it wants to do (which requires flow binding) it is up to the HA
to decide.

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 5 Mar 2009 08:53:33 -0800

Hi George and Christian,

One comment below

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of George
> Tsirtsis
> Sent: Thursday, March 05, 2009 4:38 AM
> To: Christian Kaas-Petersen
> Cc: [email-masked]
> Subject: Re: [MEXT] multiple coa draft 11
> 
> some more inline...
> 

As Christian mentioned there has been some discussions about the opportunity of having same CoAs for multiple BIDs. This may have a some advantages in some specific flow binding scenarios. However this is really something related to flow binding and I am not sure how to address it here. I think a MAY is fine as it does not create any interoperability issue.

As a background, the scenario is the following:
- MN has three interfaces with BID1, BID2, BID3 with some FIDs associated to each BID
- Let's assume the interface (e.g. WiFi) for BID2 loses coverage. In this case you have two possibilities:
1. the MN deregisters the BID2 and maps one by one all FIDs to other BIDs
2. the MN binds the CoA of BID1 also to BID2 in order to avoid sending all the FID options. Automatically the FIDs are still bound to BID2 but with an active CoA

In some scenarios option 2 gives you an optimization in terms of signaling.

Gerardo

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

---

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

Hi Gerardo,

On 2009/03/06, at 1:53, Giaretta, Gerardo wrote:

> As Christian mentioned there has been some discussions about the  
> opportunity of having same CoAs for multiple BIDs. This may have a  
> some advantages in some specific flow binding scenarios. However  
> this is really something related to flow binding and I am not sure  
> how to address it here. I think a MAY is fine as it does not create  
> any interoperability issue.

Do we really need to mention how to manage multiple BIDs assigned to  
the same CoA?
The same BID MUST NOT be used for different CoAs, because it causes  
protocol errors.
On the other hand, I don't see any issue if someone assign two BIDs to  
the same CoA.
The bindings are managed independently and separately.

If we will say something for this, I also think MAY is better.

regards,
ryuji

> 2. the MN binds the CoA of BID1 also to BID2 in order to avoid  
> sending all the FID options. Automatically the FIDs are still bound  
> to BID2 but with an active CoA
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Mon, 9 Mar 2009 15:32:06 -0700

Hi Ryuji,

> From: Ryuji Wakikawa [mailto:[email-masked]]
> Sent: Friday, March 06, 2009 1:34 AM
> To: Giaretta, Gerardo
> Cc: George Tsirtsis; Christian Kaas-Petersen; [email-masked]

This was indeed my point. It does not seem to cause any issue and everything works fine, except that there is a larger amount of state in the MN and HA. I don't have a strong opinion on this. We can even say SHOULD NOT if George and Hesham think this should be recommended. Saying nothing is also OK with me, but Christian was not fine with that and wanted clearer text.

Regards
Gerardo