Subject: RE: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh-signaling-02.txt a WG doc

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 2 Jun 2007 02:27:46 -0500

Hello,
 
My understanding that the scope of draft-haley is as follows:

o  A generic container which can be used to communicate multiple 
   functionalities while preserving the MH types.
o  Introduce a Generic Notification Messages and Generic Notification
mechanism 
   that can be used to communicate several common notification event(s)
between 
   the HA and the MN.

Having said that, I would like to propose a small change to the current 
Draft-haley revision 02 which would hopefully enrich and enhance the
draft.

The following summarize the proposed changes:
=============================================
   1.  Define the first two bytes, of the current generic notification
       message, and call them , for example, Generic Mobility Container,
GMC, or XYZ.

   2.  The Generic Mobility Container is 2 bytes length and can have up
to 64k
       different values which we can call, for example, GMC Type. i.e.

       Generic Notification Request message, Generic Notification Ack,
       Binding Revocation Indication message, Binding Revocation Ack,
etc.

   3.  Every common functionality defines its own messages and mechanism
       including its own mechanism as fits the need of the specified
functionality.

   4.  Any functionality, e.g. Generic Notification, may define the use 
       of any MH option inside its own messages or define new ones.

Here is the format, let us use the Generic Notification and Binding 
Revocation as examples:
   
1. Generic Mobility Container Message 
===================================== 
This Signaling Generic Mobility Container Message uses the MH Type value
(TBD).

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           GMC Type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                      Message Data                             .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2. Generic Notification
=======================

Let us assume that this application requires two messages, a Request and

an acknowledgement.

3.1. Generic Notification Request
==================================
This Generic Notification Request uses a GMC Type of (TBD).

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           GMC Type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                 Generic Notification Request                  .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.2. Generic Notification Ack
==============================
This Generic Notification Ack uses a GMC Type of (TBD).

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           GMC Type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                 Generic Notification Ack                      .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
3.  Binding Revocation
======================

The following are the revocation messages that are defined by
the Binding Revocation Functionality as specified by the Binding
Revocation for IPv6 Mobility draft.
   
2.1. Binding Revocation Indication
==================================

This Binding Revocation Indication uses a GMC Type of (TBD).

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           GMC Type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .              Binding Revocation Indication                    .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
2.2.  Binding Revocation Acknowledgement
========================================
This Binding Revocation Acknowledgement uses a GMC Type (TBD).

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |           GMC Type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .              Binding Revocation Acknowledgement               .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Finally and as a suggestion, I would like to suggest that draft-haley
address two things:
1. Introducing the Generic Mobility Container, GMC.
2. Define the Generic Notification Messages and the related Mechanism.

While the Binding Revocation for IPv6 Mobility draft can define the
Binding 
Revocation messages and the binding revocation mechanism.

Best Regards,
Ahmad

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Wednesday, May 30, 2007 12:23 PM
> To: Mobile IPv6 Mailing List
> Cc: [email-masked]; ext Sri Gundavelli
> Subject: [Mip6] Consensus call: Make I-D 
> draft-haley-mip6-mh-signaling-02.txt a WG doc
> 
> 
> Hello,
> 
> At the Prague IETF (IETF68), the MIP6 WG discussed the following I-D:
> Mobility Header Signaling Message 
> <draft-haley-mip6-mh-signaling-02.txt>
> 
> There was consensus in the meeting to make this a WG 
> document. We would like to obtain consensus on the WG ML 
> prior to making it a WG doc. Please review the I-D and 
> indicate if you are in favor of this I-D becoming a WG document.
> 
> We will decide after June 10th, 07 the status of this I-D 
> following the feedback from the WG members.
> 
> Abstract of the I-D:
>    This document specifies a new Mobility Header message type that can
>    be used between a mobile node and home agent to signal an 
> event that
>    requires attention.
> 
> -Raj
> 
> 
> _______________________________________________
> 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: Brian Haley <[email-masked]>
Date: Mon, 04 Jun 2007 17:04:04 -0400

Hi Raj,

Ahmad, Sri and I have talked off-line about how to go forward with 
draft-haley and support draft-muhanna better.  We've come to the 
following conclusion (someone update if I got this wrong).

Draft-haley will define a Generic Notification Message (GNM) which is a 
new MH type, and also define two new sub-types - one for Signaling 
Request, one for Signaling Reply (or some wording like that).

The structures would look something like this:

Generic Notification Message (w/MH message pieces, MH Type TBD)

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Payload Proto |  Header Len   |   MH Type     |   Reserved    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |           Checksum            |       GNM Type/Sub-Type       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In essence, the message is just a container to transport notification 
messages between mobility entities.

They we'd define two Sub-types with the same semantics of the current 
messages in draft-haley:

Signaling Request (GNM Type TBD):

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Sequence Number           |A|         Reserved            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Signaling Reply (GNM Type TBD):

        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Sequence Number           |    Status     |   Reserved    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This would give someone that wants to use the semantics of the Signaling 
Messages an easy framework for implentation (sequencing, retransmission, 
etc).  All they would have to do is define a mobility option with their 
data to go "inside".

Ahmad would define a new GNM Sub-type for revocation, and whatever 
structures and options to go with it.

I'll update draft-haley with these changes if there are no objections.

Thanks to Ahmad for the suggestions.

-Brian

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 14:48:46 -0700

This is not making sense to me. We have two messages in the 
current draft, the Mobility Header Signaling Request Message 
and the Mobility Header Signaling Acknowledgement Message. 
This is equivalent to the "Signaling request" and "Signaling
response" messages below. One has to just define new mobility 
options that go in the Signaling Request and Signaling 
Acknowledgement Message. 

I don't understand why you would want to define "subtype" 
fields in this message. Please let me know what I am missing.

Vijay

> From: Brian Haley [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 2:04 PM
> To: Basavaraj Patil
> Cc: Mobile IPv6 Mailing List; ext Sri Gundavelli
> Subject: Re: [Mip6] Consensus call: MakeI-D 
> >                                        |           GMC Type 
>            |
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                      Message Data                  
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> >                                        |           GMC Type 
>            |
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> >                                        |           GMC Type 
>            |
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> >                                        |           GMC Type 
>            |
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |
> >                                        |           GMC Type 
>            |
> >        |                                                    
>            |
> >        .                                                    
>            .
> >        .                                                    
>            .
> >        |                                                    
>            |

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 4 Jun 2007 17:02:47 -0500

Hi Vijay,

I am not sure why this does not make sense? Is there something specific
that you do not like?

The suggested mechanism defines a generic container mechanism and at the
same time gives the freedom for some notification mechanisms to have its
own specifics. Probably taking a look at all the discussion related to
this topic would be a good idea.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 4:49 PM
> To: Brian Haley; Basavaraj Patil
> Subject: RE: [Mip6] Consensus call: MakeI-D 
> > Draft-haley will define a Generic Notification Message 
> (GNM) which is 
> > a new MH type, and also define two new sub-types - one for 
> Signaling 
> > This would give someone that wants to use the semantics of the 
> > Signaling Messages an easy framework for implentation (sequencing, 
> > retransmission, etc).  All they would have to do is define 
> a mobility 
> > option with their data to go "inside".
> > 
> > > The following are the revocation messages that are defined by the 
> > > Binding Revocation Functionality as specified by the Binding 
> > > Binding Revocation messages and the binding revocation mechanism.
> > > 
> > > 
> > > Best Regards,
> > > Ahmad
> > > 
> document. We 
> > >> would like to obtain consensus on the WG ML prior to 
> making it a WG 
> > >> doc. Please review the I-D and indicate if you are in 
> favor of this 
> > >> I-D becoming a WG document.
> > >>
> > >> We will decide after June 10th, 07 the status of this 
> I-D following 
> > >> the feedback from the WG members.
> > >>
> > >> Abstract of the I-D:
> > >>    be used between a mobile node and home agent to 
> signal an event 
> > >> that
> > >>    requires attention.
> > >>
> > >> -Raj
> > >>
> > >>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 4 Jun 2007 15:22:07 -0700

Hi Ahmad,

I did go through all the emails on this topic. 

> I am not sure why this does not make sense? Is there 

Not clear why you want to embed some subtypes inside the
generic signaling message, whereas you could define mobility
options for each specific application of the generic signaling
message.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 4 Jun 2007 18:09:24 -0500

Hi Vijay,
Please see comments inline.

Regards,
Ahmad
 
> > I am not sure why this does not make sense? Is there something 
> > specific that you do not like?
> 
> options for each specific application of the generic 
> signaling message.

[Ahmad]
So you are against defining a generic mechanism that is flexible enough
to avoid the strict assumption you just stated which requires all
applications to fit all of its requirements/scenarios inside a single
option. IMO, this is not the best approach that we need to take.
Although you/we may think/imagine that the requirement set forth for the
signaling request/response message is good enough for all possible
applications for now, However, the proposed approach is more flexible
and does not have this rigid requirement.

On the other hand, we need to remember that an option is just an
extension, nothing more nothing less. It is used to communicate a HoA,
CoA, an NAI, etc. When it comes to binding revocation, a control
signaling mechanism, we may identify more than one of these options to
identify the proper action the receiving mobility entity needs to take.
Also, different scenarios may require different options. What I mean is,
fitting all the scenarios and functionality described in the Binding
Revocation for IPv6 Mobility draft in a single option is probably a
stretch.

Therefore, we need a mechanism which is flexible enough to allow
different applications to define its own specifics if necessary and I am
not sure why you think that approach is a bad thing! It would be a good
idea if you can identify some examples or use cases which shows that the
proposed approach is not a good thing to do. Honestly, I do not see a
point of objecting a good flexible approach for achieving the same
objectives of the draft-haley.

> 
> Vijay
> 
> > 
> > The suggested mechanism defines a generic container 
> mechanism and at 
> > the same time gives the freedom for some notification mechanisms to 
> > have its own specifics. Probably taking a look at all the 
> discussion 
> > related to this topic would be a good idea.
> > 
> > Regards,
> > Ahmad
> >  
> > 
> > > This is not making sense to me. We have two messages in 
> the current 
> > > draft, the Mobility Header Signaling Request Message and the 
> > > Mobility Header Signaling Acknowledgement Message.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 05 Jun 2007 09:51:47 +0200

Hi all,

I think that binding related signaling should not use a generic 
notification signaling.
First, it strongly contradicts RFC 3775:
RFC 3775 says:

6.1.  Mobility Header

   The Mobility Header is an extension header used by mobile nodes,
   correspondent nodes, and home agents in *all messaging related to the
   creation and management of bindings*.  The subsections within this
   section describe the message types that may be sent using the
   Mobility Header.

RFC 3775 provides some extension capabilities for the MH type that can 
be used to specify revocation commands.
It has been done this way in IPv4.
I am not against a generic notification signaling but i think it should 
be kept separate from the binding management signaling itself.

As far as the generic notification signaling draft is concerned 
(draft-haley), i think the term "notification" is not suited.
Generally speaking, I am not expecting a notification to carry a 
(command) request or a (command) response. The term "notification" does 
not ask for something but rather notify of something. Doing 
request-response with a "notification mechanism" is not consistent to 
me. If the draft intends to extends RFC 3775 with a generic signaling 
capability, it should be stated explicitly. Such a generic signaling 
capability could be used for request-response and notification. However, 
it should explicitly exclude binding management signaling that is 
specified in RFC 3775 and extended in draft-muhanna.

To summarize my opinion:
draft-haley => should be defined as a generic signaling protocol on top 
of MIP6 and exclude binding management signaling (RFC 3775 and futher 
revisions)
draft-muhanna => should be defined as extension to RFC 3775 (or new 
revision?) without relationship to draft-haley.

Any thoughts?

Bruno.

Brian Haley wrote:
> Draft-haley will define a Generic Notification Message (GNM) which is 
> a new MH type, and also define two new sub-types - one for Signaling 
> retransmission, etc).  All they would have to do is define a mobility 
>> mechanism    that can be used to communicate several common 
>> notification event(s)
>> between    the HA and the MN.
>>
>> Having said that, I would like to propose a small change to the 
>> current Draft-haley revision 02 which would hopefully enrich and 
>> enhance the
>> draft.
>>
>>    4.  Any functionality, e.g. Generic Notification, may define the 
>> use        of any MH option inside its own messages or define new ones.
>>
>> ===================================== This Signaling Generic Mobility 
>> Container Message uses the MH Type value
>> (TBD).
>>
>>
>>> From: Basavaraj Patil [mailto:[email-masked]] Sent: 
>>> Wednesday, May 30, 2007 12:23 PM
>>> There was consensus in the meeting to make this a WG document. We 
>>> would like to obtain consensus on the WG ML prior to making it a WG 
>>> doc. Please review the I-D and indicate if you are in favor of this 
>>> We will decide after June 10th, 07 the status of this I-D following 
>>>    be used between a mobile node and home agent to signal an event that
>>>    requires attention.
>>>
>>> -Raj
>>>
>>>

---

From: Brian Haley <[email-masked]>
Date: Tue, 05 Jun 2007 12:12:13 -0400

Hi Bruno,

>   section describe the message types that may be sent using the

I disagree with "strongly contradicts", the Mobility Header can be used 
for any number of mobility-related purposes, as it is in other drafts. 
Also, we are creating it to help with binding management - revocation, 
even signaling, etc.  RFC 3775 doesn't restrict it's use with a 
MUST/MUST NOT either.

> be kept separate from the binding management signaling itself.

There are no provisions in 3775 for binding revocation, the only thing a 
HA can do is deny the binding when the next BU is received.

> specified in RFC 3775 and extended in draft-muhanna.

The Mobile IPv4 Generic Notification Message is doing similar things, so 
I'd like to keep the naming consistent if we can.

> of MIP6 and exclude binding management signaling (RFC 3775 and futher 

I disagree.  We shouldn't restrict the Generic Notification message to 
certain types of messages, it should be usable for *anything* one 
mobility entity - the data contained inside is basically opaque.

> revision?) without relationship to draft-haley.

We just spent the last few days debating the best way to do this, and 
the authors agreed to work together and use a common mechanism.  So I 
disagree with this as well since I don't want to re-visit that discussion.

-Brian

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 5 Jun 2007 09:34:15 -0700

Hi Bruno,

Adding to Brian's comment .. 

> Sent: Tuesday, June 05, 2007 9:12 AM
> To: Bruno Mongazon-Cazavet
> Cc: Basavaraj Patil; Mobile IPv6 Mailing List; ext Sri Gundavelli
> Subject: Re: [Mip6] Consensus call: Make I-D 

Thanks for the review comments.

The notification messages have a relation to the established
session between the entities. The message has no purpose, if
there is no session. The exchanged message using the signaling
does not have to be just about a creation/deletion of the BCE,
but it can a message that has a relation to that state. A message
indicating that the mobile node's prepayed service is getting
expired has a relation to that session. So, with other messages,
"your home agent is getting rebooted in 5 minutes". So, the
notification message must use the MH signaling.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 27 Jun 2007 19:52:52 -0700

> Generic Notification Message (w/MH message pieces, MH Type TBD)

I have an objection. I would like to use the existing format of having
a generic signaling message and using mobility options to carry the
actual information. The above format has one drawback, in the sense
that you can't carry more than piece of information since you use the
subtype field to indicate what you are carrying. When you use mobility
options, you don't really have that restriction. You can chain any
number of mobility options.

Vijay

>>> Mobility Header Signaling Message <draft-haley-mip6-mh-signaling-02.txt>
>>>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 27 Jun 2007 22:21:32 -0700 (PDT)

Vijay,

> number of mobility options.

The addition of sub-type does not disallow the addition of
mobility options. It provides more flexibility for defining
messages with a fixed format where it cannot be expressed
or not suitable for expressing it as an option. Options are
suitable for carrying a fixed fields, such as HoA, NAI ..etc.
So, we can still do the same of chaining multiple options for
the same sub-type.

Sri

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 28 Jun 2007 20:33:56 +0900

Hi Brian and Ahmad,

The MH Signaling Request/Ack Message are deprecated, and
you introduce a new Generic Notification message, right?

I am basically fine with this. However, the last Vijay's comment is  
valid.
We cannot carry multiple messages in the same MH message.

Why not using option-type of the MH option, instead of  GNM Type/Sub- 
type?

draft-haley defines a MH type value for the generic notification message
and defines two MH options for signaling request and reply.

regards,
ryuji

On 2007/06/05, at 6:04, Brian Haley wrote:

> Draft-haley will define a Generic Notification Message (GNM) which  
> is a new MH type, and also define two new sub-types - one for  
> Signaling Request, one for Signaling Reply (or some wording like  
> that).
>
> In essence, the message is just a container to transport  
> notification messages between mobility entities.
>
> They we'd define two Sub-types with the same semantics of the  
> current messages in draft-haley:
>
> retransmission, etc).  All they would have to do is define a  
> mobility option with their data to go "inside".
>
>> o  A generic container which can be used to communicate  
>> multiple    functionalities while preserving the MH types.
>>    4.  Any functionality, e.g. Generic Notification, may define  
>> the use        of any MH option inside its own messages or define  
>> new ones.
>> Here is the format, let us use the Generic Notification and  
>> Binding Revocation as examples:
>> ===================================== This Signaling Generic  
>> Mobility Container Message uses the MH Type value
>> (TBD).
>>                                        |           GMC  
>> Type            |
>>        .                      Message  
>> Data                             .
>>                                        |           GMC  
>> Type            |
>>                                        |           GMC  
>> Type            |
>>                                        |           GMC  
>> Type            |
>>                                        |           GMC  
>> Type            |
>>> Subject: [Mip6] Consensus call: Make I-D draft-haley-mip6-mh- 
>>> signaling-02.txt a WG doc
>>>
>>>
>>> Hello,
>>>
>>> would like to obtain consensus on the WG ML prior to making it a  
>>> WG doc. Please review the I-D and indicate if you are in favor of  
>>> this I-D becoming a WG document.
>>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Jun 2007 04:58:18 -0700

> So, we can still do the same of chaining multiple options for

But, the subtype already tells you what the notification is about.
You obviously cannot include another mobility option that carries
information unrelated to the notification.

I am not suggesting the use of options to carry information just
to identify which home address or the NAI the information is
related to. We already have mobility options that can carry this
information. You just need to include them in this message. I am
am talking about the use of mobility option to carry the actual
contents of the notification message. This is what the earlier
version of the draft was talking about.

Vijay

---

From: Brian Haley <[email-masked]>
Date: Thu, 28 Jun 2007 11:11:29 -0400

> information unrelated to the notification.

We can define a sub-type (0) in the draft that says there is no specific 
information here, you must parse the options separately.  Is that ok?

-Brian

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 28 Jun 2007 08:46:01 -0700

> information here, you must parse the options separately.  Is that ok?

Yes, this will work. But why wouldn't this be the default for all
notification messages? The mobility option tells us what the
notification is about.

Vijay

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 29 Jun 2007 02:48:38 +0900

Hi Brian and Ahmad,

I was a bit confused about two different names (GNM type and sub- 
type) for the same field in the figure.
I'm basically fine with this approach. Thanks Ahmad to correct me.

regards,
ryuji