Re: [MEXT] Global Binding Revocation initiated by MAG

Ahmad

Thanks for the response.  Please see my comments inline.

Regards
S Magesh

  _____  

From: Ahmad Muhanna [mailto:amuhanna@nortel.com] 
Sent: Friday, December 12, 2008 3:38 AM
To: Magesh Shanmugam
Cc: mext@ietf.org
Subject: RE: 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?

[Magesh] I agree with your above statement.

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".

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