[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
On Tue, Mar 17, 2009 at 4:00 AM, Christian Kaas-Petersen
<kaaspetersen at yahoo.dk> wrote:
>
> 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).
>
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.
> 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 <tsirtsis at googlemail.com>:
>
>> Fra: George Tsirtsis <tsirtsis at googlemail.com>
>> Emne: Re: [MEXT] Review of Re: I-D Action:draft-ietf-monami6-multiplecoa-12.txt
>> Til: "Christian Kaas-Petersen" <kaaspetersen at yahoo.dk>
>> Cc: "mext" <mext at ietf.org>
>> Dato: mandag 16. marts 2009 15.46
>> On Mon, Mar 16, 2009 at 7:10 AM,
>> Christian Kaas-Petersen
>> <kaaspetersen at yahoo.dk>
>> wrote:
>> >
>>
>> > --- Den lør 14/3/09 skrev George Tsirtsis <tsirtsis at googlemail.com>:
>> >
>> >> Fra: George Tsirtsis <tsirtsis at googlemail.com>
>> >> Emne: [MEXT] Review of Re: I-D
>> Action:draft-ietf-monami6-multiplecoa-12.txt
>> >> Til: "mext" <mext at ietf.org>,
>> "Jari Arkko" <jari.arkko at piuha.net>
>> >> 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
>