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

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

Hi Hesham,
Please see comments inline.

Regards,
Ahmad

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2007 9:40 PM
> To: Muhanna, Ahmad (RICH1:2H10); 'Brian Haley'
> Cc: [email-masked]
> Subject: RE: [Mip6] FW: I-D 
> ACTION:draft-muhanna-mip6-binding-revocation-00.txt
> 
> Hi Ahmad,
> 
>  >
>  > 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. 
> 
> => 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. 
> 
>  >
>  > 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.
> 
> => 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? 

[Ahmad]

Let me clarify one thing here. draft-hanley defines a messaging
container mechanism via generic notification messages. According to that
draft and its scope, the details of a functionality like revocation,
which possibly can be carried inside the generic notification messages,
is to be defined in a different draft anyway. In other words, even if we
agree to define a subtype for revocation messages in the generic
notification messages, (as you just suggested) the details of the
revocation mechanism needs to be captured in a different draft anyway. I
just would like to point that out and put it behind us.
 
On the other hand, I actually expressed before, that anything is
possible and we can make anything to work. The question is, what is the
best most flexible and efficient way for achieving the same outcome. **
It reminds me with the GRE issue related to DSMIP6, when you felt that
defining a new TLV introduces an unnecessary overhead while others
argued that there is a valid need for such TLV which justify the
overhead **. (sorry for bringing that here, I am just trying to make a
comparison not to argue about it). It seems that I am always on the
other side:-)

Anyway, you probably missed my other email, in which I pointed out that
we definitely have two available options here.

Snip
++++++++++++++++++++
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.
+++++++++++++++++++++
snip

I, personally, believe that defining separate MH types for revocation
messages (option 1) is more flexible and efficient than defining the
same messages within the generic notification messages. It is more
relevant since it is a control message similar to BU/BA. Otherwise, we
could argue that all IPv6 mobility control messages can anyway be masked
and embedded in the generic notification messages. In other words, we
are creating another messaging container within the Mobility Header
itself. May be in the near future some people will argue that another
level/container within the generic notification message is necessary
too!:) 

I just do not see why using another messaging container to mask the
revocation messages within the Mobility header is necessary!
 
> 
> Hesham
> 
>  >
>  > 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
>  >
>  > > -----Original Message-----
>  > > From: Brian Haley [mailto:[email-masked]]  > > Sent: 
> Thursday, May 31, 2007 1:27 PM  > > To: Muhanna, Ahmad 
> (RICH1:2H10)  > > Cc: [email-masked]  > > Subject: Re: [Mip6] 
> FW: I-D  > > ACTION:draft-muhanna-mip6-binding-revocation-00.txt
>  > >
>  > > Hi Ahmad,
>  > >
>  > > Comments inline.
>  > >
>  > > Ahmad Muhanna wrote:
>  > > >> 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 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
>  > >
>  >
>  > _______________________________________________
>  > Mip6 mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/mip6
>  > 
> 
> 
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 1 Jun 2007 15:41:27 +1000

> just would like to point that out and put it behind us.

=> Yes that's true of course.

 > best most flexible and efficient way for achieving the same 
 > outcome. 

=> Ok, so what is that most flexible way? 

 > relevant since it is a control message similar to BU/BA. 

=> Ok, it's clear that this is your belief. What's not clear is why you
think it's efficient and flexible. This is a one message that is not sent
frequently to the MN, so what efficiency metrics do you use to come to this
conclusion? I think it's a waste (albeit not so significant of course) to
define a new MH type just for this message. 

I really don't care which way this goes because both will work with little
differences. I'm trying to understand why we're talking so much about this
and what the differences are, if any. I don't really see much difference. 

 > > > mechanism/messages which is  > applicable to MIPv6 and PMIPv6?

=> Other than wasting a new MH type, I see zero practical differences. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 1 Jun 2007 01:58:44 -0500

Hi Hesham,

Regards,
Ahmad

>  >
>  > [Ahmad]
>  >
>  > Let me clarify one thing here. draft-hanley defines a 
> messaging  > container mechanism via generic notification messages. 
>  > According to that
>  > draft and its scope, the details of a functionality like 
> revocation,  > which possibly can be carried inside the 
> generic  > notification messages,  > is to be defined in a 
> different draft anyway. In other  > words, even if we  > 
> agree to define a subtype for revocation messages in the 
> generic  > notification messages, (as you just suggested) the 
> details of the  > revocation mechanism needs to be captured 
> in a different  > draft anyway. I  > just would like to point 
> that out and put it behind us.
> 

[Ahmad]
That is good.
> 
>  >
>  > On the other hand, I actually expressed before, that 
> anything is  > possible and we can make anything to work. The 
> question is,  > what is the  > best most flexible and 
> efficient way for achieving the same  > outcome. 
> 

[Ahmad]
Please see my comments below. Just to address the whole thing in one
place. 
> 
> 
>  >
>  > Snip
>  > ++++++++++++++++++++
>  > 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  > 
>  > I, personally, believe that defining separate MH types for 
> revocation  > messages (option 1) is more flexible and 
> efficient than defining the  > same messages within the 
> generic notification messages. It is more  > relevant since 
> it is a control message similar to BU/BA. 
> 
> => Ok, it's clear that this is your belief. What's not clear 
> is why you think it's efficient and flexible. This is a one 
> message that is not sent frequently to the MN, so what 
> efficiency metrics do you use to come to this conclusion? I 
> think it's a waste (albeit not so significant of course) to 

[Ahmad]
Again, Please see the comments below.
> 
> I really don't care which way this goes because both will 
> work with little differences. I'm trying to understand why 
> we're talking so much about this and what the differences 
> are, if any. I don't really see much difference. 
> 
>  > >  >
>  > >  > 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?
> 

[Ahmad]
Since most of your questions are, basically, related to efficiency, I
would like to address everything in one place.
If the whole concept behind the generic notification message is to AVOID
and SAVE a new MH type and basically mask all future IPv6 mobility
control related messages, then I believe that the proposed mechanism as
per draft-haley is inefficient and all what we need is the following:

1. In order to enable the generic notification mechanism, we need to
define/reserve a specific MH Type (TBD=Generic Mobility Header) which
identifies the presence of a two bytes (Generic Mobility Header, GMH) at
the end of the Mobility header which, if included ALONE makes the
mobility header length equal to ZERO.

2. These two bytes (GMH) are used to define a 64k subtypes for the
Generic Mobility Header.
3. Each subtype define a single message, for example, 01: Binding
Revocation Indication, 02: Binding Revocation Acknowledgement, 03: etc.
4. Separate drafts, like Binding Revocation for IPv6 Mobility, for
example, defines the messages format and describe in details the
revocation mechanism.

Now, why I think this or a separate messages is more efficient than what
is already defined and proposed in draft-haley?

1. Since the whole objective here is to save MH type, we eliminate the
need for defining two messages, generic notification message and generic
notification acknowledgement.

2. We eliminated the use of the generic notification sequence number
which may be limited in here. As a matter of fact, why do we need that
if the new functionality is going to define all the needed formats and
details.

3. We define the details of the revocation mechanism, for example,
independently without any possible conflict with the generic message A
bit, for example. In other words, the A bit is defined where it is
mattered most, i.e. in the Binding Revocation Indication message, rather
than in the masking container structure. Moreover, all needed bits will
be defined and processed in one place rather defining the
Acknowledgement bit in the container header, while figuring out the
Global bit inside the Binding Revocation Indication message, just as an
example.

4. Provide the flexibility to define any other messaging protocol
without being restricted with the rules of the generic notification
messages mechanism and whatever limitations it may have.

5. If this messaging mechanism is really generic in the full sense, how
anyone expect that one byte of status is enough to address all possible
status for all the possible functionalities that could ever be
masked/encapsulated using this generic messaging mechanism. In other
words, I believe that the status should be moved from the Generic
notification message header to the specific message, where it is more
relevant. For example, what the following status has to do with
revocation mechanism, for example: "130 Insufficient resources". I
thought we are trying to FREE resources here!

6. Why do we have to define retransmission for this generic notification
messaging mechanism. Is not this supposed to be generic enough to fit
the need of any functionality that we may think of. Is not there is a
possibility that we define a functionality that depends on best effort
that does not require retransmission.

7. Finally, how do we expect to have this mechanism generically sound
and at the same time we define limitation that may or may not work for
all generic functionalities that could be masked/encapsulated inside
such container, for example, why do you think that the following
timeouts is applicable to all functionalities. I believe that these
numbers need to be defined specifically by each functionality.

    	INITIAL_MH_SIGNAL_TIMEOUT             5 seconds
   	MAX_MH_SIGNAL_TIMEOUT                 20 seconds

8. I hope that you would agree that using the generic notification
messages mechanism as per the current proposed mechanism in draft-haley
is not the most efficient mechanism to protect and save MH types and at
the same time offer a generic enough mechanism to contain almost any
possible generically sound functionality.

9. Finally, if we are concerned to preserve what left of the MH types, I
believe the above proposed Generic Mobility Header is the best way to go
forward. "2 bytes of 64k subtypes" that simple.

> > > (RICH1:2H10)  > > Cc: [email-masked]  > > Subject: Re: 
> [Mip6]  > > FW: I-D  > > 
>  > >  > > >> 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  > 
> > > 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:
>  > > 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.
>  > >  > >
> > > Request Message in  > > draft-haley, having a Revoke  > > 
>  > >  > > 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: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 1 Jun 2007 17:22:05 +0900

Hi Ahmad and Hesham,

Sorry Hesham, let me jump in this thread.

> notification acknowledgement.

Isn't this such big issue?!

Anyway, if you have a new MH, you should consider the IPsec setting up.
The MH type is now a selector in IPsec,
you need additional SAD/SPD for the new revocation message?!

> if the new functionality is going to define all the needed formats and

You can always overwrite the draft-haley in your document.

> thought we are trying to FREE resources here!

Can you define your status field  in your options??

> that does not require retransmission.

Retransmission is required, because MH does not provide reliable  
transmission.
If you don't want retransmission, you just override that spec. in  
your document...
The haley's draft defines a generic MH message, you can always  
overwrite it as you want.
Otherwise, nobody can use draft-haley...

>    	MAX_MH_SIGNAL_TIMEOUT                 20 seconds

please overwrite it...
RFC3775 also overrides the constant value of RFC2461.

> forward. "2 bytes of 64k subtypes" that simple.

Finally, I feel the same with Hesham.
I am fine either case, but what you are saying here is not such  
correct..

If you have any problems to use the draft-haley as a base,
you can also raise the issue to the draft-haley.
It is still under consensus call. Your comments aren't specific to  
the binding revocation,
but more general problem whether the Mobility Header Signaling  
Message is useful or not..

regards,
ryuji

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 01 Jun 2007 12:23:17 -0500

Ahmad et al,

Let me try and summarize this discussion:

Basically you are arguing that binding revocation is a control message which
does not really fit in with the generic mh-signaling message being defined
by draft-haley. And the reasoning (IMO) that you seem to have is that the
generic-mh-header signaling scheme is intended for informational updates
only. You have also stated that the generic mh-signaling scheme limits
flexibility. As to what flexibility is required for binding revocation, it
has not been clearly spelled out. I think other claims about processing
efficiency etc. to me seem like hand-waving.

Binding revocation in general would not be frequently used in a deployment.
So trying to optimize it is not a strong requirement.

As Hesham and Ryuji have said, there is no reason why you cannot accomplish
binding revocation using the generic-mh-signaling message defined in
draft-haley.
You can solve the binding revocation problem either by defining new messages
as you are currently doing and stating that this is the only method that
makes the most sense or by notifying the MS about the binding being revoked
via a standardized option (IANA assigned) in the generic MN-header signaling
message. Both of them will work. I don't think there is any disagreement
about the solution.

Reuse of a signaling message would be a good approach.

If you were to specify binding revocation using the generic-mh-signaling
message and the behavior of the host and the HA in a separate draft, I think
it would solve the problem just as well. I hope you will consider this
option as well.

-Raj

---

From: Brian Haley <[email-masked]>
Date: Fri, 01 Jun 2007 14:12:40 -0400

RYUJI WAKIKAWA wrote:
> I am fine either case, but what you are saying here is not such correct..
> 
> It is still under consensus call. Your comments aren't specific to the 
> binding revocation,
> but more general problem whether the Mobility Header Signaling Message 
> is useful or not..

Yes, if there are things in draft-haley that need to be 
resolved/fixed/etc so it can be better used for signaling, please send 
them to the list or to me, I'll be happy to update it.  Irregardless of 
the outcome of this discussion...

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 1 Jun 2007 13:17:48 -0500

Thanks Brian,

I will provide the suggested change when the discussion is concluded.
One point, as per the discussion on this thread, I tried to avoid giving
opinion about the generic container mechanism introduce in the
draft-haley. However, when I was asked to justify the deficiency claim,
I had to highlight what I think is causing some deficiency and
limitation.

Regards,
Ahmad

> From: Brian Haley [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 1:13 PM
> To: RYUJI WAKIKAWA
> Cc: Muhanna, Ahmad (RICH1:2H10); Hesham Soliman; [email-masked]
> Subject: Re: [Mip6] FW: I-D 
> >> 9. Finally, if we are concerned to preserve what left of the MH 
> >> types, I believe the above proposed Generic Mobility Header is the 
> >> best way to go forward. "2 bytes of 64k subtypes" that simple.
> > 
> > If you have any problems to use the draft-haley as a base, you can 
> > also raise the issue to the draft-haley.
> > binding revocation, but more general problem whether the Mobility 
> > Header Signaling Message is useful or not..
> 
> resolved/fixed/etc so it can be better used for signaling, 
> please send them to the list or to me, I'll be happy to 
> update it.  Irregardless of the outcome of this discussion...
> 
> -Brian
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 1 Jun 2007 13:38:34 -0500

Hi Raj,

As I said before, I am not against using a generic container mechanism
in order to mask/carry the Binding revocation messages. However, In my
answer to Hesham below, I identified several deficiency issues with the
current proposed generic container mechanism. Let me make on point clear
before moving forward, according to the discussion you referred to with
Hesham and Ryuji, the main concern was that the MH types are running out
quickly and a generic container mechanism is very useful to have some
protection.

Having said that, I would like to summarize some of the discussion with
Hesham and Ryuji below. Also, I would propose an optimization to the
generic container mechanism which I already shared with Ryuji in a
separate thread as a reply to the wg consensus call.

Here is a summary:
Concern No. 1:
==============

>> Since the whole objective here is to save MH type, we eliminate the 
>> need for defining two messages, generic notification message and 
>> generic notification acknowledgement.

> Isn't this such big issue?!

[Ahmad]
Agreement on preserving the remaining MH types. As per the generic
notification mechanism in draft-haley, the proposed modified container
mechanism will preserve this as well.

Concern No. 2:
==============
> The MH type is now a selector in IPsec, you need additional SAD/SPD 
> for the new revocation message?!

[Ahmad]
If we use the generic container mechanism with the proposed
modification, then we are all happy and on the same page.

Concern No. 3:
==============

> You can always overwrite the draft-haley in your document.

[Ahmad]
Well, my understanding is that we will end up with two sequence number
fields, one in the generic notification message and another in the
revocation message. Is not that right? If so, why do we need to have
two?

Concern No. 4:
==============
>> If this messaging mechanism is really generic in the full sense, 
>> how anyone expect that one byte of status is enough to address all 
>> possible status for all the possible functionalities that could ever 
>> be masked/encapsulated using this generic messaging mechanism. In 
>> other words, I believe that the status should be moved from the 
>> Generic notification message header to the specific message, where it

>> is more relevant. For example, what the following status has to do 
>> with revocation mechanism, for example: "130 Insufficient resources".

>> I thought we are trying to FREE resources here!
>
> 

[Ahmad]
Again, same as concern No.3. 
Why do we need to end up handling two different status field for
addressing the same status?.

Concern No. 5:
==============
>> We define the details of the revocation mechanism, for example, 
>> mattered most, i.e. in the Binding Revocation Indication message, 
>> rather than in the masking container structure. Moreover, all needed 
>> bits will be defined and processed in one place rather defining the 
>> Global bit inside the Binding Revocation Indication message, just as 
>> an example.

Concern No. 6:
==============
>> Why do we have to define retransmission for this generic 
>> notification messaging mechanism. Is not this supposed to be generic 
>> enough to fit the need of any functionality that we may think of. Is 
>> not there is a possibility that we define a functionality that
depends 
>> on best effort that does not require retransmission.

> If you don't want retransmission, you just override that spec. in your

> document...

[Ahmad]
Agree. I assumed here that the functionality embedded requires best
effort.
However, if we allow each functionality the option to overwrite the
generic mechanism numbers, why do we need these numbers to start with.
If that concept is generic enough, then I assume we have two options:

1. These numbers are very generic that are applicable to all
functionalities, OR, 
2. Do not define them to start with.

IMO, all what we need is a container rather than another level of
embedded messaging. Right?

Concern No. 7:
==============
>> Finally, how do we expect to have this mechanism generically sound 

[Ahmad]
Same as concern No. 6.

Regards,
Ahmad

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 12:23 PM
> To: Muhanna, Ahmad (RICH1:2H10); Hesham Soliman; Brian Haley
> Cc: [email-masked]
> Basically you are arguing that binding revocation is a 
> control message which does not really fit in with the generic 
> mh-signaling message being defined by draft-haley. And the 
> reasoning (IMO) that you seem to have is that the 
> generic-mh-header signaling scheme is intended for 
> informational updates only. You have also stated that the 
> generic mh-signaling scheme limits flexibility. As to what 
> flexibility is required for binding revocation, it has not 
> been clearly spelled out. I think other claims about 
> processing efficiency etc. to me seem like hand-waving.
> 
> As Hesham and Ryuji have said, there is no reason why you 
> cannot accomplish binding revocation using the 
> generic-mh-signaling message defined in draft-haley.
> You can solve the binding revocation problem either by 
> defining new messages as you are currently doing and stating 
> that this is the only method that makes the most sense or by 
> notifying the MS about the binding being revoked via a 
> standardized option (IANA assigned) in the generic MN-header 
> signaling message. Both of them will work. I don't think 
> there is any disagreement about the solution.
> 
> If you were to specify binding revocation using the 
> generic-mh-signaling message and the behavior of the host and 
> the HA in a separate draft, I think it would solve the 
> problem just as well. I hope you will consider this option as well.
> 
> -Raj 
> 
> 
> >> revocation,  > which possibly can be carried inside the generic  > 
> >> notification messages,  > is to be defined in a different draft 
> >> anyway. In other  > words, even if we  > agree to define a subtype 
> >> for revocation messages in the generic  > notification 
> messages, (as 
> >> you just suggested) the details of the  > revocation 
> mechanism needs 
> >> to be captured in a different  > draft anyway. I  > just 
> would like 
> >> to point that out and put it behind us.
> >> 
> >> IPv4 has in RFC3543 and  > detailed in the Binding Revocation for 
> >> IPv6 Mobility draft.
> >>> 
> >>> -OR-
> >>> 
> >>> Option 2:
> >> 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.
> >>> +++++++++++++++++++++
> >>> snip
> >>> 
> efficient than 
> >> defining the  > same messages within the generic notification 
> >> messages. It is more  > relevant since it is a control message 
> >> similar to BU/BA.
> >> 
> >> => Ok, it's clear that this is your belief. What's not 
> clear is why 
> >> you think it's efficient and flexible. This is a one 
> message that is 
> >> not sent frequently to the MN, so what efficiency metrics 
> do you use 
> >> to come to this conclusion? I think it's a waste (albeit not so 
> >> significant of course) to define a new MH type just for 
> this message.
> > 
> > [Ahmad]
> work with 
> >> little differences. I'm trying to understand why we're talking so 
> >> much about this and what the differences are, if any. I 
> don't really 
> >> see much difference.
> >> 
> >>>>> 
> >> separate  > > MH types for  > revocation messages to define one 
> >> revocation  > > > mechanism/messages which is  > 
> applicable to MIPv6 
> >> and PMIPv6?
> >> 
> > If the whole concept behind the generic notification message is to 
> > AVOID and SAVE a new MH type and basically mask all future IPv6 
> > mobility control related messages, then I believe that the proposed 
> > mechanism as per draft-haley is inefficient and all what we 
> need is the following:
> > 
> > identifies the presence of a two bytes (Generic Mobility 
> Header, GMH) 
> > at the end of the Mobility header which, if included ALONE 
> makes the 
> > Now, why I think this or a separate messages is more efficient than 
> > what is already defined and proposed in draft-haley?
> > 
> > need for defining two messages, generic notification message and 
> > generic notification acknowledgement.
> > 
> > mattered most, i.e. in the Binding Revocation Indication message, 
> > rather than in the masking container structure. Moreover, 
> all needed 
> > bits will be defined and processed in one place rather defining the 
> > Global bit inside the Binding Revocation Indication 
> message, just as 
> > an example.
> > 
> > 5. If this messaging mechanism is really generic in the full sense, 
> > how anyone expect that one byte of status is enough to address all 
> > possible status for all the possible functionalities that 
> could ever 
> > be masked/encapsulated using this generic messaging mechanism. In 
> > other words, I believe that the status should be moved from the 
> > Generic notification message header to the specific 
> message, where it 
> > is more relevant. For example, what the following status has to do 
> > with revocation mechanism, for example: "130 Insufficient 
> resources". 
> > I thought we are trying to FREE resources here!
> > 
> > 6. Why do we have to define retransmission for this generic 
> > notification messaging mechanism. Is not this supposed to 
> be generic 
> > enough to fit the need of any functionality that we may 
> think of. Is 
> > not there is a possibility that we define a functionality 
> that depends 
> > on best effort that does not require retransmission.
> > 
> > messages mechanism as per the current proposed mechanism in 
> > draft-haley is not the most efficient mechanism to protect 
> and save MH 
> > types and at the same time offer a generic enough mechanism 
> to contain 
> > almost any possible generically sound functionality.
> > 
> > 9. Finally, if we are concerned to preserve what left of 
> the MH types, 
> > I believe the above proposed Generic Mobility Header is the 
> best way 
> > to go forward. "2 bytes of 64k subtypes" that simple.
> > 
> > 
> >> 
> >> Hesham
> >> 
> >>>>> 
> >>>>> Thanks in advance.
> >>>>> 
> >>>>> Regards,
> >>>>> Ahmad
> >>>>> 
> maybe that  
> >> a  >  > > separate MH type  > > > messages. This is 
> similar to what  
> >> > > Mobile IPv4 has in RFC3543 and  > > > detailed in the 
> Binding  > 
> (unless it  
> >> > > after the MH)  > > > can be used to define the type of  > > 
> >> message that is  > included in the  >
> >>>> Indication  > > Message is very similar to the Signaling Request 
> >>>> Message in  > > draft-haley, having a Revoke  > >
> information 
> >>>> - they  > > might be considered at different "levels" in each 
> >>>> draft:
> >>>>>> 
> >> Session  > > options  > > with the Revocation option, they're all 
> >> just  > > options, right?
> Options in 
> >> the  > >  > > ha-reliability draft).  I can understand 
> this problem,  
> >> > > since  > > as you define more options it could get 
> difficult  > >

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 2 Jun 2007 13:48:09 +1000

Hi Ahmad,  

 > Concern No. 1:

=> Ok so we agree on this. 

 > Concern No. 2:
 > ==============
 > > 
 > > Anyway, if you have a new MH, you should consider the 
 > IPsec setting 
 > > up.

=> ok good. I agree with Ryuji's comment on the security aspect.

 > > > if the new functionality is going to define all the 
 > needed formats
 > and
 > > > details.
 > > 

=> Why can't you use the one in draft-haley? This is a revocation message,
it's removing the binding completely, why does it need its own seq number? 

 > Concern No. 4:

=> I completely disagree with your premise above. I think 255 is plenty. If
a specific
message needs more than 255 then it can add its own status. I don't know why
you'd need that in this case.

 > >> with revocation mechanism, for example: "130 Insufficient 

=> You don't *have* to use every generic error code, you can use/define the
ones that are relevant to you. 

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 2 Jun 2007 09:19:51 -0500

Hi Hesham,

Regards,
Ahmad

>  >
>  > Concern No. 3:
>  > ==============
>  >
>  > > > 2. We eliminated the use of the generic notification  
> > sequence number  > > > which may be limited in here. As a 
> matter of fact, why do we need  > that  > > > if the new 
> functionality is going to define all the  > needed formats  > 
> and  > > > details.
>  > >
>  > Well, my understanding is that we will end up with two  > 
> sequence number  > fields, one in the generic notification 
> message and another in the  > revocation message. Is not that 
> right? If so, why do we need to have  > two?
> 
> => Why can't you use the one in draft-haley? This is a 
> revocation message, it's removing the binding completely, why 
> does it need its own seq number? 

[Ahmad]
seq. # is used to match the binding revocation ack to the outstanding
revocation Indication. The Binding Revocation for IPv6 Mobility draft
allows a mobility entity to request a BRA in many cases. Right?

> 
>  >
>  > Concern No. 4:
>  > ==============
>  > >> If this messaging mechanism is really generic in the 
> full sense,  > >> how anyone expect that one byte of status 
> is enough to  > address all  > >> possible status for all the 
> possible functionalities that  > could ever  > >> be 
> masked/encapsulated using this generic messaging mechanism. 
> In  > >> other words, I believe that the status should be 
> moved from the 
> 
> => I completely disagree with your premise above. I think 255 
> is plenty. If a specific message needs more than 255 then it 

[Ahmad]
which specific message we are talking about here. Probably I am missing
something.

> can add its own status. I don't know why you'd need that in this case.
> 
>  > >> Generic notification message header to the specific  > 
> message, where it  >  > >> is more relevant. For example, 
> what the following status  > has to do  > >> with revocation 
> mechanism, for example: "130 Insufficient  > resources".
> 
> => You don't *have* to use every generic error code, you can 
> use/define the ones that are relevant to you.
> 
> Hesham
> 
> 
>

---

From: "Hesham Soliman" <[email-masked]>
Date: Sun, 3 Jun 2007 00:25:16 +1000

> allows a mobility entity to request a BRA in many cases. Right?

=> That's fine but you can use a generic seq no for that. The one in
draft-haley.
you don't need to define another one in your option. All you need is a
number tracked by both sides, it doesn't have to be specific to your option
inside the header.

 > which specific message we are talking about here. Probably I 

=> I was responding to the claim that 1 byte of status is not enough.
Anyway, even if we do agree that 1 byte is not enough, that's something you
can add as a comment on draft-haley.

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 2 Jun 2007 09:33:42 -0500

Hi Hesham,
Please see comment inline.

Regards,
Ahmad

> > > revocation message, it's removing the binding completely, 
> why  > > does it need its own seq number? 
>  >
>  > [Ahmad]
>  > seq. # is used to match the binding revocation ack to the 
> outstanding  > revocation Indication. The Binding Revocation 
> for IPv6 Mobility draft  > allows a mobility entity to 
> request a BRA in many cases. Right?
> 
> => That's fine but you can use a generic seq no for that. The 
> one in draft-haley.
> you don't need to define another one in your option. All you 
> need is a number tracked by both sides, it doesn't have to be 
> specific to your option inside the header.
> 
>  >
>  > >
>  > >  >
>  > >  > Concern No. 4:
>  > >  > ==============
>  > >  > >> If this messaging mechanism is really generic in 
> the  > > full sense,  > >> how anyone expect that one byte of 
> status  > > is enough to  > address all  > >> possible status 
> for all the  > > possible functionalities that  > could ever  
> > >> be  > > masked/encapsulated using this generic messaging 
> mechanism. 
>  > > In  > >> other words, I believe that the status should 
> be  > > moved from the  > >  > > => I completely disagree 
> with your premise above. I think 255  > > is plenty. If a 
> specific message needs more than 255 then it  >  > [Ahmad]  > 
> which specific message we are talking about here. Probably I  
> > am missing  > something.
> 
> Anyway, even if we do agree that 1 byte is not enough, that's 
> something you can add as a comment on draft-haley.

[Ahmad]
That is good. I already proposed a slight modification to the generic
container mechanism introduced by draft-haley on a different thread,
could you please take a look when you have a chance.

Many thanks.