Re: [MEXT] Global Binding Revocation initiated by MAG

Magesh,
please see inline.

Regards, 
Ahmad

________________________________

	When the 'G' bit is used for a Global revocation and in line
with the above logic, we need to communicate the MAG-ID. I understand
that currently we do not have a mobility option specific to carry
MAG-ID, however, we defined a very specific scenario where the 'G' bit
is set and the R. Trigger is set to "per-peer policy". Only in this
case, the draft currently allow the MAG to include its ID in the MN-ID
option. Sending the BRI and BRA is assumed to follow the exact procedure
for PBU and PBA with respect to the source and dest. IP addresses.

	[Magesh] I'm not in favour of having a new mobility option for
carrying the MAG-ID, my concern is if MAG-ID is carried in the BRI
message, how does LMA knows all the binding session(s) related to that
particular MAG (your point here is implementation dependent).  Since
from RFC5213 , it is clear that Binding Cache & Policy Profile does not
maintain the MAG-ID, i feel it is better to add a statement in Binding
Revocation draft regarding the way MAG-ID is handled by LMA for
identifying all the binding session(s).

	In the vice versa case (i.e. LMA sending Global Revocation to
MAG with Revocation Trigger set to "Per-Peer Policy" ), the BRI
triggered by LMA will not have any mobility option(s).  When MAG
receives the
	BRI, based on the LMAA (i.e. source address in the received BRI
message), it will retrieve all the binding session(s) and revoke them.
I just need the same kind of procedure when MAG sends BRI with status
set to "Per-Peer Policy". 

	[Ahmad]
	As I said earlier in my reply. If the case of the LMA is
sufficient to you, then the case of the MAG is sufficient too. Because,
in every BRI sent from the MAG to the LMA, the MAG follow the same
procedure as in sending a PBU. i.e. src address = pCoA. However, as I
said earlier, that could be NOT enough in case the MAG has multiple
pCoAs. In this case, my suggestion is: Whenever MAG sends a BRI with the
(G) bit is set and the R. Trigger is set to "per-Peer Policy", the MAG
must identify the pCoA(s) by including them in Alternate CoA options in
the BRI.

	Is that logic acceptable to you or you have a problem with that?

	Regards,
	Ahmad