Subject: [Mip6] FW: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 28 May 2007 07:43:44 -0500

Hello Folks,

We submitted this draft for Binding Revocation for IPv6 Mobility. It
handles several use cases which are applicable to Client Mobile IPv6 and
PMIPv6. Please take a look and we appreciate your comments.

Thanks in advance.

Regards,
Ahmad Muhanna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 25, 2007 2:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-muhanna-mip6-binding-revocation-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Binding Revocation for IPv6 Mobility
	Author(s)	: A. Muhanna, et al.
	Filename	: draft-muhanna-mip6-binding-revocation-00.txt
	Pages		: 18
	Date		: 2007-5-25
	
   The service binding revocation semantics are missing in Mobile IPv6
   Specificaion [RFC-3775] and PMIPv6 [PMIP6-SPEC].  This document
   defines the semantics of the revocation of a mobile node registration
   binding, which could have been established using a Client Mobile IPv6
   or a Proxy Mobile IPv6 signaling.  The proposed revocation mechanism
   uses generic message properties which is applicable to Mobile IPv6
   and Proxy Mobile IPv6 and can be used by any two mobility entities.
   As an example, this mechanism allows local mobility agent, involved
   in providing IP mobility services to a mobile node, to notify the
   mobility access gateway of the termination of the mobile node
   registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocatio
n-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-muhanna-mip6-binding-revocation-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 30 May 2007 12:19:23 -0500

Ahmad,

Binding revocation is a useful feature.
However, we have a I-D: Mobility Header Signaling Message
<draft-haley-mip6-mh-signaling-02.txt> which can be used as the means for
binding revocation as well.

In Prague, we discussed this I-D and agreed to consider it as a WG document.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 May 2007 14:21:49 -0500

Hi Raj,

If I remember correctly, since no new options were defined by the
draft-haley, a question was asked about the scope of the notification
messages and it was mentioned, Opaque.

IMO, the draft-haley is intended for sending a generic notification
(fyi) messages, where detailed receiver action is not required and does
not need to be specified. The common use cases include, expiry of
prepaid billing, service outage related notifications, new promotional
information.

Revocation is a detailed topic which handles many scenarios and use
cases addressing both NetLMM and MIP6 scope with potential to address
some very specific scenarios that need a detailed attention by the
receiver and most probably a reply after processing the revocation
indication message. Overloading a generic notification (fyi) messages to
handle all of the revocation scenarios is similar to trying to fit an
elephant in a refrigerator :) 

IMO, the generic notification (fyi) messages would quite restrict and
limit the revocation mechanism potential to address many immanent
scenarios that will evolve due to the interaction of MIP6 and PMIPv6
when deployed over the heterogeneous nature of the mobile IP network at
large.

I strongly believe that the revocation mechanism introduced in the
Binding Revocation draft needs to be addressed separately from the
notification (fyi) messages proposed by draft-haley.

Regards,
Ahmad

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Wednesday, May 30, 2007 12:19 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: Re: [Mip6] FW: I-D 
> ACTION:draft-muhanna-mip6-binding-revocation-00.txt
> 
> 
> Ahmad,
> 
> <draft-haley-mip6-mh-signaling-02.txt> which can be used as 
> the means for binding revocation as well.
> 
> > handles several use cases which are applicable to Client 
> Mobile IPv6 
> > and PMIPv6. Please take a look and we appreciate your comments.
> > 
> > Thanks in advance.
> > 
> > Regards,
> > Ahmad Muhanna
> > 
> > You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce
> > logging in, type "cd internet-drafts" and then "get 
> > draft-muhanna-mip6-binding-revocation-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > MIME-encoded form by using the "mpack" utility.  To use 
> this feature, 
> > insert the command "ENCODING mime" before the "FILE"
> > command.  To decode the response(s), you will need "munpack" or a 
> > MIME-compliant mail reader.  Different MIME-compliant mail readers 
> "multipart" 
> > MIME messages (i.e. documents which have been split up into 
> multiple 
> > messages), so check your local documentation on how to manipulate 
> > these messages.
> >

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 30 May 2007 14:41:41 -0500

Hi Raj,

I strongly disagree on the idea of designing a protocol which is used as
a container for other protocols. Each protocol should have a limited
scope and designed according to certain requirements. It is very
difficult to design  a generic protocol which satisfy all the
requirements for all future protocols. This container idea has many
issues, the simplest is that it increases, unnecessarily, the processing
time for the contained protocol (e.g. revocation). In addition there
some situations where a simple Request/Reply will not be enough to do
the job. Let us leave each protocol designer(s) to do what it is
required to do and don't limit their thinking. 

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 12:19 PM
To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
Subject: Re: [Mip6] FW: I-D

Ahmad,

Binding revocation is a useful feature.
However, we have a I-D: Mobility Header Signaling Message
<draft-haley-mip6-mh-signaling-02.txt> which can be used as the means
for binding revocation as well.

In Prague, we discussed this I-D and agreed to consider it as a WG
document.

-Raj

On 5/28/07 7:43 AM, "ext Ahmad Muhanna" <[email-masked]> wrote:

> handles several use cases which are applicable to Client Mobile IPv6 

> the message. You can also visit 
> "FILE /internet-drafts/draft-muhanna-mip6-binding-revocation-00.txt".
> 
> MIME-encoded form by using the "mpack" utility.  To use this feature, 
> insert the command "ENCODING mime" before the "FILE" command.  To 
> decode the response(s), you will need "munpack" or a MIME-compliant 
> mail reader.  Different MIME-compliant mail readers
> Internet-Draft. _______________________________________________
> Mip6 mailing list
> [email-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 30 May 2007 15:19:24 -0500

Hi Ahmad,

Would you not consider binding revocation by an HA as a notification message
from the HA to the MN?

The subsequent actions or behavior of the MN and HA resulting from such a
notification (binding revocation) is to be specified. But I am not sure if
there is a need to have new signaling messages for accomplishing binding
revocation. 

What the I-D draft-haley-mip6-mh-signaling is specifying (from what I
understood) is a mechanism to do signaling between the HA<->MN. It is
specifying a generic mechanism for signaling which may be for various
reasons including the examples that you quote below. I don't know if there
would be any limitations of using the generic notification extension for the
purpose of binding revocation.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 30 May 2007 15:24:11 -0500

MK,

I don't think anyone is designing a new protocol here. In MIP6 we have a
protocol (RFC3775) and are now extending it for meeting some of the
requirements which would enable deployment and adding a few new limited
features.

The mobility header signaling message is a generic extension that can be
used for various purposes as indicated in the draft itself. To me binding
revocation is merely another notification.
I don't understand what complexities you are refering to below or processing
issue.

Can you clarify why the binding revocation cannot be solved by the
specification of an option in the mobility header signaling message?

-Raj

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 30 May 2007 15:57:01 -0500

Hi Raj,

If we include revocation protocol in information options, we will end up
with three levels of protocol complexity as follows:

1- The Information option Request message.
2- The information option containing the revocation request, let us call
it revocation option.
3- the revocation attributes, or sub-options.

This means that the revocation option needs to be structured very much
similarly to the Binding Revocation Indication message, as per Binding
Revocation draft, where it has to carry all possible options as
sub-options. This simply a control protocol imbedded inside another one
which introduce unnecessary complexity. 

If we don't have this container mechanism, the process is simple.

1- The revocation protocol request message.
2- The revocation related options.

Regards

Mohamed

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Wednesday, May 30, 2007 3:24 PM
To: Khalil, Mohamed (RICH2:2S20); [email-masked]
Subject: Re: [Mip6] FW: I-D

MK,

The mobility header signaling message is a generic extension that can be
used for various purposes as indicated in the draft itself. To me
binding revocation is merely another notification. I don't understand
what complexities you are refering to below or processing issue.

-Raj 

On 5/30/07 2:41 PM, "ext Mohamed Khalil" <[email-masked]> wrote:

> Hi Raj,
> 
> I strongly disagree on the idea of designing a protocol which is used 
> as a container for other protocols. Each protocol should have a 
> limited scope and designed according to certain requirements. It is 
> very difficult to design  a generic protocol which satisfy all the 
> issues, the simplest is that it increases, unnecessarily, the 
> processing time for the contained protocol (e.g. revocation). In 
> addition there some situations where a simple Request/Reply will not 
> be enough to do the job. Let us leave each protocol designer(s) to do 
> what it is required to do and don't limit their thinking.
> 
>> http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revoca
>> t
>> io
>> n-00.txt
>> 

>> mail reader.  Different MIME-compliant mail readers exhibit different

>> behavior, especially when dealing with "multipart" MIME messages 
>> (i.e. documents which have been split up into multiple messages), so 
>> check your local documentation on how to manipulate these messages.
>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 30 May 2007 16:38:59 -0500

Hi Raj,
Please see my comments inline.

Regards,
Ahmad

> Sent: Wednesday, May 30, 2007 3:19 PM
> Would you not consider binding revocation by an HA as a 
> notification message from the HA to the MN?

[Ahmad]
As usual, the devil in the details. In general, as you may agree, any
thing is possible. However, IMO, trying to use the generic notification
messages for registration revocation introduces an unnecessary
complexity and, I believe is not the best possible way to go forward.
With the expected complexity of the Mobile IP network layout and the
real need to support seamless mobility across heterogeneous access
network, a MN binding may experience different states during one single
call. 

I am very well aware and understand that we need to restrict our
discussion to Client MIPv6 on this wg mailing list. However, I strongly
believe that we need to have one revocation mechanism for Client MIPv6
and PMIPv6 for the following reasons:

1. At IETF, the trend seems to be more of a consolidation of related wg
trend. MIPv6 and PMIPv6 probably good candidates.
2. More importantly and due to the different access network deployment,
a Client MIPv6 binding can very possibly be modified by a PMIPv6 BU
during a transitional scenario.
3. Last but not least, the co-location of LMA and HA is a very possible
scenario and a single protocol to handle revocation for both MIPv6 and
PMIPv6 is an serious plus.

In Summary:
I look at the binding revocation mechanism as "the common denominator"
for MIPv6 and PMIPv6 where it can be used to maintain the best possible
use of the network available resources. This means that any introduced
revocation mechanism needs to address all possible scenarios in MIPv6
and PMIPv6. Having this in mind, I believe sneaking the binding
revocation protocol inside the generic notification messages is not
probably the best we can do. A separate clean revocation mechanism has
the flexibility and the potential to address many scenarios that we may
not have yet identified.

Best Regards,
Ahmad

> 
> The subsequent actions or behavior of the MN and HA resulting 
> from such a notification (binding revocation) is to be 
> specified. But I am not sure if there is a need to have new 
> signaling messages for accomplishing binding revocation. 
> 
> understood) is a mechanism to do signaling between the 
> HA<->MN. It is specifying a generic mechanism for signaling 
> which may be for various reasons including the examples that 
> you quote below. I don't know if there would be any 
> limitations of using the generic notification extension for 
> the purpose of binding revocation.
> 
> -Raj
> 
> 
> > (fyi) messages, where detailed receiver action is not required and 
> > does not need to be specified. The common use cases 
> include, expiry of 
> > indication message. Overloading a generic notification 
> (fyi) messages 
> > to handle all of the revocation scenarios is similar to 
> trying to fit 
> > an elephant in a refrigerator :)
> > 
> > when deployed over the heterogeneous nature of the mobile 
> IP network 
> > at large.
> >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 30 May 2007 17:40:44 -0400

Hi Raj,

I think the confusion is regarding the scope of the two documents. 

I think the scope of I-D: mh-signaling is quite generic with many uses
cases as described in that document. Besides the uses cases that are
described in that document there may be other use cases that are
deployment specific. That's why I would consider this document to have a
generic scope with opaque container to accommodate many uses cases. No
response from the receiver is mandated in this mechanism.

The scope of I-D: binding-revocation is very specific i.e. revoke the
mobility binding with the MN, HA, (and MAG, LMA). The use cases for this
mechanism are specific as well. A response from the receiver is mandated
in some cases in this mechanism. 

So, I think we should agree on the scope of these two documents and
progress both of them through the IETF process.

BR,
Kuntal

> To: ext Ahmad Muhanna; [email-masked]
ACTION:draft-muhanna-mip6-binding-revocation-
> 00.txt
for
> > handles several use cases which are applicable to Client Mobile IPv6
and

---

From: Brian Haley <[email-masked]>
Date: Thu, 31 May 2007 11:58:31 -0400

Hi Ahmad,

> prepaid billing, service outage related notifications, new promotional

The generic notification message is a delivery mechanism, the receiver 
action for the opaque data within is up to that draft to define.  In 
Mobile IPv4, the generic notification message 
(draft-ietf-mip4-generic-notification-message-00.txt) does mention 
binding revocation.

> elephant in a refrigerator :)

draft-haley-mip6-mh-signaling-02.txt does have Acknowledge support, so 
repying isn't a problem.

> notification (fyi) messages proposed by draft-haley.

I won't disagree that binding revocation could be a very complex task 
when you involve many of the possible mobility scenarios.  But the 
protocol in draft-muhanna seems pretty simple.  Do you think that having 
multiple layers of mobility options just makes it too difficult?  I 
could see if you had a generic notification message, with a revocation 
option inside, with additional "session" options, that might be a little 
confusing, but I don't think it's a show-stopper.

Noone even mentioned the extra bytes over the air, I figured that would 
be the first complaint :)

-Brian

---

From: Brian Haley <[email-masked]>
Date: Thu, 31 May 2007 12:00:02 -0400

Hi Mohamed,

> 3- the revocation attributes, or sub-options.

How often do you think additional attributes/sub-options will be 
present?  In every message?  Will they be defined in a -02 version of 
the draft or is that something for another draft?

-Brian

---

From: Brian Haley <[email-masked]>
Date: Thu, 31 May 2007 12:52:27 -0400

> (draft-ietf-mip4-generic-notification-message-00.txt) does mention 

Correction.  It was pointed out to me that RFC 3543 is for Mip4 
registration revocation.  So maybe that set a precedence to do this 
separately?

-Brian

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 31 May 2007 12:27:33 -0500

> registration revocation.  So maybe that set a precedence to do this

Learning from experience of MIP4 is good.... But does not imply that we have
to solve the issues in exactly the same way.
The binding revocation capability in MIP6 is required. The solution for this
can be fairly simple. I don't know what numerous suboptions are being
refered to as the reasoning for having a separate message.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 31 May 2007 12:38:55 -0500

Hi Brian, 
please see comments inline.

Regards,
Ahmad

> From: Brian Haley [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2007 11:52 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> include, expiry 
> >> of prepaid billing, service outage related notifications, new 
> >> promotional information.
> > 
> Correction.  It was pointed out to me that RFC 3543 is for 
> Mip4 registration revocation.  So maybe that set a precedence 
> to do this separately?

[Ahmad]
I agree. 

IMO, revocation mechanism is more of a control mechanism than
informational. It is similar to the registration messages since it
impacts the state of the MN binding and the allocated resources. Having
said that, I believe we probably have a couple of options here:

Option 1:
Is to have the revocation messages stands out as a separate MH type
messages. This is similar to what Mobile IPv4 has in RFC3543 and
detailed in the Binding Revocation for IPv6 Mobility draft.

-OR-

Option 2:
Since the MH generic message type allows only for options to be defined
(in separate drafts) and including all the revocation related
information would not be possible in a single option (unless it becomes
a message), then a subtype (as the first byte after the MH) can be used
to define the type of message that is included in the generic
notification message. 

I still believe that option 1 is the best way to go forward in order to
address the revocation mechanism, having in mind that whatever
revocation mechanism we propose here needs to be applicable to PMIPv6
too.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 31 May 2007 13:02:29 -0500

Hi Raj,

Please see comments inline.

Regards,
Ahmad

> >> The generic notification message is a delivery mechanism, the 
> >> receiver action for the opaque data within is up to that draft to 
> >> define.  In Mobile IPv4, the generic notification message
> Learning from experience of MIP4 is good.... But does not 
> imply that we have to solve the issues in exactly the same way.
> The binding revocation capability in MIP6 is required. The 
> solution for this can be fairly simple. I don't know what 
> numerous suboptions are being refered to as the reasoning for 
> having a separate message.

[Ahmad]

In the case of MIPv6, we could have the following scenarios:
1. Revoking a single session based on the NAI and/or HoA.
2. Revoking all MN sessions based on NAI, alone for example.
3. Revoking more than one sessions by including more than one HoA or a
Home Network Prefix.
4. A very possible need for the Identification of what type of IPv6
mobility session we are revoking.
5. Probably a special handling is necessary in revoking a MN session
during the transition scenario, i.e. moving from MIPv6 to PMIPv6.

I also believe that more options are needed to address scenarios that
are related to PMIPv6 and inter-MAG handoff scenarios.

---

From: Brian Haley <[email-masked]>
Date: Thu, 31 May 2007 14:27:20 -0400

Hi Ahmad,

Comments inline.

> to define the type of message that is included in the generic

I don't follow you here.  Your Binding Revocation Indication Message is 
very similar to the Signaling Request Message in draft-haley, having a 
Revoke sub-option (with some flags) doesn't seem like it's that different.

The one thing that would be different is if you're sending multiple 
sub-options containing revocation information - they might be considered 
at different "levels" in each draft:

   Generic Notification Message
     Revocation option
     Session revocation option #1
     Session revocation option #2

   Revocation Indication Message
     Session revocation option #1
     Session revocation option #2

So in the top case, how do you associate the Session options with the 
Revocation option, they're all just options, right?  You'd just have to 
have very specific processing rules (like we do for Binding Cache 
Information Options in the ha-reliability draft).  I can understand this 
problem, since as you define more options it could get difficult - is 
this the main reason you want a new message?

I'm just trying to understand your reasoning here.

Thanks,

-Brian

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 31 May 2007 15:16:32 -0500

Ahmad, 

Inline:

> 1. Revoking a single session based on the NAI and/or HoA.

What do you mean by single session??? In the MIP6 case revoking the binding
implies that you are deprecating the entry from the BCE for the MS. There is
no session specific information.

> 2. Revoking all MN sessions based on NAI, alone for example.

Again, what do you mean by "all MN sessions"... Are you refering to the
scenario of deprecating the binding for all MNs served by an HA? And even if
that is case, why cant you accomplish the same via notifications sent to all
affected MNs (or sessions in your terminology)?

> 3. Revoking more than one sessions by including more than one HoA or a

Any why is this a problem? I mean the binding in MIP6 is between an MN and
HA. So if you were to revoke the binding for all MNs that use a certain
prefix (for example), you have to send notifications to all those MNs.

> mobility session we are revoking.

??? Not sure I understand what you mean by "type of IPv6 mobility session".

> during the transition scenario, i.e. moving from MIPv6 to PMIPv6.

Well.. This becomes a scoping of work issue. Netlmm is dealing with
interactions of MIP6 and PMIP6. I am not sure if the MIP6 base protocol
needs to start considering issues which IMO are not in scope here.
Moreover transition from MIP6 to PMIP6 is a topic still in discussion in
Netlmm and I don't think we can really solve the binding revocation issue
without having a solution for such transition in place first.

> are related to PMIPv6 and inter-MAG handoff scenarios.

Hmmm... I think if there is a need to do binding revocation between MAGs and
LMAs, that should be discussed in the Netlmm WG. In fact I don't think the
MIP6 work on binding revocation needs to be overloaded with PMIP6 semantics.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 31 May 2007 18:33:00 -0500

Hi Brian,

Please allow me to bring the discussion back to the basic functionality
of binding revocation. Probably, that would help in realizing the
difference between the two mechanism and what each one is trying to
achieve.

Although, we arguably can say that both protocols functionalities is
about notifying the MN with an event, however, there is a difference
between the two. In the case of Binding Revocation mechanism, the
decision has been made for administrative or other reasons to
immediately revoke, i.e. delete, the MN BCE. The HA possibly already
executed the revocation order, BUT need to notify the MN with the new
state of its BCE. This is clearly different than the nature of the
informational signaling protocol introduced by the generic notification
messages which may notify the MN with an event that eventually may cause
the MN BCE to be deleted if the MN does not react according to the
agreement with the home domain, e.g. pre-paid balance is going below
$3.00, or HA is scheduled for maintenance after 2 hours. In order for
the MN to avoid service termination, MN may refill its pre-paid account
and later sends a BU to renew its BCE lifetime.

In other words, Binding revocation involves an immediate movement/change
of the control plane and impacts the MN BCE state which is very similar
to Registration Signaling Control messages, i.e. BU/BA. One cause BCE to
be created and one cause it to be deleted.

The scope of the generic notification messages, as per the draft text,
is to send opaque data with an Informational nature by introducing a new
encapsulating header (generic notification message), if I may call it
that, inside the Mobility Header itself to be used for communicating
some generic information (fyi) to the MN. 

Finally, I would like to make sure that we agree that PMIPv6, although,
it is described under Netlmm wg, is very relevant to this wg and
considered as an extension to the MIPv6 protocol. Not only that, but the
same MN BCE may change from MIPv6 state to PMIPv6 and again to MIPv6
state where the change of the same BCE may require at one point a
revocation message according to PMIPv6 and another according to MIPv6.
If that the extent of the interaction between the MIPv6 and PMIPv6, we
should design a revocation signaling mechanism that can be used in both
cases to revoke different states of the same BCE. Let me explain a
scenario here:

1. Let us assume that a MN is visiting Access1 and its session
registered with its HA1 using MIPv6. BCE Flag=MIPv6.
2. MN moves to Access2, where PMIPv6 is deployed and MAG1 send a PBU to
modify the MN BCE @ HA1. BCE Flag=PMIPv6.
3. Let us assume the MN moves within Access2 from MAG1 to MAG2 which
triggers the LMA/HA1 to send a Revocation message to MAG1 in order for
MAG1 to clean resources associated with the MN; Here, BRI1 revokes a
PMIPv6 BCE.
4. Let us assume that the MN moved to Access 3, where PMIPv6 is not
deployed and MN used MIPv6 for global mobility with the same HA1. BCE
Flag= MIPv6.
5. If the home domain decides to revoke the MN BCE, the HA1 sends a
BRI2. Here, BRI2 revokes a MIPv6 BCE.

One last thing, Do you see a problem by using a separate MH types for
revocation messages to define one revocation mechanism/messages which is
applicable to MIPv6 and PMIPv6?

Thanks in advance.

Regards,
Ahmad

> Sent: Thursday, May 31, 2007 1:27 PM
> >> Mip4 registration revocation.  So maybe that set a 
> precedence to do 
> >> this separately?
> > 
> > [Ahmad]
> > I agree. 
> > 
> > impacts the state of the MN binding and the allocated resources. 
> > Having said that, I believe we probably have a couple of 
> options here:
> > 
> > Option 1:
> > Since the MH generic message type allows only for options to be 
> > defined (in separate drafts) and including all the 
> revocation related 
> > information would not be possible in a single option (unless it 
> > becomes a message), then a subtype (as the first byte after the MH) 
> > can be used to define the type of message that is included in the 
> > generic notification message.
> 
> I don't follow you here.  Your Binding Revocation Indication 
> Message is very similar to the Signaling Request Message in 
> draft-haley, having a Revoke sub-option (with some flags) 
> doesn't seem like it's that different.
> 
> The one thing that would be different is if you're sending 
> multiple sub-options containing revocation information - they 
> might be considered at different "levels" in each draft:
> 
> So in the top case, how do you associate the Session options 
> with the Revocation option, they're all just options, right?  
> You'd just have to have very specific processing rules (like 
> we do for Binding Cache Information Options in the 
> ha-reliability draft).  I can understand this problem, since 
> as you define more options it could get difficult - is this 
> the main reason you want a new message?
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 31 May 2007 18:35:07 -0500

Hi Brian,

Correction... Meant to say:
"Probably, that would help *US* in realizing the difference....."

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Thursday, May 31, 2007 6:33 PM
> To: 'Brian Haley'
> Cc: [email-masked]'
> Subject: RE: [Mip6] FW: I-D 
> Please allow me to bring the discussion back to the basic 
> functionality of binding revocation. Probably, that would 
> help in realizing the difference between the two mechanism 
> and what each one is trying to achieve.
> 
> Although, we arguably can say that both protocols 
> functionalities is about notifying the MN with an event, 
> however, there is a difference between the two. In the case 
> of Binding Revocation mechanism, the decision has been made 
> for administrative or other reasons to immediately revoke, 
> i.e. delete, the MN BCE. The HA possibly already executed the 
> revocation order, BUT need to notify the MN with the new 
> state of its BCE. This is clearly different than the nature 
> of the informational signaling protocol introduced by the 
> generic notification messages which may notify the MN with an 
> event that eventually may cause the MN BCE to be deleted if 
> the MN does not react according to the agreement with the 
> home domain, e.g. pre-paid balance is going below $3.00, or 
> HA is scheduled for maintenance after 2 hours. In order for 
> the MN to avoid service termination, MN may refill its 
> pre-paid account and later sends a BU to renew its BCE lifetime.
> 
> In other words, Binding revocation involves an immediate 
> movement/change of the control plane and impacts the MN BCE 
> state which is very similar to Registration Signaling Control 
> messages, i.e. BU/BA. One cause BCE to be created and one 
> cause it to be deleted.
> 
> The scope of the generic notification messages, as per the 
> draft text, is to send opaque data with an Informational 
> nature by introducing a new encapsulating header (generic 
> notification message), if I may call it that, inside the 
> Mobility Header itself to be used for communicating some 
> generic information (fyi) to the MN. 
> 
> Finally, I would like to make sure that we agree that PMIPv6, 
> although, it is described under Netlmm wg, is very relevant 
> to this wg and considered as an extension to the MIPv6 
> protocol. Not only that, but the same MN BCE may change from 
> MIPv6 state to PMIPv6 and again to MIPv6 state where the 
> change of the same BCE may require at one point a revocation 
> message according to PMIPv6 and another according to MIPv6. 
> If that the extent of the interaction between the MIPv6 and 
> PMIPv6, we should design a revocation signaling mechanism 
> that can be used in both cases to revoke different states of 
> the same BCE. Let me explain a scenario here:
> 
> 1. Let us assume that a MN is visiting Access1 and its 
> session registered with its HA1 using MIPv6. BCE Flag=MIPv6.
> 2. MN moves to Access2, where PMIPv6 is deployed and MAG1 
> send a PBU to modify the MN BCE @ HA1. BCE Flag=PMIPv6.
> 3. Let us assume the MN moves within Access2 from MAG1 to 
> MAG2 which triggers the LMA/HA1 to send a Revocation message 
> to MAG1 in order for MAG1 to clean resources associated with 
> the MN; Here, BRI1 revokes a PMIPv6 BCE.
> 4. Let us assume that the MN moved to Access 3, where PMIPv6 
> is not deployed and MN used MIPv6 for global mobility with 
> the same HA1. BCE Flag= MIPv6.
> 5. If the home domain decides to revoke the MN BCE, the HA1 
> sends a BRI2. Here, BRI2 revokes a MIPv6 BCE.
> 
> One last thing, Do you see a problem by using a separate MH 
> types for revocation messages to define one revocation 
> mechanism/messages which is applicable to MIPv6 and PMIPv6?
> 
> Thanks in advance.
> 
> Regards,
> Ahmad
> 
> > I don't follow you here.  Your Binding Revocation 
> Indication Message 
> > is very similar to the Signaling Request Message in draft-haley, 
> > having a Revoke sub-option (with some flags) doesn't seem like it's 
> > that different.
> > 
> > sub-options containing revocation information - they might be 
> > considered at different "levels" in each draft:
> > 
> > Revocation option, they're all just options, right?
> > You'd just have to have very specific processing rules 
> (like we do for 
> > Binding Cache Information Options in the ha-reliability 
> draft).  I can 
> > understand this problem, since as you define more options 
> it could get 
> > difficult - is this the main reason you want a new message?
> >

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Jun 2007 12:39:58 +1000

Hi Ahmad,

 > functionality
 > pre-paid account

=> I don't think it's impossible to reconcile those different cases in the
same message. 
The notification message can indicate all sorts of information to the MN
like "binding deleted", "about ot be deleted" ...etc.

 > movement/change
 > draft text,

=> So are you suggesting that the information in draft-haley should not be
opaque? Opaque is a strange word anyway when the information is sent to the
ultimate receiver of the message. If that's the suggestion then I think it's
doable. 

 > send a PBU to

=> That's fine but you didn't explain why this is not doable in draft-haley?
You can simply define a message to be carried in his notification header,
what's wrong with that? 

Hesham