Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus call:AdoptingI-D)

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 4 Sep 2007 12:04:25 -0500

Hi Gerardo,
Sorry for the late reply.
Please see comment inline.

Regards,
Ahmad

> Subject: RE: Need for revocation in MIP6 (RE: [Mip6] 
> Consensus call:AdoptingI-D)
> 
> 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

[Ahmad]
Well, none of the listed above addresses the revocation of MIPv6
service. In other words, the user is authorized to receive an IPv6
mobility service that could be revoked for admin reasons. IMO, it is
more than "nice" but probably required for the Home domain to inform the
user "MN" that its MIPv6 service has been revoked in order for the MN to
release all state machine gracefully.

The fact that MIPv6 service is revoked, does not mean that Simple IPv6
service is not available. Right?
In that case, the MN can make an educated decision, for example,
initiates a simple IPv6 session and live without mobility.

Finally, I believe that Binding revocation is not in contradiction with
the HA switch I-D at all. HA switch I-D addresses the operational
administrative use cases while Binding revocation addresses the Mobility
service authorization aspect of the administrative domain use cases.

Best Regards,
Ahmad

> 
> 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
> 
> > -----Original Message-----
> > From: Ahmad Muhanna [mailto:[email-masked]]
> > 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
> > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus
> > call:AdoptingI-D)
> > 
> > Gerardo,
> > 
> > Please visit the below link for binding revocation presentation and
> the
> > minutes was provided sometime back on the mailing list.
> > 
> > http://www3.ietf.org/proceedings/07jul/slides/mip6-3/sld1.htm
> > 
> > 
> > Regards,
> > Ahmad
> > 
> > 
> > > -----Original Message-----
> > > 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
> > > Subject: RE: Need for revocation in MIP6 (RE: [Mip6] Consensus 
> > > call:AdoptingI-D)
> > >
> > > Hi Sri,
> > >
> > > >
> > > > 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.
> > >
> > > Therefore I don't think this is a valid use case for this draft.
> > >
> > > > 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.
> > > >
> > >
> > > 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
> > >
> > > > Sure, no need to bring NETLMM usecases for this discussion.
> > > >
> > > > Sri
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Narayanan, Vidya [mailto:[email-masked]]
> > > > > Sent: Wednesday, August 29, 2007 11:08 AM
> > > > > To: Sri Gundavelli; Basavaraj Patil; 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)
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > > > -----Original Message-----
> > > > > > 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'
> > > > > > Subject: RE: Need for revocation in MIP6 (RE: 
> [Mip6] Consensus 
> > > > > > call:Adopting I-D)
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Basavaraj Patil [mailto:[email-masked]]
> > > > > > > Sent: Wednesday, August 29, 2007 9:56 AM
> > > > > > > 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
> > > > > > >
> > > > > > >
> > > > > > > On 8/29/07 12:53 AM, "ext Narayanan, Vidya"
> > > > > > > <[email-masked]> wrote:
> > > > > > >
> > > > > > > > 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
> > > > > > > >
> > > > > > > >> -----Original Message-----
> > > > > > > >> 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
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>> -----Original Message-----
> > > > > > > >>> From: Narayanan, Vidya [mailto:[email-masked]]
> > > > > > > >>> 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
> > > > > > > >>>
> > > > > > > >>>> -----Original Message-----
> > > > > > > >>>> From: Basavaraj Patil 
> [mailto:[email-masked]]
> > > > > > > >>>> Sent: Tuesday, August 28, 2007 9:25 AM
> > > > > > > >>>> To: Narayanan, Vidya; Mobile IPv6 Mailing List;
> > > > > Jonne Soininen
> > > > > > > >>>> Cc: Gopal Dommety
> > > > > > > >>>> Subject: Re: [Mip6] Consensus call: Adopting I-D
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> 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
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>> On 8/27/07 8:13 PM, "ext Narayanan, Vidya"
> > > > > > > >>>> <[email-masked]> wrote:
> > > > > > > >>>>
> > > > > > > >>>>> A meta question concerning this draft - how does it
> fit
> > > > > > > >> into the
> > > > > > > >>>>> current
> > > > > > > >>>>> MIP6 or proposed MEXT charter?
> > > > > > > >>>>>
> > > > > > > >>>>> Thanks,
> > > > > > > >>>>> 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.
> > > > > > > >>>>>>
> > > > > > > >>>>>> 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
> > > > > > > >>>>>>
> > > > > > > >>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>> _______________________________________________
> > > > > > > >>> Mip6 mailing list
> > > > > > > >>> [email-masked]
> > > > > > > >>> https://www1.ietf.org/mailman/listinfo/mip6
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Mip6 mailing list
> > > > > > > [email-masked]
> > > > > > > https://www1.ietf.org/mailman/listinfo/mip6
> > > > > >
> > > >
> > > > _______________________________________________
> > > > Mip6 mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mip6
> > >
> 

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

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 5 Sep 2007 04:07:31 -0700

Hi Ahmad,

See inline please...

> release all state machine gracefully.

I listed the use cases above as some of them were mentioned by others
during the discussion. 

I am still not sure it is required that a revocation must be explicitly
signaled to the MN. Moreover, if this is really something needed, the HA
switch message can be used. Based on the HA switch draft, after
receiving the HA switch message the MN must stop using the HA. If the HA
switch message does not contain any HA address, the MN can interpret
this message as a revocation. We may add a flag to make it explicit, but
I see a lot of commonalities in the two messages and I would avoid
specifying both. 

> service authorization aspect of the administrative domain use cases.

It's not in contradiction. The point is that I am not sure we need two
different mechanisms for these two use cases. 

And I think the requirement on gracefulness is not very clear. I can
definitely think of some use cases where revocation is needed in NETLMM
and probably also in MONAMI6, but not for MIP6. Therefore I would prefer
to take this discussion on adopting the I-D in the respective WGs where
the use cases are clearer, either MONAMI6 or NETLMM or MEXT (if Jari
thinks this can be included in the MEXT charter).

Thanks
Gerardo

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 5 Sep 2007 17:01:37 -0500

Hi Gerardo,
Please see inline.

Regards,
Ahmad

> > user "MN" that its MIPv6 service has been revoked in order 
> for the MN
> to
> I listed the use cases above as some of them were mentioned 
> by others during the discussion. 
> 
> I am still not sure it is required that a revocation must be 
> explicitly signaled to the MN. Moreover, if this is really 
> something needed, the HA switch message can be used. Based on 
> the HA switch draft, after receiving the HA switch message 
> the MN must stop using the HA. If the HA switch message does 
> not contain any HA address, the MN can interpret this message 
> as a revocation. We may add a flag to make it explicit, but I 
> see a lot of commonalities in the two messages and I would 
> avoid specifying both. 

[Ahmad]
As I mentioned before, HA switch message is not meant to be for
revocation. It is to inform the MN that it needs to look for another HA
to receive service. Revocation is to inform the MN that its MIPv6
authorization is no longer valid. Please take a look at the below
excerpts from the draft and then judge.

Also, the draft is already at the IESG desk, I am not sure why we need
to change the fundamental objective and the functionality of the draft
the last minute to make it fit for a something it is not meant for. Just
let me highlight one example of from the HA switch message draft:

"
If no alternate home agent addresses are included in the list, the
mobile node MUST first
perform home agent discovery.
"

Does that mean revocation?

More excerpts from HA switch message draft:
===========================================

1. up front from the abstract:
==============================

"
Abstract

   This document specifies a new Mobility Header message type that can
   be used between a home agent and mobile node to signal a mobile node
   that it should acquire a new home agent.
"

2. Some more, look into the Introduction:
=========================================
"
1. Introduction

   RFC 3775 [2] contains no provision to allow a home agent to inform a
   mobile node that it needs to stop acting as the home agent for the
   mobile node.  For example, a home agent may wish to handoff some of
   its mobile nodes to another home agent because it has become
   overloaded or it is going offline.

   This protocol describes a signaling message type that can be used to
   send a handoff notification between a home agent and mobile node.
"

3. The scenario identified as you mentioned above is as follows:
================================================================

2. Scenarios

   Here are some example scenarios where a home agent signaling message
   would be useful.

2.1 Overloaded

2.2 Load Balancing

2.3 Maintenance

2.4 Functional Load Balancing

2.5 Home Agent Renumbering

3. some more under section 3.0:
==============================

3. Home Agent Switch Message

   The Home Agent Switch message is used by the home agent to signal the
   mobile node that it needs to stop acting as the home agent for the
   mobile node, and that it should acquire a new home agent.  Home Agent
   Switch messages are sent as described in Section 4.

   The Home Agent Switch Message uses the MH Type value (TBD).  When
   this value is indicated in the MH Type field, the format of the
   Message Data field in the Mobility Header is as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |# of Addresses |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   .                                                               .
   .                      Home Agent Addresses                     .
   .                                                               .
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   # of Addresses
   --------------

     An 8-bit unsigned integer indicating the number of IPv6 home agent
     addresses in the message.  If set to zero, the mobile node MUST
     perform home agent discovery.

   Home Agent Addresses
   --------------------

     A list of alternate home agent addresses for the mobile node.  The
     number of addresses present in the list is indicated by the "# of
     Addresses" field in the Home Agent Switch message.

4. Under section 4:
===================

     o The "# of addresses" field MUST be filled-in corresponding to
        the number of home agent addresses included in the message.  If
        no addresses are present, the field MUST be set to zero, forcing
        the mobile node to perform home agent discovery by some other
        means.

If the HA addresses field is set to zero, the MN is forced to perform
home agent discovery!

5. some more about switch message:
==================================
                                       If no alternate home agent
   addresses are included in the list, the mobile node MUST first
   perform home agent discovery.

> It's not in contradiction. The point is that I am not sure we 
> need two different mechanisms for these two use cases. 
> 
> And I think the requirement on gracefulness is not very 
> clear. I can definitely think of some use cases where 
> revocation is needed in NETLMM and probably also in MONAMI6, 
> but not for MIP6. Therefore I would prefer to take this 
> discussion on adopting the I-D in the respective WGs where 
> the use cases are clearer, either MONAMI6 or NETLMM or MEXT 
> (if Jari thinks this can be included in the MEXT charter).

[Ahmad]
Revocation is common between MIP6, Netlmm, and Monami6. 
However, I do not think we are much a part with respect to IETF
procedures. If this draft is adopted as a MIP6 draft then it will be
addressed under MEXT wg. However, if it is adopted under MIP6 + Netlmm
wgs, then eventually will be under Netlmm + MEXT wgs, as you suggested.
(of course, as you mentioned, pending expanding MEXT charter upon the AD
approval)

> 
> Thanks
> Gerardo
> 
> > Best Regards,
> > Ahmad
> > 
> > >
> > > 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
> > >
> > > > > > > > > sending the Disconnect to the NAS. And this 
> would allow
> a
> > > > > > > graceful
> > > > > > > > > detach from the HA??
> > > > > > > > >
> > > > > > > > > -Raj
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >> MN probably can delete its binding with 
> other CN or,
> at
> > > > > least,
> > > > > > > > > >> that long time ago, early 2002, there has 
> been a lot
> of
> > > > > > > > discussion
> > > > > > > > > >> during
> > > > > > > > > >>> PMIPv6 - I'm trying to specifically 
> understand this
> in
> > > the
> > > > > > > > > >> context of
> > > > > > > > > >>> MIP6.
> > > > > > > > > >>>
> > > > > > > > > >>>> The primary goal of the MIP6 working 
> group will be
> to
> > > > > > > > > enhance base
> > > > > > > > > >>>>>> MIP6 deployments and hence should be 
> made a MIP6
> WG
> > > > > > > > > >> document and
> > > > > > > > > >>>>>> Mip6 mailing list [email-masked]