Re: [MEXT] Global Binding Revocation initiated by MAG

Magesh,

Sorry for the late response. Had to travel for a short trip.

I see what you are saying here. May be what we need to do is to take one
step back and look into the reason for the Global revocation.

The intention is to allow one of the PMIPv6 domain nodes (MAG or LMA) to
inform the other to revoke all bindings that is served by these two
nodes or a partial number of these binding, for example proxy MIP6
bindings that have their MN-ID which belong to a specific realm, e.g.,
(*@abc.com). 

When the 'G' bit is used for a partial Global revocation, "Revoking Node
Local Policy", the draft requires that another identifier MUST be
included in the BRI which is used to identify these proxy bindings. I
believe that we do not have any problem in that one. Right?

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.

On the other hand, I see your point of defining a default mechanism to
be used by the received Node to identify all these proxy Bindings. IMO,
we need probably to have a generic approach that applicable to all
cases. for example, a MAG may have more than one pCoA with a specific
LMA. As a suggestion, I would recommend, in this case ONLY that the pCoA
always be included in the Alternate CoA option in the BRI. Additionally,
when the MAG share more than one pCoA, the MAG MUST include each pCoA in
a separate Alternate-CoA option.

Does sound acceptable? 

As a side note, implementations may have their own mechanism where the
MAG-ID is somehow known to the LMA, for example, and that implementation
would identify all of the proxy Binding that are served at that MAG
using the MAG-ID, but that is out of scope.

Regards, 
Ahmad 

________________________________

	From: Magesh Shanmugam [mailto:mshanmugam@intellinet-india.com] 
	Sent: Wednesday, December 10, 2008 12:55 AM
	To: Muhanna, Ahmad (RICH1:2H10)
	Cc: mext@ietf.org
	Subject: Global Binding Revocation initiated by MAG

	Ahmad

	In PMIPv6 domain, when MAG initiates Global Binding Revocation
(G bit set), it will send the MAG identity in the MN-ID option (as per
section 3.1 of binding-revocation draft-02).

	As per RFC 5213, while creating Binding Cache Entry @ LMA, we
have MN-ID, HNP(s), Proxy Care of Address, etc in the received PBU
message which will be updated in the
	BC entry after validation.  MAG-ID will not be stored in the
Binding Cache Entry when individual binding session(s) are processed and
validated by LMA.  
	When MAG triggers Global Binding Revocation, it will send the
MAG-ID in the MN-ID option.  Since LMA won't maintain the MAG-ID for
each binding session (i.e. in BC entry), 
	it will be tough for the LMA to identify all the binding(s) from
the specific MAG.  

	Instead of having MAG-ID in the MN-ID option for Global
Revocation, if we use Proxy Care of Address (through the source IP
address of the BRI message or 
	Alternate Care of Address mobility option, if source address is
different from proxy care of address), it will be easy for LMA to
retrieve all the binding(s), 
	since Proxy Care of Address is stored in the Binding Cache
entry.

	Thanks
	S Magesh