Subject: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt

From: Christian Kaas-Petersen <[email-masked]>
Date: Tue, 17 Mar 2009 08:00:42 +0000 (GMT)

The packets I proposed I get from draft 12, section 5.4 second paragraph
(which details a de-registration with lifetime=0 and absence of
care-of address) and section 5.6.3 bullets number 1 and 2 (which detail
the presence of the H-bit and the absence of the care-of address).

To me, there is no need to register a binding where CoA=HoA (use of
home link), unless flow binding is used.  Section 5.6.5 is new in
draft 12 and 11 as compared to draft 10, and it was introduced as a
specific add-on to allow assigning specific flow bindings to the home
link.  Of course, one may now ask whether it is useful with two
mechanisms for signaling home link is also available: (a) the CoA=HoA
mechanism and (b) the H-bit mechanism.  Maybe the CoA=HoA mechanism
should be seen as a flow binding specific item and moved to the flow
binding draft.  This continues the discussion whether MCoA and flow
binding should be seen as one item or as two separate items.

Christian

--- Den man 16/3/09 skrev George Tsirtsis <[email-masked]>:

> Fra: George Tsirtsis <[email-masked]>
> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
> Til: "Christian Kaas-Petersen" <[email-masked]>
> Cc: "mext" <[email-masked]>
> Dato: mandag 16. marts 2009 15.46
> On Mon, Mar 16, 2009 at 7:10 AM,
> Christian Kaas-Petersen
> <[email-masked]>
> wrote:
> >
> 
> > --- Den lør 14/3/09 skrev George Tsirtsis <[email-masked]>:
> >
> >> Fra: George Tsirtsis <[email-masked]>
> >> Emne: [MEXT] Review of Re: I-D
> Action:draft-ietf-monami6-multiplecoa-12.txt
> >> Til: "mext" <[email-masked]>,
> "Jari Arkko" <[email-masked]>
> >> Dato: lørdag 14. marts 2009 16.42
> >> I was reading the document again in
> >> order to review the Flow Bindings
> >> draft but I found that the MCoA draft is confusing
> and
> >> incomplete in a
> >> number of places.
> >>
> >> The following are issues that came up after a
> review of
> >> sections 1- 6.
> >> I have not yet reviewed sections 7 to 11.
> >>
> >> 1) Binding De-registrations
> >> I think the descriptions of 5.4, 5.5., 5.6., are
> terribly
> >> confused,
> >> WRT what a normal MCoA registration is, vs what a
> home
> >> binding MCoA
> >> registration is, and how they relate to
> >> 3775-de-registration.
> >> a) I think we have to make clear that Binding
> >> De-registrations as
> >> described in RFC3775 are still valid and have
> exactly the
> >> same effect
> >> when MCoA is used i.e., removes all bindings from
> the HA
> >> and all
> >> packets flow to the MN via the home link
> >> b) If the MN wants to use simultaneous home and
> foreign
> >> links it MUST
> >> NOT send an RFC3775 style  deregistration.
> Instead it
> >> SHOULD send an
> >> MCoA registration with:
> >>  - A non-zero lifetime
> >>  - a Binding Identifier mobility option,
> including
> >>         *  'H' flag set to "1",
> >>         *  BID field set to a
> >> value used for the home link,
> >>         * CoA field set to the home
> >> address
> >> - any other Binding Identifier mobility options
> registering
> >> CoAs on
> >> foreign links
> >>
> >
> > Example: The mobile node is away, and has the two
> registrations in
> > the home agent's binding cache
> >
> >    v6HoA BID1 -> v6CoA1
> >    v6HoA BID2 -> v6CoA2
> >
> > The interface known as BID2 attaches to the home link,
> and the mobile node
> > wants to continue using both interfaces.  The mobile
> node could send
> > a binding update
> >
> >    BU
> >        lifetime = 0
> >        BID-option: BID2, H-bit=1 (no care-of
> address should be given)
> >
> 
> GT> It is not exactly clear to me what you disagree on
> exactly from my
> comment above. I am not sure where the draft allows the
> above though
> (maybe I am missing something?). A BU with Lifetime=0 is a
> de-registration BU and it simply removes BID2 from the
> binding list.
> According to the current draft the MN also needs to
> register CoA=HoA
> in another BID i.e.:
> BU
>   lifetime >0
>   O=0
>  BID-option: BID3, CoA field=v6HoA, and H=1
> 
> What is not so clear is whether both of the above can be
> done at the
> same time:e.g.,
> 
> BU
>   lifetime >0
>   O=1
>  BID-option: BID3, CoA field=v6HoA, and H=1
>  BID-option: BID1, CoA field=v6CoA, and H=1
> 
> Does H flag matter in this case?
> 
> > When flow binding in not used, it is not required to
> know the
> > BID-value found on the home link.  When at a later
> time the mobile node
> > refreshes the binding cache, it will send
> >
> >    BU
> >        lifetime > 0
> >        BID-option: BID1, H-bit=1, v6CoA1
> >
> >

      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: Tue, 17 Mar 2009 06:16:12 -0400

> the presence of the H-bit and the absence of the care-of address).

GT> And here is a good illustration of how confusing this draft is:
Section 5.4 says:
"   If a mobile node wants to delete a particular binding(s) from its
   home agent and correspondent nodes, the mobile node sends a Binding
   Update with lifetime set to zero and includes a Binding Identifier
   mobility option(s) with the BID(s) it wants to de-register.  The
   receiver will remove only the care-of address(es) that match(es) the
   specified BID(s).  The care-of addresses field in each mobility
   option SHOULD be omitted by the sender (i.e. the field does not
   appear in the option) and MUST be ignored by the receiver.  This is
   because the receiver will remove the binding that matches the
   specified BID."

GT> These are clearly instructions regarding how a BID/CoA is removed.
It does not mention what the H flag should be set to and thus the HA
flag is irrelevant. It just says that BU with lifetime=0 and BID with
no CoA mean deregistration of the given BID.

GT> Then in Section 5.6.3, bullet 2, it says:
"   o  The mobile node MUST include the Binding Identifier mobility
      option specifying the BID the mobile node had previously
      associated with the interface attached to the home link.  The 'H'
      flag MUST be set in the Binding Identifier mobility option.  For
      the binding deregistration, a mobile node SHOULD NOT store a
      care-of address in the Care-of Address field of the Binding
      Identifier mobility option.  The receiver, the home agent, can
      match the removed binding with BID value in the Binding Identifier
      mobility option."
GT> It describes a home registration where the BID with H=1 and no
CoA. But what should the Lifetime be? I claim it should be >0 because
if it is 0 this is a deregistration no matter what the H flag says.
you think otherwise.

GT> Also what s this first part of this bullet all about? "The mobile
node MUST include the Binding Identifier mobility
      option specifying the BID the mobile node had previously
      associated with the interface attached to the home link." Why
does this protocol assume that the interface connecting to the home
link already has a BID and was connected somewhere else earlier? What
happens if the interface connecting to the HA if a new one (e.g., I
just pluged in my eathernet cable)? This is clearly not necessary and
has nothing to do with the spec.

---

From: Benjamin Lim <[email-masked]>
Date: Wed, 18 Mar 2009 15:17:16 +0800

Hi Christian, all,

Pls see inline for some of my comments.

Christian Kaas-Petersen wrote:
> home link), unless flow binding is used.  
[Ben] Agree, being simultaneous connected on a home link and foreign
link does not imply that flow binding must be used.

For example, MN wants to receive packets from devices on MN's home link
through MN's home attached interface.  Rather than having those devices
send the packet to HA who will then forward it to MN's foreign attached
interface, MN uses the 'H' flag to turn off ND-proxy at HA and advertise
MN's home attached interface.  This way, devices in the home link will
send packets to MN's home attached interface.  On the other hand, any
packets not from the home link (e.g. from the global Internet) will
arrive at HA, who in turn forward it to MN's foreign attached interface.

As you can see from the above example, flow binding is not used.

> Section 5.6.5 is new in
[Ben] Your point is valid here and I feel that we did not really
consider fully on how to in-corporate flow binding into the MCoA draft
(hence the confusion).  Since the MCoA draft is undergoing IESG review,
in order not to delay its progress, it might be better to remove all
descriptions on how to use flow binding with the MCoA draft and have
these descriptions covered in the flow binding draft.

Regards,
Benjamin Lim

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