Re: [MEXT] Acknowledgements for Revocation Messages

["Ahmad Muhanna" <[e-mail]>]

Hello Jari,
Sorry for taking so long before getting back to you. Please see
responses inline.

Regards,
Ahmad

> -----Original Message-----
> From: Jari Arkko [mailto:[e-mail]] 
> Sent: Monday, September 14, 2009 5:41 AM
> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli
> Cc: [e-mail]
> Subject: Re: Acknowledgements for Revocation Messages
> 
> At this point we are only changing the document if there's a 
> technical problem somewhere.
[Ahmad]
Thanks! 
I believe features that already had the wg consensus are not supposed to
be removed for the sake of just removing it or because all of a sudden
some people believe it is not necessary. Unless, there is a technical
issue and problem in the respected functionality (something broken),
IMO, it should not be removed.

> 
> That being said, I believe there were/are issues in the rules 
> that specify when a BRA is going to be sent. So something has 
> to be fixed in any case. 
[Ahmad]
IMO, they are not technical issues that breaks the protocol. I believe
we received good comments from Ben to clarify few points about the
protocol handling and setting of the Acknowledge (A) bit. These
clarifications have been agreed upon and the next revision will captured
all of these clarifications.


> The fix can be:
> 
> 1. Make it clear what the rules are, and ensure that the 
> rules are logically consistent. RFC 3775 Section 9.5.4 should 
> be default approach, and I don't really see no reason to 
> deviate from that approach if we have the A bit to begin 
> with. 
[Ahmad]
What I am struggling with here is: in MIP6, the message exchange is
usually between the MN and the HA or the MN and the CN; with the BA
always coming from either the HA or the CN. However, in the case of
Binding Revocation, every single node may send or receive a BRA; except
the MN which always send a BRA.

May be the right approach is: after addressing all of Ben's comments, it
would be good if we can identify what is missing? Or what is NOT there
that breaks the protocol. That will be a great help.


> I'm not sure I like the rules that mix G and A bits; I 
> would rather keep separate things separate. 
[Ahmad]
Hmmm... I am not sure we should call it mixing:) Because what would you
call the following text in RFC3775:
"
   ..............................................  .............. After
   selecting a new primary care-of address, the mobile node MUST send a
   Binding Update containing that care-of address to its home agent.
   The Binding Update MUST have the Home Registration (H) and
   Acknowledge (A) bits set .."

Is that mixing the (H) and (A) bits?

IMO, in order to have a robust and sane protocol, crucial and critical
scenarios need to be identified and explicit recommendation is needed.
In the whole binding revocation draft, there is only one case that the
Acknowledge (A) bit setting is mandated when another bit is set. It is
when the BRI has the capabilities to wipe out all of the BCEs between
the MAG and its LMA peer, or vice versa. I believe that scenario is
crucial and critical enough for this specification to make sure that the
sending node REQUEST a BRA back by setting the (A) bit.


> In any case, what 
> the specific issues Ben and Vijay raised need to be fixed.

[Ahmad]
I guess, we need to separate between the two sets of comments. Ben's
comments has the following basic logic, the (A) bit should have the
authoritative power to mandate the receiving node to send back a BRA.
That is actually a good comment and all of my debate with Ben was on the
cases when the receiving node is NOT able to send a BRA, in this case,
it is the mobile node. Even that one, we closed it too!

However, with respect to Vijay's comments, He is raising comments
against text that have the wg consensus and I disagree that these are
issues to start with before thinking of whether they need to be fixed or
not. Here they are:

1. Removing the (A) bit from the BRI and BRA and assume that the (A) bit
is always set and a BRA is mandated for each BRI. (I DISAGREE, please
see below)

2. If we have a careless implementation that sent a BRI with the (G) bit
set and the revocation trigger value "Per-Peer Policy" and the (A) bit
is NOT set (against the specification recommendation), Vijay wants the
receiving node to send a BRA with status error or in his late posting to
use ICMP error message. Neither one should work. IMO, a BRA MUST NOT be
SENT because the sending node does NOT expect one! Now, we can agree on
whether the receiving node discard the message or accept it, I am open
for either one, but I favor discarding it. In order to make sure that
the sending node take a note and make sure that if it needs this to
work, the (A) bit needs to be set. 
IMO, A CARELESS SENDING NODE SHOULD NOT BE REWARDED!:)

3. The issue of Alternate care of address use. Well, the text was
clarified based on specific questions from Ben. The clarification text
did not change any functionality or add anything new other than spell
out what everyone knows. Vijay raised the issue that in case of MIP6,
the source address of the IPv6 packet that carried the BU with Alternate
Care-of address option included, MAY become invalid, that because this
mechanism is used as a pre-registration mechanism to register a new
care-of address by sending a BU from the old Care-of address. Honestly,
I am not sure of the validity of this usecase in the scope of MIP6
(RFC3775). IMO, pre-registration needs to be clearly signaled to the HA.
Because, how the HA would know when the source IP address becomes
invalid? Although, it has just sent the BA to that address! 


> 
> 2. Remove the A bit and make the spec simpler. 
[Ahmad]
I disagree that will make the protocol simpler. It rather makes the
protocol incomplete!
Binding revocation covers a wide range of usecase that all of them CAN
NOT be treated with the same severity. The funny thing here is that for
sometime people argued on the ml that Binding Revocation can be
addressed via a generic notification (send it and forget about it) and
all of a sudden, we are going to the other extreme! Binding revocation
is always authoritative and critical and a BRA MUST be sent all the
time. That is a very rigid approach which lacks the full realization of
the binding revocation usecases. 

NOT only that, but a protocol which is used for creating a new BCE
(MIP6) uses the (A) bit optionality while a protocol which allows the
home anchor point to release the resources of a mobile node session, all
of a sudden MUST be as rigid as a rock and a BRA is ALWAYS sent back! 

I can go on and on with respect to this but, IMO, this is a recipe for
killing creativity and the chance for implementations to differ from one
another. Those implementations which fall in love with assuming the (A)
bit is set all the time can simply make the choice to set the (A) bit in
every BRI message and be ready for retransmission. That is absolutely
fine and is currently allowed by the protocol.


> I do not 
> personally believe the flexibility is useful in this context, 
> so I do not object to removing it. However, given that we are 
> so far in the process, we should not do this change if there 
> are people who are opposing it. 
[Ahmad]
Please see comments above.

> Ahmad, since you were the one 
> arguing that there is a need, can you re-think this in view 
> of whether your objections are about real-live business needs 
> or reducing late changes? If its more about the latter, maybe 
> the right thing is to get rid of the bit.

[Ahmad]

In simple words, I respectfully disagree. Let me explain why.
As I mentioned above, Binding Revocation mechanism addresses a wide
range of usecases with various severity and consequences. Some of which
are documented in the draft and many others are not. WHY when the LMA/HA
would like to revoke a BCE of an important fellow needs to handle that
as when revoking the BCE of NO-ONE-KNOWS-ABOUT-COPPER=USER-X? Sending a
BRI message with the (A) bit cleared in certain cases, reduces
signaling, retransmission, and makes a lot of sense. 

Best Regards,
Ahmad
 
> 
> Jari
> 
>