Subject: Re: [MEXT] flow binding draft 2

From: Christian Kaas-Petersen <[email-masked]>
Date: Tue, 5 May 2009 07:06:27 +0000 (GMT)

An example.  Assume the mobile node has made the registrations shown
in the two tables in the draft (in the Ordered Flow Binding Entries
on page 15 and in the Ordered BID Entries on page 16).  Now the mobile
node returns home in the sense of RFC3775.  The mobile node can
send a binding update with lifetime zero and include a Flow
Identification Summary Mobility Option with all the FIDs included.
How is this interpreted by the home agent?  As a deletion of
all entries? Or rather as a deletion of all BID entries but keeping
all Flow Binding Entries (which will now be in state Inactive)?
I think the intention is all is removed, but please point to the
text in the draft making this clear.

Christian

--- Den tirs 5/5/09 skrev Hesham Soliman <[email-masked]>:

> Fra: Hesham Soliman <[email-masked]>
> Emne: Re: [MEXT] flow binding draft 2
> Til: [email-masked], "'George Tsirtsis'" <[email-masked]>
> Cc: [email-masked]
> Dato: tirsdag 5. maj 2009 08.23
> 
> > 
> >> So how do you refresh bindings?
> > 
> > We don't need to refresh flow bindings. Since flow
> have no
> > lifetime and are binding to CoA(BID), it is not
> > necessary to refresh them. We can just refresh
> CoA(BID).
> 
> => Of course they have a lifetime, it's the lifetime of
> the BU.
> > 
> >> What if the MN rebooted and lost all
> >> state and became
> >> out of sync with the HA?
> > 
> > Since MN reboots, it will re-register all its bindings
> and flows.
> 
> => How?? Are you saying the MN somehow remembers what
> flows it had before
> reboot? Even if it did, if a connection no longer exists it
> won't need a
> binding. Makes no sense to me.
> 
> Hesham
> 
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 

      ________________________________________________________ 
Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte biler til en hver smag! Klik her for at sammenligne priser.(http://dk.yahoo.com/r/pat/mmb)

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 05 May 2009 18:08:47 +1000

On 5/05/09 5:06 PM, "Christian Kaas-Petersen" <[email-masked]> wrote:

> all entries? 

=> It's a deletion of all entries. A dregistration BU removes all bindings
and this includes FIDs. Any inactive FIDs are removed with the last binding,
just like any other MIP state.

Or rather as a deletion of all BID entries but keeping
> all Flow Binding Entries (which will now be in state Inactive)?

=> No, inactive FIDs are not stored permanently, they're only there while a
binding exists. 

Hesham

> Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte biler
> til en hver smag! Klik her for at sammenligne
> priser.(http://dk.yahoo.com/r/pat/mmb)

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 09:19:14 +0100

Right, I agree. I think it is a good property to keep across MIP specs
i.e., BU with Lifetime=0 removes everything, no matter what else is
going on.

In any case, I think it is worth adding a comment about this in the
Flow Bindings draft just to make it very clear for this draft.

Thanks
George

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 14:46:25 +0200

> i.e., BU with Lifetime=0 removes everything, no matter what else is

Not arguing at all on that fact; just clarifying this is not the only
way to remove a binding (spec-wise):

1) from a receiver (HA, CN) perspective, having the BU lifetime set to 0
   is indeed sufficient. *BUT* having the Care-of Address set to the
   Home Address is *sufficient* too (i would add for clarity 'no  matter
   the value of the lifetime' in the BU)
2) from a sender perspective, the BU is expected to have the Lifetime
   set to 0 *and* the Care-of address set as the HoA.

To avoid the lookup in RFC 3775 are difficult, below are excerpts from
the document: 

In section 6.1.7. of RFC 3775 ('Binding Update Message') :

   The deletion of a binding can be indicated by setting the Lifetime
   field to 0 and by setting the care-of address equal to the home
   address.  In deletion, the generation of the binding management key
   depends exclusively on the home keygen token, as explained in Section
   5.2.5.  (Note that while the senders are required to set both the
   Lifetime field to 0 and the care-of address equal to the home
   address, Section 9.5.1 rules for receivers are more liberal, and
   interpret either condition as a deletion.)

In section 9.5.1. of RFC 3775 (note that this subsection is part of
section '9. Correspondent Node Operation' but explicitly direct the
reader to section 10.3.2 for processing when the H flag is set):

   o  If the Lifetime specified in the Binding Update is zero or the
      specified care-of address matches the home address for the
      binding, then this is a request to delete the cached binding for
      the home address.  In this case, the Binding Update MUST include a
      valid home nonce index, and the care-of nonce index MUST be
      ignored by the correspondent node.  The generation of the binding
      management key depends then exclusively on the home keygen token
      (Section 5.2.5).  If the Home Registration (H) bit is set in the
      Binding Update, the Binding Update is processed according to the
      procedure specified in Section 10.3.2; otherwise, it is processed
      according to the procedure specified in Section 9.5.3.

Section 10.3.2. (Primary Care-of Address De-Registration) is based on
10.3.1 which is based on 9.5.1.

Cheers,

a+

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 05 May 2009 22:49:02 +1000

>    the value of the lifetime' in the BU)

=> Unfortunately that's no longer the case. Having the CoA = HoA doesn't
remove bindings.

>    interpret either condition as a deletion.)

=> Yes this is not true anymore.

Hesham

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 13:52:06 +0100

Hesham, responded while I was writing the e-mail below...which I am
still sending to make this even clearer.

As far as RFC3775 goes you are correct.

In draft-ietf-monami6-multiplecoa-13#section-5.6.3, however, we update
this to support home link registrations so that:

"   When the home binding is used, the mobile node MUST send a
   registering binding update with a Binding Identifier mobility option
   whith H flag set.  The lifetime MUST be set to a non-zero lifetime of
   the home binding, and the care-of address MUST be set to the home
   address."

George

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 16:01:32 +0200

Hi,

> => Yes this is not true anymore.

@hesham: I think you mean this is no more true in the context of
MCoA/flow-binding extensions (and not due to some changes introduced in
3775bis which I would have missed). Is that what you meant?

If this is correct, is it defined by the paragraph quoted by George
below (applying to MN-HA relationship) or are there any other parts of
the spec that revisit 3775-defined behavior on that topic?

>    the home binding, and the care-of address MUST be set to the home

@george: well, because the format of the packet as described above
(lft!=0, Care-of address set as HoA) explicitly fit the description of a
deregistration BU in 3775, I think it might be useful for developers
reading the spec to be aware of that w/o having to confront both spec
and then wonder about which is right. What do you think?

Anyway, our discussion is only for MN-HA exchanges. For MN-CN, the
drafts do not alter the weird expectations of 3775 about format of
deregistration BU, do they?

Cheers,

a+

ps: Another possible solution (not that it is in a ps of a mail, so ...)
would be to fill a ticket in the context of 3775bis to add a
clarification requiring the lft to be set to 0 in dereg BU and remove
the weird ability to dereg by having the care-of address set to the HoA.