Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt

["Ahmad Muhanna" <amuhanna at nortel.com>]

Hi Joel,
Please see responses inline.

Regards,
Ahmad
 

> -----Original Message-----
> From: Joel Hortelius [mailto:joel.hortelius at interpeak.se] 
> Sent: Friday, March 13, 2009 4:28 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: mext; netlmm at ietf.org
> Subject: Re: [MEXT] Review of 
> draft-ietf-mext-binding-revocation-03.txt
> 
> Resending my questions in brief form;
> 
> 1; Since some triggers do require specific actions, and the 
> draft uses the word "currently defined" for trigger 
> definitions indicating new triggers may be added - how is an 
> implementation supposed to deal with future triggers that may 
> or may not require specific action?
>
 
[Ahmad]
I believe the safest approach is to allow the receiving node to reject
such message with a proper status code, "Revocation Trigger NOT
Supported" or we can make it more generic "Specific Revocation
Functionality NOT Supported"

> 2; What combinations are possible? What triggers may be used 
> with the 'G' bit? Some triggers have been indicated that they 
> should be used with 'G', but others do not. Some combinations 
> do not make sense. Does 'G'
> ONLY work with those explicitly specified? If so, what should 
> one do with the other combinations if they appear?

[Ahmad]
Yes, Global Revocation is meant to communicate a Mass revocation which
impact all mobility sessions between the pair MAG-LMA. Another use case
was discussed to allow the LMA, for example, to revoke multiple sessions
that belong to all MN(s) which share a specific criteria, e.g., MN-ID
belong to a certain realm. The receiving node need to be able to
differentiate between the two cases. Thus, there was two different
Revocation Triggers.

Any other combinations of (G) bit and other R. T. is NOT supported. IMO,
the receiving node should reject that BRI.
We can add text for this one. 

> 
> 3; Since you define your own namespace regarding revocation 
> trigger message types (BRI, BRA), it would have made sense to 
> me to split the messages even further and have a Global BRI 
> and Global BRA instead of the 'G' bit, AND separate the 
> trigger reason values into a global and per binding trigger 
> namespaces. Mixing global trigger reasons with per-binding 
> session reason, where the global "namespace" requires 
> specific actions based on trigger reason quickly gets 
> complex. Having them separated would remove the most obscure 
> combinations, which are either meaningless or invalid. 

[Ahmad]
Good point. I see what you are saying about the separation of the
triggers. However I do not see any value in creating different message
type for Global revocation. It is the same message and duplication
should be eliminated as much as possible.

> 
> 4; Just remembered that the per-session revocation do require 
> specific action on some triggers (unknown handoff). Perhaps 
> splitting the trigger
> values:
> < 128  -"soft" triggers; revoke and log - may use reason for 
> for undefined action to restore connectivity. This would be 
> "administrative", "user initiated", etc.
> >= 128 -"hard" trigger. If unknown, reply with "unsupported trigger",
> otherwise do the actions defined by the trigger. This would 
> be "per-peer", "node-local", "unknown handoff" etc.

[Ahmad]
Okay, this means that we will have the following combination:

Per-MN Soft,
Per-MN Hard,

Global, Soft, and
Global, hard

That is probably too much. I believe separating the triggers to per-MN
and Global will suffice. Introducing Status code of "Unsupported
Trigger" is a good idea too.

> 
> 5; What is one supposed to do if both 'G' and 'V' bit are set 
> in a BRI?

[Ahmad]
I actually thought about this one but I was not able to come up with a
usecase that justifies it. In other words, why the LMA, for example,
would send a Global BRI to revoke all IPv4 binding only?
If there is a valid usecase, we could add it.

> 
> 6; The partial success on MAG is hazy; When is it supposed to be used?
[Ahmad]
The original intention was: If the MAG, for example, received a BRI
which impacts multiple sessions and one of these sessions for a reason
or another was already removed because of race condition, for example,
the MAG would set the status Code to either "success" or "partial
success". However, it seems that this "partial success" opens the door
for a lot of interpretations. If the group thinks that is problematic,
we can actually remove it completely.


> 
> 7; The out of sync BCE state trigger, when is it supposed to 
> be used? I can't find any reference to it in the doc.

[Ahmad]
Hmmm... I guess we missed the text for this one. Will add it.

> 
> Regards,
> Joel Hortelius
> 
> 
>