Subject: [Mip6] Consensus call: Adopting I-D

From: Basavaraj Patil <[email-masked]>
Date: Thu, 23 Aug 2007 12:15:54 -0500

Hello,

This is a consensus call for adopting I-D: Binding Revocation for IPv6
Mobility <draft-muhanna-mip6-binding-revocation-01.txt> as a MIP6 WG
document.

The I-D has been discussed on the ML in the past and was also presented at
IETF69 in Chicago.

So please opine on the following statement:

The binding revocation feature specified in I-D
draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6
deployments and hence should be made a MIP6 WG document and progressed as a
standards track doc.

Yes [ ]
No  [ ]

-Raj

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 23 Aug 2007 13:49:11 -0700

Raj,
Was there a conclusion on how this draft relates to draft-haley? 

Sorry if I missed it. 

Vidya 

> -----Original Message-----
> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 10:16 AM
> To: Mobile IPv6 Mailing List
> Cc: Gopal Dommety
> Subject: [Mip6] Consensus call: Adopting I-D
> 
> 
> Hello,
> 
> This is a consensus call for adopting I-D: Binding Revocation 
> for IPv6 Mobility 
> <draft-muhanna-mip6-binding-revocation-01.txt> as a MIP6 WG document.
> 
> draft-muhanna-mip6-binding-revocation-01.txt is essential for 
> MIP6 deployments and hence should be made a MIP6 WG document 
> and progressed as a standards track doc.
> 
> Yes [ ]
> No  [ ]
> 
> -Raj
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 23 Aug 2007 21:57:15 -0500

Hi Vidya,

Yes... There was a conclusion and basically we agreed that the MH message
specified in draft-haley can be used as the means for revocation.

This draft specifies the details of the Reg-revocation message, the behavior
and operation of the MN and HA in the context of binding revocation.

-Raj

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 24 Aug 2007 14:15:53 +0900

Hi Raj,

Yes, I support this document as a WG item.

ryuji

On 2007/08/24, at 2:15, Basavaraj Patil wrote:

> Yes [ x]

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 24 Aug 2007 10:26:19 +0200

> Yes [X]

---

From: Julien Laganier <[email-masked]>
Date: Fri, 24 Aug 2007 10:51:00 +0200

On Thursday 23 August 2007, Basavaraj Patil wrote:
> deployments and hence should be made a MIP6 WG document and
> progressed as a standards track doc.

Yes [X]
No  [ ]

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 24 Aug 2007 08:39:35 -0500

Hi Vidya/All,

I just would like to give some clarification, the most up-to-date
solution of the draft, which was based on latest discussion on the MIP6
mailing list, was presented during MIPv6 meeting in Chicago. We
basically presented the use of one MH type "Generic Notification
message" with a subtype field. The subtype is used to differentiate
Binding revocation signaling messages from other notification signaling.

For more information, please take a look at the details in the
revocation slides at the link below.

http://www3.ietf.org/proceedings/07jul/slides/mip6-3/sld1.htm

Regards,
Ahmad

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Thursday, August 23, 2007 3:49 PM
> To: Basavaraj Patil; Mobile IPv6 Mailing List
> Cc: Gopal Dommety
> Subject: RE: [Mip6] Consensus call: Adopting I-D
> 
> Raj,
> > MIP6 deployments and hence should be made a MIP6 WG document and

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 27 Aug 2007 13:50:31 +0200

> Yes [x ]

BR,

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 10:44:28 -0700

Hi Raj,

I do agree that we need to standardize a binding revocation mechanism. 
But I am not sure about adopting 
draft-muhanna-mip6-binding-revocation-01.txt. If we are adopting this 
document, we need substantial changes. My comments at a high level

1. I had argued for using mobility options in the generic mobility 
header signaling message to carry the revocation information. Those 
changes haven't been done yet. Also, I don't believe we have consensus 
on changing the format of the generic mobility header signaling message 
to include a sub-type. I guess that is the current assumption.

2. I don't think the Binding Revocation Indication message should be 
sent from the MAG to the LMA. draft-muhanna-mip6-binding-revocation says

    In the case when the MAG receives a direct or indirect indication or
    the MAG finds that the MN has moved a way and no longer attached to
    the it, the MAG MAY send a BRI message to indicate to the LMA that
    the MN session binding has been cleaned up at the MAG and the LMA
    needs to clean up the allocated and reserved resources.  If the LMA
    processes the BRI message and the A bit is set, the LMA MUST send a
    BRA message in response to the MAG.

If the MN moves awas, the MAG sends a de-registration Proxy BU to the 
LMA. Not the BRI message. The de-registration Proxy BU would inform the 
LMA that the MN is no longer attached to the MAG that sent the message.

The draft goes beyond and specifies handover behavior for PMIPv6.

    Since there is no guaranteed indication to the LMA that the MAG has
    sent the BRI message due to a MN move during an inter-MAG handoff,
    the LMA SHOULD start a T_Handoff_Progress_timer to make sure that the
    MN session binding survives an inter-MAG handoff.

Figure 5 and 6 specify new handover procedure for PMIPv6.
This does not belong in this draft.

3. From what was presented at the IETF meeting regarding this draft, I 
don't think bindings should be revoked based on the CoA or Home Network 
Prefix. The HoA, MN Identifier and the BID are sufficient. I would like 
clarification on when the CoA or the Home Network Prefix would be used 
in binding revocation messages.

Hope that helps.

Vijay

---

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 27 Aug 2007 12:22:49 -0700

The I-D has been discussed on the ML in the past and was also presented
at
IETF69 in Chicago.

The binding revocation feature specified in I-D
draft-muhanna-mip6-binding-revocation-01.txt is essential for MIP6
deployments and hence should be made a MIP6 WG document and progressed
as a standards track doc.

Yes [X]
No  [ ]

---

From: Sebastian Thalanany <[email-masked]>
Date: Mon, 27 Aug 2007 16:55:25 -0500

Hi, Raj,
               
The binding revocation feature, specified in I-D 
draft-muhanna-mip6-binding-revocation-01.txt, should be progressed further.

Yes [x ]
No  [ ]

Regards,
    Sebastian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 27 Aug 2007 18:13:27 -0700

A meta question concerning this draft - how does it fit into the current
MIP6 or proposed MEXT charter? 

Thanks,
Vidya

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 28 Aug 2007 11:25:15 -0500

Hi Vidya,

In the context of the MIP6 charter:
"
The primary goal of the MIP6 working group will be to enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments.
"

Binding revocation is a feature that is required from deployments
perspective and hence it fits into the current charter.

Since MEXT is essentially a consolidation of multiple MIP6 related WGs, I
believe this work item would be a carryover from MIP6 to MEXT.

Having said that, I do however have some questions about this document scope
that is related to Netlmm.

This I-D is specifying a binding revocation mechanism that is applicable to
MIP6 and PMIP6. The consensus call is in the MIP6 WG. I think that given the
PMIP6 aspects included in this I-D, it would make sense to consult with you
and Jonne (Netlmm chairs) about opinions on this I-D.

The MIP6 WG charter and scope is focused on extensions to the MIP6 protocol
(RFC3775) and issues related to base MIP6. From a charter and scope
perspective, this I-D oversteps the boundaries of MIP6 and is treading in
Netlmm waters. 
It is possible that the feature which addresses MIP6 and PMIP6 can be done
as a joint WG item (MIP6/MEXT and Netlmm). But I want to make sure that
Netlmm is aware of it and supports it as well.

If the binding revocation feature were to be done only as a MIP6 WG
I-D/feature, the PMIP6 aspects in this I-D would have to be removed and any
enhancements needed to make binding revocation work in the case of PMIP6
would have to be done in Netlmm.

-Raj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 28 Aug 2007 16:22:19 -0500

Hi Raj,

I agree; the scope of the work extends to Mobile IPv6 and Proxy
Mobile IPv6. As we stated in our presentation in Chicago meeting,
the semantics and the messaging we are defining for supporting
Binding Revocation should address the requirements of both MIP6 and
Netlmm WG's.
It is exactly the same as how the work of DS-MIP6 is being leveraged by
NETLMM and
NEMO WG's. 

IMHO, Revocation should fall in the same category. That is the reason 
why we titled the draft Binding Revocation for IPv6 mobility:-) The
purpose of the messages, the formats and the actions can all be
captured in a common document. Defining multiple documents for
this simple messaging is not a good idea, I hope we as a group will 
take the best decision on this, especially, as I just said that there is
already
a precedent in the case of DS-MIPv6 draft.

We will be happy to work with the NETLMM chairs and the AD to get this 
adopted as a joint WG document.

Best Regards,
Ahmad

> Sent: Tuesday, August 28, 2007 12:25 PM
> To: ext Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> Subject: Re: [Mip6] Consensus call: Adopting I-D
> 
> 
> Hi Vidya,
> 
> IPv6 mobility by continuing work on developments that are 
> required for wide-scale deployments.
> "
> 
> Binding revocation is a feature that is required from 
> deployments perspective and hence it fits into the current charter.
> 
> Since MEXT is essentially a consolidation of multiple MIP6 
> related WGs, I believe this work item would be a carryover 
> from MIP6 to MEXT.
> 
> Having said that, I do however have some questions about this 
> document scope that is related to Netlmm.
> 
> PMIP6 aspects included in this I-D, it would make sense to 
> consult with you and Jonne (Netlmm chairs) about opinions on this I-D.
> 
> (RFC3775) and issues related to base MIP6. From a charter and 
> scope perspective, this I-D oversteps the boundaries of MIP6 
> and is treading in Netlmm waters. 
> It is possible that the feature which addresses MIP6 and 
> PMIP6 can be done as a joint WG item (MIP6/MEXT and Netlmm). 
> But I want to make sure that Netlmm is aware of it and 
> supports it as well.
> 
> If the binding revocation feature were to be done only as a 
> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have 
> to be removed and any enhancements needed to make binding 
> revocation work in the case of PMIP6 would have to be done in Netlmm.
> 
> -Raj
>  
> 
> 
> >> This is a consensus call for adopting I-D: Binding Revocation for 
> >> IPv6 Mobility <draft-muhanna-mip6-binding-revocation-01.txt> as a 
> >> MIP6 WG document.
> >>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Aug 2007 17:42:42 -0700

Raj, all,
I'd like to understand the need for revocation in MIP6 better.  I think
we've had a discussion on how to do revocation, but, not so much on why
we would need it for MIP6.  Please note that this is not a discussion on
PMIPv6 - I'm trying to specifically understand this in the context of
MIP6. 

A revocation mechanism was developed for MIP4 to allow a clean up of
resources at the mobility agents (FA/HA).  The philosphy of revocation
applies to managed networks and in such networks, a AAA disconnect
message (or equivalent) is likely to first cut off any network access to
the MNs before even MIP6 has a chance to revocate anything - so, I'm not
sure I understand why we need revocation. Note that the non-MIP6
mechanism is needed regardless so that network access can be revoked for
nodes not using MIP6 as well.  

I've seen a number of people support adoption of this draft - so,
perhaps there is a good reason for it that I'm just not seeing.  I'd
appreciate a clarification. 

Thanks,
Viday

> Sent: Tuesday, August 28, 2007 9:25 AM
> To: Narayanan, Vidya; Mobile IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 28 Aug 2007 22:52:13 -0500

Hi Vidya,

Thanks Vidya for the question. I actually was planning to check with you
and Jonnie on this topic but I had been very busy here at 3GPP2 meeting
and I had to go out to eat:-(

I believe that we, earlier, had quite good amount of discussion on this
topic, however, I must admit it was mixed with revocation applicability
to PMIPv6 too.

Now, let me try to address your MIPv6 specific question. There is one
scenario when the HA would like to revoke the MN session, for example:
administrative reasons. As you said, Disconnect message could be sent to
the HA for that purpose. Now: I, at least, think of two options here:

Option 1. The HA deletes the binding cache entry and forget about the
mobile node and the HA starts dropping the MN packets/traffic, I would
call this "a bad customer service and a bad example that operators would
like to avoid such a non-graceful revocation mechanism"

Option 2. As soon as the HA receives the Disconnect message, for
example, the HA sends a revocation message and informs the MN that its
binding has been revoked with the proper code which should indicate the
reason behind revoking the MN binding. In that case, MN probably can
delete its binding with other CN or, at least, gives the MN a chance to
start a simple IP session, for example, etc.

Now since you mentioned MIPv4 Revocation, I would like to mention that
long time ago, early 2002, there has been a lot of discussion during
RFC3543 development which was translated into allowing the MN to clearly
indicate if it (the MN) needs to be informed when its session is revoked
or NOT. There is an "I" bit in the revocation extension. That is similar
to the case in MIPv6. Not only that, but RFC3543, Registration
Revocation in Mobile IPv4, also addresses MIPv4 registration in the case
of Co-CoA sessions. This is exactly the same as in MIPv6.

Having said the above, I believe that revocation mechanism is needed in
multiple scenarios which were presented in Chicago meeting as follows:

1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg)
2. Revoking a PMIPv6 session. (PMIPv6 - Netlmm wg)
3. Revoking a specific Care-of-Address for a multiple care-of-addresses
sessions (Monami6 wg)

The common thing for all of these scenarios is that all of them use an
extension of MIPv6 protocol. Since one simple mechanism can address all
of these scenarios, then one draft would be the best choice. As I said
earlier there is already a precedent at IETF with DS-MIPv6. IMHO, it
does make a lot of sense to address all of these scenarios which happen
to extend across several wgs in a single draft using one simple and
generic mechanism.

Finally, in fairness to all the fine people who thus far supported this
draft as MIP6 wg document, I believe their support was based on the
applicability of this draft to MIPv6 and PMIPv6 and I am sure some of
them also have Monami6 applicability in mind.

Best Regards,
Ahmad

> Sent: Tuesday, August 28, 2007 8:43 PM
> To: Basavaraj Patil; Mobile IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> Subject: Need for revocation in MIP6 (RE: [Mip6] Consensus 
> call: Adopting I-D)
> 
> Raj, all,
> I'd like to understand the need for revocation in MIP6 
> better.  I think we've had a discussion on how to do 
> revocation, but, not so much on why we would need it for 
> MIP6.  Please note that this is not a discussion on
> PMIPv6 - I'm trying to specifically understand this in the 
> context of MIP6. 
> 
> A revocation mechanism was developed for MIP4 to allow a 
> clean up of resources at the mobility agents (FA/HA).  The 
> philosphy of revocation applies to managed networks and in 
> such networks, a AAA disconnect message (or equivalent) is 
> likely to first cut off any network access to the MNs before 
> even MIP6 has a chance to revocate anything - so, I'm not 
> sure I understand why we need revocation. Note that the 
> non-MIP6 mechanism is needed regardless so that network 
> access can be revoked for nodes not using MIP6 as well.  
> 
> I've seen a number of people support adoption of this draft - 
> so, perhaps there is a good reason for it that I'm just not 
> seeing.  I'd appreciate a clarification. 
> 
> Thanks,
> Viday
> 
> > Since MEXT is essentially a consolidation of multiple MIP6 related 
> > WGs, I believe this work item would be a carryover from 
> MIP6 to MEXT.
> > 
> > Having said that, I do however have some questions about 
> this document 
> > scope that is related to Netlmm.
> > 
> > PMIP6 aspects included in this I-D, it would make sense to consult 
> > with you and Jonne (Netlmm chairs) about opinions on this I-D.
> > 
> > perspective, this I-D oversteps the boundaries of MIP6 and 
> is treading 
> > in Netlmm waters.
> supports it as 
> > well.
> > MIP6 WG I-D/feature, the PMIP6 aspects in this I-D would have to be 
> > removed and any enhancements needed to make binding 
> revocation work in 
> > the case of PMIP6 would have to be done in Netlmm.
> > 
> > -Raj
> >  
> > 
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 28 Aug 2007 22:53:55 -0700

Hi Ahmad,
The point I was making is that the AAA disconnect messages are sent to
the NAS, not the HA - that causes network access being terminated for
the MN.  The MN won't even get the MIP6 revocation message once network
access is revoked.  

I realize that the MIP4 revocation is also supported in the spec for MNs
in CCoA mode - but, I'm not aware of any real world use of that.  

Regards,
Vidya 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Tuesday, August 28, 2007 8:52 PM
> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing 
> List; Jonne Soininen
> Cc: Gopal Dommety
> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] 
> Consensus call: Adopting I-D)
> 
> Hi Vidya,
> 
> Thanks Vidya for the question. I actually was planning to 
> check with you and Jonnie on this topic but I had been very 
> busy here at 3GPP2 meeting and I had to go out to eat:-(
> 
> I believe that we, earlier, had quite good amount of 
> discussion on this topic, however, I must admit it was mixed 
> with revocation applicability to PMIPv6 too.
> 
> Now, let me try to address your MIPv6 specific question. 
> There is one scenario when the HA would like to revoke the MN 
> session, for example:
> administrative reasons. As you said, Disconnect message could 
> be sent to the HA for that purpose. Now: I, at least, think 
> of two options here:
> 
> Option 1. The HA deletes the binding cache entry and forget 
> about the mobile node and the HA starts dropping the MN 
> packets/traffic, I would call this "a bad customer service 
> and a bad example that operators would like to avoid such a 
> non-graceful revocation mechanism"
> 
> Option 2. As soon as the HA receives the Disconnect message, 
> for example, the HA sends a revocation message and informs 
> the MN that its binding has been revoked with the proper code 
> which should indicate the reason behind revoking the MN 
> binding. In that case, MN probably can delete its binding 
> with other CN or, at least, gives the MN a chance to start a 
> simple IP session, for example, etc.
> 
> Now since you mentioned MIPv4 Revocation, I would like to 
> mention that long time ago, early 2002, there has been a lot 
> of discussion during
> RFC3543 development which was translated into allowing the MN 
> to clearly indicate if it (the MN) needs to be informed when 
> its session is revoked or NOT. There is an "I" bit in the 
> revocation extension. That is similar to the case in MIPv6. 
> Not only that, but RFC3543, Registration Revocation in Mobile 
> IPv4, also addresses MIPv4 registration in the case of Co-CoA 
> sessions. This is exactly the same as in MIPv6.
> 
> Having said the above, I believe that revocation mechanism is 
> needed in multiple scenarios which were presented in Chicago 
> meeting as follows:
> 
> 1. Revoking a MIPv6 session. (MIPv6 - MIP6 wg) 2. Revoking a 
> PMIPv6 session. (PMIPv6 - Netlmm wg) 3. Revoking a specific 
> Care-of-Address for a multiple care-of-addresses sessions (Monami6 wg)
> 
> The common thing for all of these scenarios is that all of 
> them use an extension of MIPv6 protocol. Since one simple 
> mechanism can address all of these scenarios, then one draft 
> would be the best choice. As I said earlier there is already 
> a precedent at IETF with DS-MIPv6. IMHO, it does make a lot 
> of sense to address all of these scenarios which happen to 
> extend across several wgs in a single draft using one simple 
> and generic mechanism.
> 
> Finally, in fairness to all the fine people who thus far 
> supported this draft as MIP6 wg document, I believe their 
> support was based on the applicability of this draft to MIPv6 
> and PMIPv6 and I am sure some of them also have Monami6 
> applicability in mind.
> 
> 
> Best Regards,
> Ahmad
>  
> 
> > I'd like to understand the need for revocation in MIP6 better.  I 
> > think we've had a discussion on how to do revocation, but, 
> not so much 
> > on why we would need it for MIP6.  Please note that this is not a 
> > discussion on
> context of 
> clean up of 
> > message (or equivalent) is likely to first cut off any 
> network access 
> > to the MNs before even MIP6 has a chance to revocate anything - so, 
> > I'm not sure I understand why we need revocation. Note that the
> access can be 
> > revoked for nodes not using MIP6 as well.
> > 
> > > MIP6 and PMIP6. The consensus call is in the MIP6 WG. I 
> think that 
> > > given the
> > > > A meta question concerning this draft - how does it fit 
> into the 
> > > > current
> > > >> IPv6 Mobility

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 29 Aug 2007 06:05:23 -0500

Hi Vidya,

Ok. I did not realize that you meant sending Disconnect message to the
NAS. I assume that Disconnect message is originated from the H-AAA and
in that case it makes a lot of sense to be sent to the HA which keeps a
record of the MN binding and can communicate the revocation to the MN
via a revocation message. In case that H-AAA sends the Disconnect to the
NAS ONLY, then this revocation style would fit option 1 discussed
earlier:-(

On the question of real world deployment, I do not claim that I have a
record of all deployments out there, but I, very well, remember that
including the option of notifying the MN with FA-CoA and the support of
Co-CoA mode were based on a long discussion and requests from vendors
and operators which, IMO, is still valid and is very well reflected by
the interest of the people who already have supported the adoption of
this draft thus far.

Regards,
Ahmad

> Sent: Wednesday, August 29, 2007 1:54 AM
> To: Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil; Mobile IPv6 
> Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> The point I was making is that the AAA disconnect messages 
> are sent to the NAS, not the HA - that causes network access 
> being terminated for the MN.  The MN won't even get the MIP6 
> revocation message once network access is revoked.  
> 
> I realize that the MIP4 revocation is also supported in the 
> spec for MNs in CCoA mode - but, I'm not aware of any real 
> world use of that.  
> 
> Regards,
> Vidya 
> 
> List; Jonne 
> > Soininen
> check with 
> > you and Jonnie on this topic but I had been very busy here at 3GPP2 
> > meeting and I had to go out to eat:-(
> > 
> > I believe that we, earlier, had quite good amount of discussion on 
> > this topic, however, I must admit it was mixed with revocation 
> > applicability to PMIPv6 too.
> > 
> > There is one scenario when the HA would like to revoke the 
> MN session, 
> > for example:
> > administrative reasons. As you said, Disconnect message 
> could be sent 
> > to the HA for that purpose. Now: I, at least, think of two options 
> > here:
> > 
> about the 
> > call this "a bad customer service and a bad example that operators 
> > would like to avoid such a non-graceful revocation mechanism"
> > 
> > binding has been revoked with the proper code which should indicate 
> > the reason behind revoking the MN binding. In that case, MN 
> probably 
> > can delete its binding with other CN or, at least, gives the MN a 
> > chance to start a simple IP session, for example, etc.
> > 
> mention that 
> > RFC3543 development which was translated into allowing the MN to 
> > clearly indicate if it (the MN) needs to be informed when 
> its session 
> > is revoked or NOT. There is an "I" bit in the revocation extension. 
> > That is similar to the case in MIPv6.
> > Not only that, but RFC3543, Registration Revocation in Mobile IPv4, 
> > also addresses MIPv4 registration in the case of Co-CoA 
> sessions. This 
> > Having said the above, I believe that revocation mechanism 
> is needed 
> > in multiple scenarios which were presented in Chicago meeting as 
> > follows:
> > 
> them use an 
> > extension of MIPv6 protocol. Since one simple mechanism can address 
> > all of these scenarios, then one draft would be the best 
> choice. As I 
> > said earlier there is already a precedent at IETF with 
> DS-MIPv6. IMHO, 
> > it does make a lot of sense to address all of these scenarios which 
> > happen to extend across several wgs in a single draft using 
> one simple 
> > and generic mechanism.
> > 
> > Finally, in fairness to all the fine people who thus far supported 
> > this draft as MIP6 wg document, I believe their support was 
> based on 
> > the applicability of this draft to MIPv6 and PMIPv6 and I 
> am sure some 
> > of them also have Monami6 applicability in mind.
> > 
> > 
> > Best Regards,
> > Ahmad
> >  
> > 
> deployments 
> > > > >> The I-D has been discussed on the ML in the past and 
> was also 
> > > > >> presented at
> > > > >> IETF69 in Chicago.
> > > > >>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 29 Aug 2007 11:21:31 -0500

Ahmad,

DS-MIP6 is not really a precedent. Work on DS-MIP6 has been ongoing for
quite a while now (couple of years at least). The DS-MIP6 I-D has been
developed as a solution for MIP6 and the design considerations in the
document precede any PMIP6 discussion in the IETF. DS-MIP6 is a joint
MIP6/NEMO WGs effort.

If the binding revocation mechanism for MIP6 and PMIP6 were to be specified
in a single I-D, it would have to be a joint WG item (MIP6/Netlmm).
Else, scope of I-D will need to change.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 29 Aug 2007 11:56:05 -0500

Hi Vidya,

But the AAA could notify the HA (via the HA-AAA interface for which we are
specifying requirements in MIP6) about the Disconnect prior to sending the
Disconnect to the NAS. And this would allow a graceful detach from the HA??

-Raj

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Aug 2007 10:15:41 -0700

Hi Raj,
Hmmm.. The AAA could certainly notify the HA.  But, a AAA that is
interested in revoking access to an MN would contact the NAS first, if
not in parallel with the HA.  After all, the AAA is getting accounting
records from the NAS - note that even if the HA is also physically
serving as a AAA aggregation point for accounting (which itself cannot
be generalized), it is still a logically separate function that will
forward on the AAA disconnect messages all the way to the NAS, resulting
in MN's access being revoked. 

So, the AAA notification to the HA would be good to clean up the HA
resources, but, I'm still not seeing a practical need for revocation in
MIP6 - the MN has likely had its access revoked before the HA sends the
MIP6 revocation out.  

Vidya

> Sent: Wednesday, August 29, 2007 9:56 AM
> To: Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing 
> List; Jonne Soininen
> Cc: Gopal Dommety
> Subject: Re: Need for revocation in MIP6 (RE: [Mip6] 
> But the AAA could notify the HA (via the HA-AAA interface for 
> which we are specifying requirements in MIP6) about the 
> Disconnect prior to sending the Disconnect to the NAS. And 
> this would allow a graceful detach from the HA??
> 
> -Raj
> 
> 
> are sent to 
> > the MN.  The MN won't even get the MIP6 revocation message once 
> > network access is revoked.
> > 
> spec for 
> > MNs in CCoA mode - but, I'm not aware of any real world use of that.
> > 
> > Regards,
> > Vidya
> > 
> >> To: Narayanan, Vidya; Basavaraj Patil; Mobile IPv6 Mailing List; 
> >> Jonne Soininen
> >> Cc: Gopal Dommety
> >> mobile node and the HA starts dropping the MN packets/traffic, I 
> >> would call this "a bad customer service and a bad example that 
> >> operators would like to avoid such a non-graceful revocation 
> >> mechanism"
> >> 
> >> example, the HA sends a revocation message and informs the MN that 
> >> its binding has been revoked with the proper code which should 
> >> indicate the reason behind revoking the MN binding. In 
> that case, MN 
> >> probably can delete its binding with other CN or, at 
> least, gives the 
> >> MN a chance to start a simple IP session, for example, etc.
> >> 
> >> Now since you mentioned MIPv4 Revocation, I would like to mention 
> >> that long time ago, early 2002, there has been a lot of discussion 
> >> during
> >> also addresses MIPv4 registration in the case of Co-CoA sessions. 
> >> This is exactly the same as in MIPv6.
> >> 
> them use 
> >> an extension of MIPv6 protocol. Since one simple mechanism can 
> >> address all of these scenarios, then one draft would be the best 
> >> choice. As I said earlier there is already a precedent at 
> IETF with 
> >> DS-MIPv6. IMHO, it does make a lot of sense to address all 
> of these 
> >> scenarios which happen to extend across several wgs in a 
> single draft 
> >> using one simple and generic mechanism.
> >> 
> >> this draft as MIP6 wg document, I believe their support 
> was based on 
> >> the applicability of this draft to MIPv6 and PMIPv6 and I am sure 
> >> some of them also have Monami6 applicability in mind.
> >> 
> >> 
> >> Best Regards,
> >> Ahmad
> >>  
> >>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 29 Aug 2007 12:42:19 -0500

Hi Vidya,

I agree that if the issue is primarily resource clean up, a notification
from the AAA to the HA will deprecate the binding.

But if the AAA sends a Disconnect to the NAS, I am not sure if there is a
graceful mechanism to indicate to the MN that it is being disconnected. Of
course there are many different ways to indicate that the MN has been
disconnected from the network and these could also be access technology
dependent. However if there is no good way to indicate to the MN that it has
been disconnected, the MN would continue to believe that it still has MIP6
binding and subsequently may cause a delay in creating a binding with the HA
when the MN does attach (for example via another access type). So I think it
would still make sense to indicate to the MN that the HA has revoked the
binding. 
There is of course an issue about synchronizing the AAA Disconnect to the
NAS and the indication to the HA to ensure that the MN can be notified of
the binding revocation prior to pulling the plug at the NAS. But I think
this can be dealt with.

-Raj

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 29 Aug 2007 10:47:03 -0700

I was not following this thread ... just a comment on this. No
time for long discussions.

We cannot just assume AAA to be deployed in the network and
assume the entire revocation to be activated and managed through
AAA. Pretty much all the specs, including "HA Switchover",
"Notifications", "HA Reliability" ... every thing could be 
achieved through AAA. What we need is a mobility messaging and with
no assumption on the presence of AAA. 3775 does not assume AAA on
the network either. AAA is not mandataroy for mobility to be achieved.
That is just one interface most useful for cellular networks. I dont
know if any one would apply AAA for enterprise mobility. 

Now, if the case where AAA interface is not present, if HA wants to
revoke the mobile node's binding, it needs a mechanism to notify the
mobile node and the spec defines the signaling for that.

Regarding the scope of the work, we cannot expect every WG to go and
define the same protocol, changing the entity names and by defining
a new usecase. If some one goes and defines Revocation for PMIP6, the
work is not going to be vastly different. Its the same messaging and
with a different title. If we look at this work in the sense of
project management, this work should be done once and leveraged by
other WG's (That's been Jari's position regarding leveraging work).
Again, just as how DSMIP6 work is being leveraged in 10 different
places. That really helped and in the same way, this work should be
done just in the base MIP6 group and be leveraged by other WG's. Hope,
this work will be adopted as a joint WG item across NEMO, MIP6, NETLMM
and MONAMI6.

Sri

> To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing 
> List; Jonne Soininen
> Cc: Gopal Dommety
> Consensus call:Adopting I-D)
> 
> 
> Hi Vidya,
> 
> which we are
> spec for MNs

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Aug 2007 11:07:44 -0700

Doing "HA switch" or "Notifications" or "HA Reliability" via AAA doesn't
make sense - those are functions of MIP6.  Revocation is a policy thing
and is associated with AAA or an equivalent entity (HSS or whatever
other entity).  I don't believe we are making the right comparisons
here.  

Of all the items listed, I can perhaps see the need for NETLMM, for
cleaning up MAG resources upon revocation of the MN.  For NEMO, MIP6 or
MONAMI6, I don't see the point.  And, I particularly don't want to
discuss the NETLMM need here at this time, since we haven't yet
discussed it in the NETLMM WG.  For the purpose of MEXT, I'm not seeing
the practical need for revocation. 

Vidya

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, August 29, 2007 10:47 AM
> To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad Muhanna'; 
> 'Mobile IPv6 Mailing List'; 'Jonne Soininen'
> Cc: 'Gopal Dommety'
> I was not following this thread ... just a comment on this. 
> No time for long discussions.
> 
> 
> assume the entire revocation to be activated and managed 
> through AAA. Pretty much all the specs, including "HA 
> Switchover", "Notifications", "HA Reliability" ... every 
> thing could be achieved through AAA. What we need is a 
> mobility messaging and with no assumption on the presence of 
> AAA. 3775 does not assume AAA on the network either. AAA is 
> not mandataroy for mobility to be achieved.
> That is just one interface most useful for cellular networks. 
> I dont know if any one would apply AAA for enterprise mobility. 
> 
> Now, if the case where AAA interface is not present, if HA 
> wants to revoke the mobile node's binding, it needs a 
> mechanism to notify the mobile node and the spec defines the 
> signaling for that.
> 
> Regarding the scope of the work, we cannot expect every WG to 
> go and define the same protocol, changing the entity names 
> and by defining a new usecase. If some one goes and defines 
> Revocation for PMIP6, the work is not going to be vastly 
> different. Its the same messaging and with a different title. 
> If we look at this work in the sense of project management, 
> this work should be done once and leveraged by other WG's 
> (That's been Jari's position regarding leveraging work).
> Again, just as how DSMIP6 work is being leveraged in 10 
> different places. That really helped and in the same way, 
> this work should be done just in the base MIP6 group and be 
> leveraged by other WG's. Hope, this work will be adopted as a 
> joint WG item across NEMO, MIP6, NETLMM and MONAMI6.
> 
> Sri
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> > To: ext Narayanan, Vidya; Ahmad Muhanna; Mobile IPv6 Mailing List; 
> > Jonne Soininen
> > Cc: Gopal Dommety
> > Subject: Re: Need for revocation in MIP6 (RE: [Mip6] Consensus 
> > call:Adopting I-D)
> > 
> > 
> > Hi Vidya,
> > 
> > But the AAA could notify the HA (via the HA-AAA interface 
> for which we 
> > are specifying requirements in MIP6) about the Disconnect prior to 
> > sending the Disconnect to the NAS. And this would allow a graceful 
> > detach from the HA??
> > 
> > -Raj
> > 
> > 
> > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus 
> > >> call: Adopting I-D)
> > >> 
> > >> Hi Vidya,
> > >> 
> > >> Thanks Vidya for the question. I actually was planning to check 
> > >> with you and Jonnie on this topic but I had been very 
> busy here at 
> > >> 3GPP2 meeting and I had to go out to eat:-(
> > >> 
> > >> administrative reasons. As you said, Disconnect message could be 
> > >> sent to the HA for that purpose. Now: I, at least, think of two 
> > >> options here:
> > >> 
> > >> Option 1. The HA deletes the binding cache entry and 
> forget about 
> > >> the mobile node and the HA starts dropping the MN 
> packets/traffic, 
> > >> I would call this "a bad customer service and a bad example that 
> that case, 
> > >> MN probably can delete its binding with other CN or, at least, 
> > >> gives the MN a chance to start a simple IP session, for example, 
> > >> etc.
> > >> 
> > >> clearly indicate if it (the MN) needs to be informed when its 
> > >> session is revoked or NOT. There is an "I" bit in the revocation 
> > >> extension. That is similar to the case in MIPv6.
> > >> The common thing for all of these scenarios is that all 
> of them use 
> > >> choice. As I said earlier there is already a precedent 
> at IETF with 
> > >> DS-MIPv6. IMHO, it does make a lot of sense to address 
> all of these 
> > >> scenarios which happen to extend across several wgs in a single 
> > >> draft using one simple and generic mechanism.
> > >> 
> supported 
> was based 
> > >> on the applicability of this draft to MIPv6 and PMIPv6 and I am 
> > >> sure some of them also have Monami6 applicability in mind.
> > >> 
> > >> 
> > >> Best Regards,
> > >> Ahmad
> > >>  
> > >> 
> better.  I

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 29 Aug 2007 11:15:21 -0700

HA reboot is not a policy event. HA is rebooting, it wants to
send a graceful event to the mobile. I dont see why AAA function
should be involved here. This is one usecase. Again, 3775 does
not assume AAA entity in the mobility infrastructure and so
the signaling has to be based on MIP6 signaling. 

Extending this further, offering mobility service involves
some policy aspect. So, it is possible to get rid of MIP6
signaling and let AAA notify both HA and MN to setup the
binding state. 

Sure, no need to bring NETLMM usecases for this discussion.

Sri

> Sent: Wednesday, August 29, 2007 11:08 AM
> To: Sri Gundavelli; Basavaraj Patil; Ahmad Muhanna; Mobile 
> IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> > > >>>> This I-D is specifying a binding revocation 
> mechanism that is 
> > > >>>> applicable to

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 29 Aug 2007 11:38:55 -0700

I'll make a final point and stop here.  Most managed networks that are
considering the use of MIP6 today allow a mix of MIP6 and non-MIP6
capable nodes to exist on the network.  A mechanism of revoking access
is needed for both MIP6 and non-MIP6 capable endpoints and they don't
need to be different.  

When the NAS receives a disconnect, it stops accepting packets sourced
from that IP address (the CoA, in the MIP6 case) and also won't forward
anything to that IP address - surely, we are not saying that the NAS
understand MIP6 signaling and forward that alone on to the MN.  Good
mobile implementations should automatically blow any state associated
with that IP address (including MIP6 state), when access is revoked.  

Vidya

> Sent: Wednesday, August 29, 2007 10:42 AM
> I agree that if the issue is primarily resource clean up, a 
> notification from the AAA to the HA will deprecate the binding.
> 
> But if the AAA sends a Disconnect to the NAS, I am not sure 
> if there is a graceful mechanism to indicate to the MN that 
> it is being disconnected. Of course there are many different 
> ways to indicate that the MN has been disconnected from the 
> network and these could also be access technology dependent. 
> However if there is no good way to indicate to the MN that it 
> has been disconnected, the MN would continue to believe that 
> it still has MIP6 binding and subsequently may cause a delay 
> in creating a binding with the HA when the MN does attach 
> (for example via another access type). So I think it would 
> still make sense to indicate to the MN that the HA has 
> revoked the binding. 
> There is of course an issue about synchronizing the AAA 
> Disconnect to the NAS and the indication to the HA to ensure 
> that the MN can be notified of the binding revocation prior 
> to pulling the plug at the NAS. But I think this can be dealt with.
> 
> -Raj
> 
> 
> > forward on the AAA disconnect messages all the way to the NAS, 
> > resulting in MN's access being revoked.
> > 
> > resources, but, I'm still not seeing a practical need for 
> revocation 
> > in
> for which 
> >> we are specifying requirements in MIP6) about the 
> Disconnect prior to 
> >> forget about the
> >>>> Care-of-Address for a multiple care-of-addresses 
> sessions (Monami6
> >>>> wg)
> >>>>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 29 Aug 2007 11:55:03 -0700

Adding a final comment to close this discussion from my end
as well.

If an operator goes to the Home Agent and clears a specific
binding for what ever reasons, that revocation event needs
to be propagated by the use MIP6 signaling. AAA is not the
only source for activating revocation events and AAA may or
may not even be there in a given architecture. It is also
possible the AAA server in an access network MAY not have
a relation to the AAA server in the home network.  

The base protocol should have the required hooks for proper
mobility management. Assuming AAA (a non mobility function)
to exist in a given architecture, is just one solution and
leaves the base protocol incomplete.

Hope this discussion helps in adopting this work across
all WG's, leveraging MIP6 protocol. Thanks

Regards
Sri

> Sent: Wednesday, August 29, 2007 11:15 AM
> To: 'Narayanan, Vidya'; 'Basavaraj Patil'; 'Ahmad Muhanna'; 
> Consensus call:AdoptingI-D)
> 
> 
> > > > >>>> The MIP6 WG charter and scope is focused on 
> extensions to the
> > > > >>>> MIP6 protocol

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 29 Aug 2007 14:04:52 -0500

Raj,

I agree. 
All what I am saying is: addressing revocation for all related MIP6
protocols in one document is the best option. However, as you said, in
that case, it needs to be a joint draft.

Regards,
Ahmad

> Sent: Wednesday, August 29, 2007 12:22 PM
> To: Muhanna, Ahmad (RICH1:2H10); ext Narayanan, Vidya; Mobile 
> Cc: Gopal Dommety; Sri Gundavelli
> DS-MIP6 is not really a precedent. Work on DS-MIP6 has been 
> ongoing for quite a while now (couple of years at least). The 
> DS-MIP6 I-D has been developed as a solution for MIP6 and the 
> design considerations in the document precede any PMIP6 
> discussion in the IETF. DS-MIP6 is a joint MIP6/NEMO WGs effort.
> 
> If the binding revocation mechanism for MIP6 and PMIP6 were 
> to be specified in a single I-D, it would have to be a joint 
> WG item (MIP6/Netlmm).
> > I agree; the scope of the work extends to Mobile IPv6 and 
> Proxy Mobile 
> > IPv6. As we stated in our presentation in Chicago meeting, the 
> > semantics and the messaging we are defining for supporting Binding 
> > Revocation should address the requirements of both MIP6 and Netlmm 
> > WG's.
> > It is exactly the same as how the work of DS-MIP6 is being 
> leveraged 
> > by NETLMM and NEMO WG's.
> > 
> > captured in a common document. Defining multiple documents for this 
> > simple messaging is not a good idea, I hope we as a group will take 
> > the best decision on this, especially, as I just said that there is 
> > already a precedent in the case of DS-MIPv6 draft.
> > 
> >> IPv6 mobility by continuing work on developments that are required 
> >> for wide-scale deployments.
> >> "
> >> 
> >> perspective, this I-D oversteps the boundaries of MIP6 and is 
> >> treading in Netlmm waters.
> revocation work 
> >> in the case of PMIP6 would have to be done in Netlmm.
> >> 
> >> -Raj
> >>  
> >> 
> >>

---

From: Brian Haley <[email-masked]>
Date: Wed, 29 Aug 2007 16:24:05 -0400

Hi Vijay,

> to include a sub-type. I guess that is the current assumption.

I am in the process of doing these changes, I'm just incorporating some 
feedback now.

As far as consensus, I sent email to the list back on 6/4 and had very 
little feedback.  In short, there were only two "votes":

Ryuji: Yes
Vijay: No

Since the three authors (Sri, Ahmad and myself) came to agreement on the 
changes I'm going to make them.  If the WG doesn't like them when it's 
posted I'll be happy to revisit them to make everyone happy, but 
supporting the revocation work with the mechanism was a driver for the 
changes.

-Brian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 29 Aug 2007 15:48:12 -0500

Hi Brian,

Thanks for making the changes. 
I may also add that I presented the revocation draft during Chicago IETF
MIP6 meeting using the same format that we agreed on and you proposed on
the mailing list on 6/4 and there was no objection to the proposed
format.

Regards,
Ahmad

> From: Brian Haley [mailto:[email-masked]] 
> Sent: Wednesday, August 29, 2007 4:24 PM
> To: Vijay Devarapalli
> Cc: Gopal Dommety; Mobile IPv6 Mailing List
> > on changing the format of the generic mobility header signaling 
> > message to include a sub-type. I guess that is the current 
> assumption.
> 
> I am in the process of doing these changes, I'm just 
> incorporating some feedback now.
> 
> As far as consensus, I sent email to the list back on 6/4 and 
> had very little feedback.  In short, there were only two "votes":
> 
> Ryuji: Yes
> Vijay: No
> 
> Since the three authors (Sri, Ahmad and myself) came to 
> agreement on the changes I'm going to make them.  If the WG 
> doesn't like them when it's posted I'll be happy to revisit 
> them to make everyone happy, but supporting the revocation 
> work with the mechanism was a driver for the changes.
> 
> -Brian
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 29 Aug 2007 14:16:30 -0700

Brian,

The Mobility Header signaling message is still an individual draft. The 
authors are free to make any changes they want to the document. I know 
there was a consensus call run to adopt this draft as a WG document, but 
the one presented to the WG was the one with previous format. Not the 
new one.

Vijay

Brian Haley wrote:
>> message to include a sub-type. I guess that is the current assumption.
>

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 30 Aug 2007 02:59:32 -0700

Hi Sri,

> the signaling has to be based on MIP6 signaling.

HA rebooting/maintenance was one of the motivations to define the HA
switch message as explained in section 2.3 of
draft-ietf-mip6-ha-switch-03.txt
I think the operator will switch the user to another HA in case of
reboot of HA and prefer not to break the mobility service. 

Therefore I don't think this is a valid use case for this draft. 

> signaling and let AAA notify both HA and MN to setup the

Again, can you clarify the different use cases for the HA switch message
and the revocation message? 

Sorry, I may be missing something as I did not attend the Chicago
presentation and proceedings are not available yet.

Thanks
Gerardo

> > > > >> Subject: RE: Need for revocation in MIP6 (RE: [Mip6]
Consensus
> > > > >>>> The MIP6 WG charter and scope is focused on extensions to
the

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 30 Aug 2007 05:32:23 -0500

Gerardo,

Please visit the below link for binding revocation presentation and the
minutes was provided sometime back on the mailing list.

Regards,
Ahmad

> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2007 6:00 AM
> To: Sri Gundavelli; Narayanan, Vidya; Basavaraj Patil; 
> Muhanna, Ahmad (RICH1:2H10); Mobile IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> > HA reboot is not a policy event. HA is rebooting, it wants 
> to send a 
> > graceful event to the mobile. I dont see why AAA function should be 
> > involved here. This is one usecase. Again, 3775 does not assume AAA 
> > entity in the mobility infrastructure and so the signaling 
> has to be 
> > based on MIP6 signaling.
> > 
> 
> HA rebooting/maintenance was one of the motivations to define 
> the HA switch message as explained in section 2.3 of 
> draft-ietf-mip6-ha-switch-03.txt I think the operator will 
> switch the user to another HA in case of reboot of HA and 
> prefer not to break the mobility service. 
> 
> some policy 
> > aspect. So, it is possible to get rid of MIP6 signaling and let AAA 
> > notify both HA and MN to setup the binding state.
> > 
> 
> Again, can you clarify the different use cases for the HA 
> switch message and the revocation message? 
> 
> Sorry, I may be missing something as I did not attend the 
> Chicago presentation and proceedings are not available yet.
> 
> Thanks
> Gerardo
> 
> > > Doing "HA switch" or "Notifications" or "HA Reliability" via AAA 
> > > doesn't make sense - those are functions of MIP6.  
> Revocation is a 
> > > policy thing and is associated with AAA or an equivalent 
> entity (HSS 
> > > or whatever other entity).  I don't believe we are making 
> the right 
> > > comparisons here.
> > >
> > > cleaning up MAG resources upon revocation of the MN.  For 
> NEMO, MIP6 
> > > or MONAMI6, I don't see the point.  And, I particularly 
> don't want 
> > > to discuss the NETLMM need here at this time, since we 
> haven't yet 
> > > discussed it in the NETLMM WG.  For the purpose of MEXT, I'm not 
> > > seeing the practical need for revocation.
> > >
> > > Vidya
> > >
> > > > To: 'Basavaraj Patil'; Narayanan, Vidya; 'Ahmad 
> Muhanna'; 'Mobile 
> > > > IPv6 Mailing List'; 'Jonne Soininen'
> > > > Cc: 'Gopal Dommety'
> > > > We cannot just assume AAA to be deployed in the network 
> and assume 
> > > > the entire revocation to be activated and managed through AAA. 
> > > > Pretty much all the specs, including "HA Switchover", 
> > > > achieved through AAA. What we need is a mobility messaging and 
> > > > with no assumption on the presence of AAA. 3775 does not assume 
> > > > AAA on the network either. AAA is not mandataroy for 
> mobility to 
> > > > be achieved.
> > > > Now, if the case where AAA interface is not present, if 
> HA wants 
> > > > to revoke the mobile node's binding, it needs a mechanism to 
> > > > notify the mobile node and the spec defines the signaling for 
> > > > that.
> > > >
> > > > Regarding the scope of the work, we cannot expect every 
> WG to go 
> > > > and define the same protocol, changing the entity names and by 
> > > > defining a new usecase. If some one goes and defines Revocation 
> > > > for PMIP6, the work is not going to be vastly 
> different. Its the 
> > > > same messaging and with a different title.
> > > > If we look at this work in the sense of project 
> management, this 
> > > > work should be done once and leveraged by other WG's 
> (That's been 
> > > > Jari's position regarding leveraging work).
> different 
> > > > places. That really helped and in the same way, this 
> work should 
> > > > be done just in the base MIP6 group and be leveraged by other 
> > > > WG's. Hope, this work will be adopted as a joint WG item across 
> > > > NEMO, MIP6, NETLMM and MONAMI6.
> > > >
> > > > Sri
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > >>> resources at the mobility agents (FA/HA).  The 
> philosphy of
> > > > > >> revocation

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 30 Aug 2007 05:44:12 -0500

> 
> 
> I'll make a final point and stop here.  Most managed networks 
> that are considering the use of MIP6 today allow a mix of 
> MIP6 and non-MIP6 capable nodes to exist on the network.  A 
> mechanism of revoking access is needed for both MIP6 and 
> non-MIP6 capable endpoints and they don't need to be different.  
> 
> When the NAS receives a disconnect, it stops accepting 
> packets sourced from that IP address (the CoA, in the MIP6 
> case) and also won't forward anything to that IP address - 
> surely, we are not saying that the NAS understand MIP6 
> signaling and forward that alone on to the MN.  Good mobile 
> implementations should automatically blow any state 
> associated with that IP address (including MIP6 state), when 
> access is revoked.

[Ahmad]
Hmmm It is scary. I did not know that even Good MIP6 enabled MN is
getting into the blow up business:-)
But do you still qualify that smart implementation as graceful?
  
> if there 
> > is a graceful mechanism to indicate to the MN that it is being 
> > disconnected. Of course there are many different ways to 
> indicate that 
> > the MN has been disconnected from the network and these 
> could also be 
> > access technology dependent.
> > However if there is no good way to indicate to the MN that 
> it has been 
> > disconnected, the MN would continue to believe that it 
> still has MIP6 
> > binding and subsequently may cause a delay in creating a 
> binding with 
> > the HA when the MN does attach (for example via another 
> access type). 
> > So I think it would still make sense to indicate to the MN 
> that the HA 
> > has revoked the binding.
> Disconnect to 
> > the NAS and the indication to the HA to ensure that the MN can be 
> > notified of the binding revocation prior to pulling the plug at the 
> > NAS. But I think this can be dealt with.
> > 
> > -Raj
> > 
> > 
> > > MIP6 - the MN has likely had its access revoked before 
> the HA sends 
> > > the
> > > MIP6 revocation out.
> > > 
> > > Vidya
> > >

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 30 Aug 2007 14:04:23 -0700

Hi Ahmad,

Thanks for the pointer. 

I went through the slides and still I partially miss the motivations of
this work for MIPv6. In slide 3 the following motivations are mentioned:
- Home Agent Revokes Mobile Node's binding for Administrative Reasons
- Network Resource Optimization
- Gracefully Revoke multiple sessions before scheduled or emergency
system maintenance
- Avoid out of sync state between MN and mobility entities
In slide 4 two scenarios are mentioned, but these are technical
scenarios rather than use cases. 

Looking at the HA switch I-D, in section 2 there are the use cases
listed:
- overloaded HA
- (functional) load balancing
- maintenance
- HA renumbering

It seems to me that the motivations and use cases are definitely
overlapping. So which are the reasons we should define yet another
mechanism in MIP6?

Thanks
Gerardo

> Sent: Thursday, August 30, 2007 12:32 PM
> To: Giaretta, Gerardo; Sri Gundavelli; Narayanan, Vidya; Basavaraj
Patil;
> Mobile IPv6 Mailing List; Jonne Soininen
> Cc: Gopal Dommety
> call:AdoptingI-D)
> > > > > > >> an extension of MIPv6 protocol. Since one simple
mechanism
> > can
> > > > > > >>>> (RFC3775) and issues related to base MIP6. From a
charter
> > > > > > >> and scope
> > > > > > >>>> MIP6 WG I-D/feature, the PMIP6 aspects in this I-D
would
> > > > > > >> have to be