Subject: Re: [MEXT] Scope of generic notification

From: Michael Eriksson <[email-masked]>
Date: Tue, 3 Jun 2008 12:45:11 +0200

On Wed, May 28, 2008 at 15:12:48 +0200, marcelo bagnulo braun wrote:
> In our new charter we have a new item on a generic notification mechanism. 
> During discussion over the last weeks, it seems to me that the WG needs to 
> make a decision about what is the scope of the generic notification
> 
> In summary, we need to decide which is the scope of the generic
> notification and what is the scope of the existing MH types.
> Essentially, what need to be as clear as possible are the criteria
> for using the generic notification and which is the criteria for
> using a MH type.

I think that a generic notification mechanism should be used for all
in-session signaling for MIPv6, i.e., when there is a BCE for the MN
at the HA (or CN). It should be bidirectional, and thus allow
signaling both to and from a MN.

Having one single in-session signaling mechanism means that we don't
have to redesign/respecify message transport, protection,
retransmission, sequence numbering etc for each new signaling message.
This will make both the specifications and implementations less
complex.

The Generic Notification Message (GNM), as described in
draft-haley-mext-generic-notification-message-00.txt, is a good start
for such a mechanism (but see below for enhancements).

For a real-life use case, the GNM is spot-on for transmitting flow
distribution rules; see
http://tools.ietf.org/html/draft-larsson-mext-flow-distribution-rules-00
We are planning to soon write a short draft on how to transmit the
rules, both MN->HA and HA->MN, using the GNM.

Currently, I see two areas for GNM extension/improvement:

- The GNM should support protected signaling also between MN and CN,
  and not only between MN and HA as seems to be the case right now.

- I don't particularly like the "notification" part of GNM's name, as
  I think it will should be used for more than notifications.

Regards,
Michael
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Hui Deng" <[email-masked]>
Date: Wed, 4 Jun 2008 00:30:21 +0800

Hello, all,

Speaking for operator, we do not like to see more complex security SAs support.
we prefer more generic way to do this.

The way of generic message draft is preferable.
Writing a binding reovocation extension will not cost long time.
If working group  have concensus on it, I could contribute to write it down.

-Hui

>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of marcelo bagnulo braun
>> Sent: Wednesday, May 28, 2008 9:13 PM
>> To: [email-masked]
>> Cc: Julien Laganier
>> Subject: [MEXT] Scope of generic notification
>>
>> Hi all,
>>
>> During discussion over the last weeks, it seems to me that
>> the WG needs to make a decision about what is the scope of
>> the generic notification
>>
>> In summary, we need to decide which is the scope of the
>> generic notification and what is the scope of the existing MH types.
>> Essentially, what need to be as clear as possible are the
>> criteria for using the generic notification and which is the
>> criteria for using a MH type.
>>
>> We would kindly ask the WG to comment on this, so we can make
>> a decision
>>
>> Next, i include some background information about how i see
>> this, but feel free to completely ignore it.
>>
>> I guess that one way to scope the generic notification, we
>> could first define what is the goal of the generic
>> notification. From Sri's draft, for instance, my
>> understanding is that the generic notification goal is to
>> allow a mean to provide asynchronous messages. (i am not sure
>> what asynchronous means in this context, but i assume that it
>> means not included in a BU/BA exchange??).
>>
>> If that is the case, i don't see why we need this, since we
>> can always use another mobility header and define new
>> messages to be exchanged.
>> From Vijay's email, i understand that one of the goals is to
>> save MH types, since they are a scarce resource. That seems
>> reasonable.
>> Raj mentioned that Generic notification is to be used for non
>> critical things. Other mentioned that this should only be
>> used for send and discard things.
>>
>>
>> Now, the next question then is when to use a new MH header
>> and when to use the generic notification. I think the generic
>> notification document needs to explicitly define its scope.
>>
>> I guess that the elements that should be taken into account
>> for the definition of the scope are the message exchange
>> supported by the generic notification, the security mode,
>> others?. In the message exchange, the question is whether the
>> generic notification is just a notification, a notification
>> plus an ACK, reliable delivery (i.e.
>> retransmission till the sender receives an ACK), or a more
>> complex message exchange i.e. more than one message
>> retransmitted in each direction.
>>
>> Now, one option would be to define the generic notification
>> so broad that it is a mere extension of the MH type, so that
>> we can encode more values in there, without much definition
>> of the message format.
>>
>> Another option would be to define a query/response message
>> format and scope the generic notification to this type of
>> simple interactions.
>>
>> A third option would be to define a reliable delivery, whith
>> tiemouts and retransmissions (slightly more complex than the
>> previous one)
>>
>> Other options that support more complex message exchange
>> could also be conceived.
>>
>> So, bottom line we need to clearly define the scope of the
>> generic notification and when to use MH types for extnesions.
>> This include the type of message exchange supported, the type
>> of information conveyed (critical or just infoormation),
>> security and so on. I think this is a high level disucssion
>> that the WG needs to have before we can move forward with the
>> generic notification and also with the binding revocation,
>> since once we define what is the scope of generic
>> notification and the MH type usage, we will be able to
>> conclude in which category the binding revocation falls.
>>
>> Regards, marcelo
>>
>>
>>
>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Jun 2008 01:03:16 -0500

> 
> Hi Marcelo,
> 
> Yes. It should provide all the general semantics required for 
> mobility entities to exchange events associated with the 
> established mobility session.
> 
> Regards
> Sri

[Ahmad]
It is worth the time to take a snap shot of the your "moving target"
definition of the scope of the generic notification message:

1. During Prague MIP6 meeting, you were specifically asked about the
scope of the Generic Notification Message and your answer was as
follows: From the IETF-68, MIP6 meeting minutes:

"
Alper; what is the scope of the message.
Sri: Opaque load, HA is going down after 1 hr or something?
"

2. Despite that you were a co-author on the Generic Notification message
draft, you joined as a co-author for the
draft-muhanna-mip6-binding-revocation- which, from day one, uses new MH
types for BRI and BRA. You did not seem to have any concern at the time!

3. During the MIP6 mailing list discussion, you defended the draft for
using new MH types.

4. In the latest Generic Notification Message draft, it says: 

"
   RFC 3775 [RFC3775] contains no provision for Mobile IPv6 entities,
   such as a home agent or mobile node, to send and receive asynchronous
   notification messages during a mobility session.
"

More over, it says:

"
   This document describes a generic notification message protocol that
   can be used by Mobile IPv6 entities for sending and receiving simple
   notification events.
"

5. During the discussion round before the last on MEXT you defined the
Notification as "It does not require semantics beyond a simple
request/reply message format" Ironically, that the scope of all mobility
protocol messages.

6. Finally, you just announced that Generic Notification Message is all
of the above and beyond!

Wow; it is quite a journey of change/modification/development that is
very interesting. The only thing I can say here that it is a function of
TIME!

Cheers!

> 
> On Fri, 30 May 2008, marcelo bagnulo braun wrote:
> 
> > Hi Sri,
> >
> > So, your view is that the generic notification should be as 
> general as 
> > possible and should be able to support reliable delivery, message 
> > exchange from the HA and from the MN or for any other party 
> involved, 
> > with different type of security (IPSec protected and non IPSec 
> > protected), for critical and for non critical things and so on?
> >
> > Regards, marcelo
> >
> >

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 09:26:02 +0200

Folks,

With my WG chair hat firmly off, I'd like to say that I agree with 
everything Henrik said on this topic (Scope of generic notification).

Thanks.

--julien

On Thursday 29 May 2008, Henrik Levkowetz wrote:
> Hi Marcelo,
>
> On 2008-05-29 16:23 marcelo bagnulo braun said the following:
> > Henrik Levkowetz escribió:
> >> Umm... Yes.  But if we have to use a new MH type for a
> >> communication between
> >> peers where the generic notification mechanism is available, that
> >> would likely
> >> indicate a failure in designing the generic notification
> >> mechanism, no?
> >
> > well, it depends on what do you think it is scope for generic
> > notification hence this discussion.
> >
> > You can envisage that generic notification is only for non reliable
> > delivery of information. So, you can scope it that way, and the it
> > is very clear: any information flowing from the HA that needs no
> > reliable ddelivery, you should use generic notification. Else you
> > should use a new MH type. (that is merely an example)
> >
> > OTOH, you can define the scope being much broader, that i think is
> > what you have in mind i.e. any information cnoveyed from the HA to
> > the MN should use the generic notification. New MH types are
> > reserved for information sent from the MN i guess then. We should
> > then define the generic notification format in a much more general
> > way, that can accomodate all kind of message exchange initiated by
> > the HA and all king of security and so on.
> >
> > I understand that your preference is that the generic notiication
> > emssage should be able to accomodate any information exchange
> > initiated by the HA, is that correct?
>
> No, I think I've still not quite managed to get across what I'm
> trying to say.  I'm not advocating any specific property of the
> generic notification mechanism, except that it should be generic. 
> I'm advocating that it should (in addition to being somewhat generic)
> be *useful* for the use case (or cases) we know about today.  More
> below.
>
> > I am perfectly ok with any of these or other options. My only point
> > is that the WG should define what the scope of the generic
> > notification is
> >
> >>> My question is then when to use the generic notification (with
> >>> the MH type assigned to the generic notification) and when to use
> >>> a new MH type, makes sese now or am i still missing something?
> >>
> >> No, I think I got you now.  But to me that would mean that if you
> >> have to use a new MH type because the generic notification
> >> mechanism won't work, then you have failed to define the generic
> >> notification mechanism appropriately.
> >>
> >> If you wish to use a new MH type because the semantics is
> >> fundamentally different than what's been envisaged for the generic
> >> notification, that's fine.  I have a hard time seeing that
> >> applying to binding revocation, though...
> >
> > I would leave the binding revocation discussion out of this for
> > now. Once we agreed on what the scope of the generic notification
> > should be, it should be fairly easy to understand if the binding
> > revocation should use it or not i guess
>
> No no no.  This is the point.  We can define a beautiful mechanism
> which could be useless, or only useful for things which isn't really
> needed by anybody.  I don't think that's what we should do, though.
>
> How many specific examples do we have of proposed messages with real
> deployment needs behind them?
>
> Discussing the properties of a message mechanism out of context of
> the specific examples which we know are needed today may lead to a
> beautiful but useless design.  Discussing the properties of the
> message mechanism in the context of known use cases is vital, in
> order to get something with a reasonable chance of actually being
> appropriate and useful.  Divorcing the generic notification mechanism
> from the most obvious potential use case for the mechanism doesn't
> make sense to me.
>
>
> Regards,
>
> 	Henrik
>

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 09:49:17 +0200

Hello Ahmad,

> follows: From the IETF-68, MIP6 meeting minutes:

[...]

> 6. Finally, you just announced that Generic Notification Message is
> all of the above and beyond!
>
> very interesting. The only thing I can say here that it is a function
> of TIME!

FWIW:

I don't think someone changing its opinion over time is an issue. 

Actually, I firmly claim the right to change my opinion over time, as I 
sometimes don't understand all implications of an issue in the 
beginning.

Let me also note that if all of us would always stick to our first 
opinion and never change them, it could make discussion useless in case 
everybody has an opinion from the start :)

Finally, and as a funny note only (no offense intended), the French 
language has this saying (maybe other languages have it too) : "Only 
imbeciles never change their mind". Maybe we should all learn from 
that :-P

Best regards,

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Jun 2008 07:00:25 -0500

> Actually, I firmly claim the right to change my opinion over 
> time, as I sometimes don't understand all implications of an 
> issue in the beginning.
> 
> Let me also note that if all of us would always stick to our 
> first opinion and never change them, it could make discussion 
> useless in case everybody has an opinion from the start.
> 
> Finally, and as a funny note only (no offense intended), the 
> French language  has this saying (maybe other languages have 
> it too) : "Only imbeciles never change their mind". Maybe we 
> should all learn from that :-P

[Ahmad]
Hello Julien,

Heheh .. sure that is in many other languages:-P I may as well quote you
what a famous professor of engineering said in the court of law, when he
was faced with a quotation from his own book, he said: "I am not a
vegetable; I learn something new every day". 

Bottom line, did I say learning new stuff is a bad thing? ... As long as
we swing within reasonable range;)

Best Regards,
Ahmad

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 5 Jun 2008 07:30:59 -0700 (PDT)

I will repeat one last time.

You are wasting your time, you are stuck on using a new MH type for
revocation message and nothing else works for you. Just go and use
it, define transport, DSMIP considerations, security and firewall
considerations. Fine, just that the document will have more pages.
Myself or Brian is not going to argue against this. I think, we
already said this twice.

Now, to accomodate this, dont say the scope of Generic Notification
is for saving MH types. The draft is written with a purpose and the
use cases as listed in the earlier versions even included Revocation
message (atleast a year before the -00 version of the revocation
draft was published). Go and check.

W.r.t my changing opinions, as you put it, go and check the meeting
minutes for the last 2 IETF's. In both the occassions when I was
presenting the Generic Notification draft, a question was asked,
"Does revocation use this Generic Notification message" and I said
"Yes".

Agreeing to work together on Revocation does not imply, I agreed to
the use of a new MH type.

I'm really baffled as why this is such a big deal. I simply dont
understand how it impacts the revocation draft. Its one line stating,
"these messages use the Generic Notification format". I will not try
to understand that, its a waste of time.

Botton line, I gave my opinion on the scope of notification draft.
I'm not interested or have the time to argue against the use of new
MH type in revocation message. Its a procedural issue as Raj put it
and is not a technical issue. Dont drag me into this argument. Do
what you want or convince the WG, not me.

Sri

---

From: Michael Eriksson <[email-masked]>
Date: Tue, 3 Jun 2008 12:03:29 +0200

Regards,
Michael

---

From: Julien Laganier <[email-masked]>
Date: Thu, 5 Jun 2008 17:42:38 +0200

Folks,

<wg chair hat off>

What Michael said above rang a bell :)

How about calling the new framework "MIPv6 Generic Signaling Message 
(MGSM), and defines two MH types, one requiring IPsec, the other not.

Then we would distinguish different types of messages (Revocation, Flow 
Distribution Rules, Heartbeat, etc.) based on a subtype inside the 
Generic Signaling Message.

I think that should satisfy everybody:
- the IPsec SPD needs only one set of rules for each of the MH types 
(bypass, and protect).
- a MGSM consumer (e.g. Revocation, Distribution Rules) simply specify 
the MH type it chooses depending on whether or not it requires IPsec 
protection.
- a MGSM consumer allocates one or more MGSM subtypes for each new 
message necessary to implement the consumer's functionality.
- a MGSM consumer specifies processing (sending, receiving, state 
machines...) for these subtyped messages.

What do you think?

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Jun 2008 10:45:26 -0500

Thanks Julien. 
This a good framework which address all concerns and flexible enough!

Regards,
Ahmad

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Thursday, June 05, 2008 10:43 AM
> To: [email-masked]
> Cc: Michael Eriksson; marcelo bagnulo braun; Muhanna, Ahmad 
> (RICH1:2H10)
> Subject: Generic Signaling Message / Name of generic 
> "notification" (Was: [MEXT] Scope of generic notification)
> 
> How about calling the new framework "MIPv6 Generic Signaling 
> Message (MGSM), and defines two MH types, one requiring 
> IPsec, the other not.
> 
> Then we would distinguish different types of messages 
> (Revocation, Flow Distribution Rules, Heartbeat, etc.) based 
> on a subtype inside the Generic Signaling Message.
> 
> - the IPsec SPD needs only one set of rules for each of the 
> MH types (bypass, and protect).
> - a MGSM consumer (e.g. Revocation, Distribution Rules) 
> simply specify the MH type it chooses depending on whether or 
> not it requires IPsec protection.
> - a MGSM consumer allocates one or more MGSM subtypes for 
> each new message necessary to implement the consumer's functionality.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 5 Jun 2008 10:53:14 -0500

agree

Mohamed

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julien Laganier
Sent: Thursday, June 05, 2008 10:43 AM
To: [email-masked]
Subject: [MEXT] Generic Signaling Message / Name of generic "notification" (Was: Scope of generic notification)

Folks,

<wg chair hat off>

What do you think?

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Jun 2008 18:04:43 +0200

Julien Laganier wrote:
>> - I don't particularly like the "notification" part of GNM's name,
>> as I think it will should be used for more than notifications.
> 
> Folks,
> 
> <wg chair hat off>
> 
> Then we would distinguish different types of messages (Revocation,
> Flow Distribution Rules, Heartbeat, etc.) based on a subtype inside
> the Generic Signaling Message.
> 
> I think that should satisfy everybody: - the IPsec SPD needs only one
> set of rules for each of the MH types (bypass, and protect). - a MGSM
> consumer (e.g. Revocation, Distribution Rules) simply specify the MH
> type it chooses depending on whether or not it requires IPsec 
> protection. - a MGSM consumer allocates one or more MGSM subtypes for

Huh?  Doesn't MIPv6 already have signaling?  BU/BAck/BErr/BRR/RR/etc are 
_not_ signaling?

Revocation can be done by sending BAck lifetime 0.  Flow Distribution
rules can be sent by UDP (much higher level than MIP6) payloads encoding
  flow labels and traffic classes, or with http payloads containing XML
descriptions of these flows.  Heartbeats are periodic messages, which
BUs are.

Or is it that 3GPP requires this?  If 3GPP requires this framework then
it may make sense to call it "3GPP MIPv6 Generic Signaling Message 
(3MGSM)", no?

Sorry if it sounds way off the current understanding, I may miss something.

Alex

> 
> --julien _______________________________________________ MEXT mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 05 Jun 2008 09:17:11 -0700

Hello Julien,

Could you provide some examples of messages that
would NOT fit as subtypes of  the proposed generic
signaling message?

Regards,
Charlie P.

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Jun 2008 12:02:43 -0500

> Huh?  Doesn't MIPv6 already have signaling?  
> BU/BAck/BErr/BRR/RR/etc are _not_ signaling?
> 
> Revocation can be done by sending BAck lifetime 0.

[Ahmad]
Hi Alex,
Did you mean a BU with lifetime = 0 ?

---

From: "Benjamin Lim" <[email-masked]>
Date: Fri, 6 Jun 2008 10:41:03 +0800

Hi,

Allow me to cut in. Pls see below. 

=8==8<=8==
> Revocation can be done by sending BAck lifetime 0.  Flow 
[Ben] Out of curiosity, this "revoke" BAck from HA/CN would contain a seq
no. that MN has already received a BAck from. I.e MN sends BU with seq no. 5
with lifetime 7 mins. HA/CN respond back with BAck seq no. 5 with status 0
(BU accepted). 3 mins later, HA/CN decide to revoke MN's binding by sending
"revoke" BAck with seq no. 5 and lifetime 0.

To MN, will it suspect if the "revoke" Back is a replay attack?
 
> Distribution rules can be sent by UDP (much higher level than 
> MIP6) payloads encoding
>   flow labels and traffic classes, or with http payloads 
> containing XML descriptions of these flows.  Heartbeats are 
> periodic messages, which BUs are.
> 
> Or is it that 3GPP requires this?  If 3GPP requires this 
> framework then it may make sense to call it "3GPP MIPv6 
> Generic Signaling Message (3MGSM)", no?
[Ben] I am not clear if 3GPP requires such notification mechanism, but
personally I prefer Julien's title "MIPv6 Generic Signaling Message (MGSM)".
Sounds more neutral to me ;p

As I mention before on the ML, we have yet utilized around 10% of the MH
type, so I see no reason why we want to overload the current signalling to
support new notifications.  If we want to overload the current signalling,
then we must carefully look into how these new changes would impact the
current protocol (e.g. the possible replay attack I mention above). 

Personally, I agree with what Julien proposing to have a main MH type to
state that this is a notification message and a sub type to state what kind
of notification message it is. IMHO, this looks like the cleanest way to go.

Regards,
Benjamin Lim

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 06 Jun 2008 10:27:11 +0200

so Alex, are you suggesting the the work in generic notification is not 
needed?

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 11:15:57 +0200

On Thursday 05 June 2008, Alexandru Petrescu wrote:
> > Message (MGSM), and defines two MH types, one requiring IPsec, the
> > other not.
> >
> > I think that should satisfy everybody: - the IPsec SPD needs only
> > one set of rules for each of the MH types (bypass, and protect). -
> > a MGSM consumer (e.g. Revocation, Distribution Rules) simply
> > specify the MH type it chooses depending on whether or not it
> > requires IPsec protection. - a MGSM consumer allocates one or more
> > MGSM subtypes for each new message necessary to implement the
> > consumer's functionality. - a MGSM consumer specifies processing
> > (sending, receiving, state machines...) for these subtyped
> > messages.
> >
> > What do you think?
>
> Huh? 

Bouh!

> Doesn't MIPv6 already have signaling?  BU/BAck/BErr/BRR/RR/etc  
> are _not_ signaling?

<WG chair hat ON>

Alex, IMO we've already spent way too much time on this topic and I'd 
really like us to move forward. Discussion is good, as long as it's 
productive.

To make a discussion productive, we'd rather all pay great attention to 
what other people are saying, try as much as possible to understand 
their view, and uttermost, not misrepresent their opinions.

So let's try to get this straight and avoid drifting. 

<WG chair hat OFF>

Did I ever said that MIPv6 has no signaling?

Did I ever said BU/Back/Berr/BRR are not signaling?

What I've been proposing is a GENERIC signaling message for MIPv6.

> Revocation can be done by sending BAck lifetime 0.  

I think we all know very well that BAck stands for "Binding 
Acknowledgment". What you're proposing here is that the HA, on its own 
initiative, *acknowledge* that a binding has been revoked, without 
having been asked anything.

It's called a semantic overloading, and it's just plainly wrong. 
Explicitness is one of the top qualities of a protocol design.

> Flow Distribution rules can be sent by UDP (much higher level than
> MIP6) payloads encoding flow labels and traffic classes, or with http
> payloads containing XML descriptions of these flows.  

Some principles of architecture cleanliness tells us that something 
manipulating MIPv6 layer concepts belongs to the MIPv6 layer, and thus 
should be implemented at the MIPv6 layer, as much as possible.

> Heartbeats are periodic messages, which BUs are.

Not sure what you mean here. Are you proposing to implement heartbeats 
with BUs? A BU is a "Binding Update", heartbeats are not intended to 
update a binding, thus that would again be semantic overloading again, 
wrong.

> Or is it that 3GPP requires this?  If 3GPP requires this framework
> then it may make sense to call it "3GPP MIPv6 Generic Signaling
> Message (3MGSM)", no?

Let's not start one of the great 3GPP debate, I have no time and no beer 
right now :)

> Sorry if it sounds way off the current understanding, I may miss

I guess you do...

--julien

---

From: Julien Laganier <[email-masked]>
Date: Fri, 6 Jun 2008 11:25:10 +0200

> Hello Julien,

Hello Charlie,

> would NOT fit as subtypes of  the proposed generic

Not sure how an answer to that question is actually useful, but anyway: 
Home Test Init, Home Test, Care-of Test Init, Care-of Test, Binding 
Update, Binding Acknowledgement, Binding Refresh Request, and Binding 
Error.

Cheers,

--julien

> > - the IPsec SPD needs only one set of rules for each of the MH
> > types (bypass, and protect).
> > - a MGSM consumer (e.g. Revocation, Distribution Rules) simply
> > requires IPsec protection.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jun 2008 12:09:09 +0200

marcelo bagnulo braun wrote:
> 
> so Alex, are you suggesting the the work in generic notification is 
> not needed?

Since you ask, I suppose you have 1000 reasons up the sleeve to counter
my arguments.  But yes, I believe the generic notification can simply be
achieved with simple extensions of MIP6 existing messages.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jun 2008 12:09:41 +0200

> Did you mean a BU with lifetime = 0 ? 

Sorry, I meant BAck with lifetime 0, not BU with lifetime 0.  HA would 
thus tell MN it no longer keeps the BC entry for it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jun 2008 12:09:26 +0200

Benjamin Lim wrote:
>> Huh?  Doesn't MIPv6 already have signaling? BU/BAck/BErr/BRR/RR/etc
>> are _not_ signaling?
>> 
> [Ben] Out of curiosity, this "revoke" BAck from HA/CN would contain a
> seq no. that MN has already received a BAck from. I.e MN sends BU
> with seq no. 5 with lifetime 7 mins. HA/CN respond back with BAck seq
> no. 5 with status 0 (BU accepted). 3 mins later, HA/CN decide to
> revoke MN's binding by sending "revoke" BAck with seq no. 5 and
> lifetime 0.

Right, sounds reasonable to me to not send BAck with a seqno already
used.  Maybe reserver seqno 0 for this purpose?  Or maybe HA waits for
next BU before sending a revoking BAck?  Or maybe use a special BRR?

> To MN, will it suspect if the "revoke" Back is a replay attack?

That's indeed an issue.  Maybe reserve 0 seqno value as special, or 
other flag in BAck or something.

>> Distribution rules can be sent by UDP (much higher level than MIP6)
>> payloads encoding flow labels and traffic classes, or with http
>> payloads containing XML descriptions of these flows.  Heartbeats
>> are periodic messages, which BUs are.
>> 
> [Ben] I am not clear if 3GPP requires such notification mechanism,
> but personally I prefer Julien's title "MIPv6 Generic Signaling
> Message (MGSM)". Sounds more neutral to me ;p
> 
> As I mention before on the ML, we have yet utilized around 10% of the
> MH type, so I see no reason why we want to overload the current
> signalling to support new notifications.

If one takes a longer term perspective one wouldn't be worried of having
used only 10% of MH type space in a couple of years.  For example, the
version field of IP header has used even less percentage in more years;
and similar with ICMP types.

> If we want to overload the current signalling, then we must carefully
> look into how these new changes would impact the current protocol
> (e.g. the possible replay attack I mention above).
> 
> Personally, I agree with what Julien proposing to have a main MH type
> to state that this is a notification message and a sub type to state
> what kind of notification message it is. IMHO, this looks like the
> cleanest way to go.

Alex

> Regards, Benjamin Lim
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit 
>> http://www.messagelabs.com/email 
>>  _______________________________________________ MEXT mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>> 
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 06 Jun 2008 12:33:47 +0200

Julien Laganier wrote:
>>>> - I don't particularly like the "notification" part of GNM's
>>>> name, as I think it will should be used for more than
>>>> notifications.
>>> Folks,
>>> 
>>> <wg chair hat off>
>>> 
>>> Message (MGSM), and defines two MH types, one requiring IPsec,
>>> the other not.
>>> 
>>> (Revocation, Flow Distribution Rules, Heartbeat, etc.) based on a
>>> subtype inside the Generic Signaling Message.
>>> 
>>>  one set of rules for each of the MH types (bypass, and protect).
>>> requires IPsec protection. - a MGSM consumer allocates one or
>>> more MGSM subtypes for each new message necessary to implement
>>> the consumer's functionality. - a MGSM consumer specifies
>>> processing (sending, receiving, state machines...) for these
>>> subtyped messages.
>>> 
>>> What do you think?
>> Huh?
> 
> Bouh!
> 
>> Doesn't MIPv6 already have signaling?  BU/BAck/BErr/BRR/RR/etc are
>> _not_ signaling?
> 
> <WG chair hat ON>
> 
> To make a discussion productive, we'd rather all pay great attention
> to what other people are saying, try as much as possible to
> understand their view, and uttermost, not misrepresent their
> opinions.
> 

If it does have signaling, why is there a need for a Generic signaling?

> Did I ever said BU/Back/Berr/BRR are not signaling?

If you didn't say it, I deduce BU/BAck/BErr/BRR are not signaling.  IF
these are _not_ signaling then what are they?

> Acknowledgment". What you're proposing here is that the HA, on its
> own initiative, *acknowledge* that a binding has been revoked,
> without having been asked anything.
> 

It would become an explicit revocation by setting a flag in it 'R' -
Revoking Binding Ack.

>> MIP6) payloads encoding flow labels and traffic classes, or with
>> http payloads containing XML descriptions of these flows.
> 
> manipulating MIPv6 layer concepts belongs to the MIPv6 layer, and
> thus should be implemented at the MIPv6 layer, as much as possible.

If people doing QoS with TC/flow label implemented all the QoS features
in the IP header then it would be .

But we have a very strong divergence with respect to Flows, what they
are and how semantically the MIP6 flows are different than the flows
labelled in IPv6 base header.

WE have such diverging views that I think we couldn't discuss these end
results.

> Not sure what you mean here. Are you proposing to implement
> heartbeats with BUs? A BU is a "Binding Update", heartbeats are not
> intended to update a binding, thus that would again be semantic
> overloading again, wrong.

Ok, but one would love to have only one heartbeat for MIP6, not two.
GEneric Signalling would propose one, DSMIPv6 proposes another one.  And
on top of that BUs are periodic already.

> Let's not start one of the great 3GPP debate, I have no time and no
> beer right now :)

Ok, I simply can't see it as  "MIPv6 Generic Signaling", because "MIPv6
Signaling" is BU/BAck/BErr/RR/MPD/DHAAD already.

>> Sorry if it sounds way off the current understanding, I may miss 

Sorry, I'll shut up.

Alex

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 06 Jun 2008 12:53:55 +0200

No, i have one very simple reason:
There was a discussion about rechartering and we try to keep it as open 
as possible. The conclusion from this discussion was to do this work. 
So, now it is not a good time to revisit that decision.

regards, marcelo

---

From: Henrik Levkowetz <[email-masked]>
Date: Sun, 08 Jun 2008 20:40:27 +0200

> machines...) for these subtyped messages.

Sounds reasonable to me, as a rough plan.

	Henrik

---

From: "Julien Bournelle" <[email-masked]>
Date: Mon, 9 Jun 2008 13:04:44 +0200

Hi,

 inline..

> machines...) for these subtyped messages.

 sounds good to me. Thanks julien.

 -julien

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 10 Jun 2008 19:38:43 -0700 (PDT)

Hi Julien,

This change should be fine ..

Thanks
Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 11 Jun 2008 09:39:04 +0200

Julien,

Would it still be possible to allocate new MH types for new MIP messages? If the answer is yes, then we need some criteria to define which new messages get its own MH type and which become an MGSM message. Otherwise this definition will not help avoding the discussions that we have right now about BRI and MH type.

domagoj

> Sent: 05. lipanj 2008 17:43
> To: [email-masked]
> Subject: [MEXT] Generic Signaling Message / Name of generic 
> "notification"(Was: Scope of generic notification)
>

---

From: Julien Laganier <[email-masked]>
Date: Wed, 11 Jun 2008 11:28:46 +0200

Domagoj,

On Wednesday 11 June 2008, Premec, Domagoj wrote:
> Julien,
>
> Would it still be possible to allocate new MH types for new MIP
> messages? 

Yes it would be possible. The plan is to design a MGSM framework that is 
as generic as possible and should thus be suitable to most needs. 
However we can't predict for sure that an usage that can't be satisfied 
with MGSM won't arise in the future.

> If the answer is yes, then we need some criteria to define 
> which new messages get its own MH type and which become an MGSM
> message. Otherwise this definition will not help avoding the
> discussions that we have right now about BRI and MH type.

I don't think we need a criteria -- The BRI/MH type discussion happened 
because we hadn't an MGSM framework yet. 

Once we have MGSM, and we have a specific protocol extension to realize, 
it's IMO pretty straightforward to decide between new MH types and 
MGSM: Either the protocol extension can be realized with MGSM thus it 
uses MGSM, or it can't thus it gets new header types. An alternative 
could also be to extend MGSM so that it can supports the new protocol 
extension.

--julien

> > > - I don't particularly like the "notification" part of
> >
> > GNM's name, as
> >
> > each new message necessary to implement the consumer's
> > functionality. - a MGSM consumer specifies processing (sending,
> > receiving, state machines...) for these subtyped messages.
> >
> > What do you think?
> >
> > --julien

---

From: Julien Laganier <[email-masked]>
Date: Mon, 16 Jun 2008 14:45:21 +0200

Folks,

<WG chair hat ON>

It seems we have reach an agreement on the ML w.r.t. the way forward 
for "notification"/"revocation" work items: 

- The working group will specify MIPv6 Generic Signalling Message 
(MGSM), using at least two different MH type values, one w/ IPsec 
protection (protect) and the other w/o IPsec protection (bypass). The 
MGSM shall be used whenever possible to implement future MIPv6 
signalling. Different consumers of the MGSM will be distinguished based 
on the MGSM subtype value they use.

- The MIPv6 Binding Revocation will be based on MGSM.

--julien and marcelo, MEXT chairs