[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Reviews of draft-ietf-mext-binding-revocation-02
Hi,
"Ahmad Muhanna" <amuhanna at nortel.com> writes:
>> > administrative reason. This mechanism enables the home domain to
>> > dynamically allow the user to act upon the revocation message in
>> > order to not have an unexpectedly interrupted mobile
>> IPv6 services.
>>
>> Well, when it receives the information, it's already too
>> late, isn't it?
>
> [Ahmad]
> What is meant here, the MN will have an instant but graceful indication
> that its mobility service is being revoked. At that time, the MN will be
> able to make an out of scope communication to check/enable/etc. the
> service with its provider, for example. This case is meant to
> replace/"be compared" the case when the HA deletes the binding and the
> tunnel without informing the MN.
What about that instead of the last sentence:
"This mechanism enables the home domain to dynamically allow the user to
act upon the revocation message in order to recover its interrupted
mobile IPv6 services."
>> > 3.4. Proxy MIPv6 Use Case
>> >
>> > the mobility entities, e.g. MAG and LMA, are always synchronized
>> > with respect to the status of the existing proxy mobile IPv6
>> > bindings. The binding revocation mechanism is generic enough that
>> > can be used in all applicable PMIPv6 scenarios and deployment
>>
>> ^^^^^^^^^^^
>> ^^^^
>>
>> "so that it can be" or "to be used"
>
> [Ahmad]
> I do not see any normative text here but, I think "can be used" is used
> to give more flexibility; but changing the text to "to be used" is fine
> with me if necessary.
What I meant is that the structure of the sentence look strange, but
maybe it's just my english.
>> What about replacing last sentence by following text:
>>
>> "If IPsec is used, the traffic selectors associated with the SP
>> protecting BU and BA MUST be extended to include Binding
>> Revocation
>> Signaling MH type <IANA-TBD>."
>
> [Ahmad]
> Looks good to me.
ack.
>> What about also including some rationale for this choice, w/ sth
>> like the following ? :
>>
>> "Extending the traffic selectors of the SP in order to
>> reuse the SA
>> protecting BU and BA (instead of creating new ones) provides the
>> insurance that those SA will be up and running when the revoking
>> entity will need to send a Binding Revocation Signaling message".
>>
> [Ahmad]
> This is good to me too.
> However, I would make a minor change: replace "provides insurance" with
> "ensures" and "will need" to "needs"
> The suggested text would read as follows:
>
> "Extending the traffic selectors of the SP in order to reuse the SA
> protecting BU and BA (instead of creating new ones) ensures that
> those SA will be up and running when the revoking entity needs
> to send a Binding Revocation Signaling message".
ack.
>> Last question on that paragraph: The last sentence start with
>> "If". Why? I mean, this is mandated by 3775. Is it for PMIPv6?
>>
>> > 6. Binding Revocation Message
>> >
>> > This section defines a Binding Revocation Message that
>> use a MH type
>> > <IANA-TBD> with a Binding Revocation type field that
>> follow the MH
>> > format described in section 6.1. [RFC3775]. The value in the
>>
>> ^^^^^^^^^^^^^^^^
>> 6.1 of [RFC3775] or just 6.1?
>>
> [Ahmad]
> Sure we can reference [RFC3775].
it's not what I meant. I meant that "[RFC3775]" sits there in the middle
of the sentence. Is it expected?
>> > Figure 6: Binding Revocation Acknowledgement Message
>> >
>> >
>> > Status
>> >
>> > 8-bit unsigned integer indicating the result of processing the
>> > Binding Revocation Indication message by the
>> receiving mobility
>> > entity. The following status values are currently defined.
>> >
>> > 0 success.
>> > 1 partial success.
>> > 2 Binding Does NOT Exist.
>> > 3 IPv4 HoA Binding Does NOT Exist.
>> > 4 Global Revocation NOT Authorized.
>> > 5 CAN NOT Identify Binding.
>> > 6 Revocation Failed, MN is Attached.
>>
>> The Binding Revocation Trigger values in Section 6.1 look
>> more self-explanatory. They are also mainly informational, right?
>
> [Ahmad]
> Yes, it is mainly informational. However, whenever any R. Trigger value
> means a specific action is needed on the side of the receiving mobility
> node, IMO, it needs to be documented. If we missed any of these, we can
> go back and do it.
>
>>
>> Here, it is not clear what "partial success" (1) or
>> "Revocation failed, MN is attached" mean, and what both
>> entities should expect when those are sent. Maybe the
>> rationale that were associated with those values when the
>> list was first created should be included in the document,
>> along with the expected behaviors (Are those status value just
>> informational?)
>>
>> Or did I missed some other section that provides that in the draft?
>
> [Ahmad]
> I agree it is mainly informational but some of these status is
> appropriate with certain scenarios. I believe those status values
> meanings and use are mentioned when these specific scenario are
> discussed later on.
I may have missed them but "partial success" and "Revocation failed, MN
is attached" (at least) are not.
>> > set, the home agent sets a flag in the mobile node BCE
>> to indicate
>> > that revocation is in progress and starts the MINDelayBRIs timer.
>> > The home agent maintains the mobile node BCE in this
>> state until it
>> > receives a Binding Revocation Acknowledgement or the
>> > BRIMaxRetransmitNumber is reached.
>>
>> What does "maintains the node BCE in this sate"? I mean, does
>> this mean that the mobile node is not able to perform
>> movement during that time?
>
> [Ahmad]
> We are talking about a race condition here which should be addressed
> based on the reason of the BRI and HA local policy. If the MN
> registration is being revoked for administrative reason, for example,
> then, IMO, it does not make sense to allow the mobile node to move
> anyway.
I understand your point, but the way it is specified in the draft does
not leave room for the reverse scenario: the extension provides the
ability to warn the user that his access *has been* interrupted but not
that it *will be* interrupted soon (i.e. no possible grace period).
>> If the revoking entity sends a BRI just when the mobile node
>> perform a handover (i.e. sends a BU), then locking the BCE
>> state will prevent the CoA update to happen on the revoking
>> entity and the retransmitted packets to be sent to the MN.
>
> [Ahmad]
> The revocation in progress flag is set until the HA receives a BRA or
> the BRIMaxRetransmitNumber expires. We could add some text to address
> this race condition and mention what the HA may do when this race
> condition occurs.
>
> "
> In a race condition case, the home agent may receive a BU from the
> mobile node while the mobile node's BCE has the revocation in progress
> flag set, the home agent should handle this case based on the reason for
> sending the Binding Revocation Indication message and its local policy.
> In this case, If the home agent accepts the BU, it needs to update the
> mobile node BCE accordingly, e.g. removing the revocation in progress
> flag.
> "
ok.
>> General comment: in the draft, the few times "Type 2 Header"
>> is used, it should probably be replaced by "Type 2 Routing
>> Header" for consistency.
>
> [Ahmad]
> Sure.
ack. thanks
Cheers,
a+
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext