Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

From: Qin Wu <[email-masked]>
Date: Mon, 02 Mar 2009 16:20:08 +0800

Hi,Ahmad:
please see inline.
----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 01, 2009 7:12 AM
Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

Hi, Qin,
Please see inline.

>  
> 
> [Ahmad]
> I am not sure if we can achieve everything in the revocation by using
> de-registration. BRI gives more information than what can be 
> carried in
> de-registration. Please remember, MAG can send a BRI in the case of
> multiple bindings revocation already. Is what you are saying: 
> we need to
> specify how BRI can be used for revocation from the MAG in all cases?
> If not and you are interested in PBU as a de-registration, 
> then probably
> what in PMIP6 is good enough.
> [Qin]Since the MAG can send BRI instead of PBU, may I suggest 
> to specify how BRI can be used for revocation from the MAG?

[Ahmad]
Personally, I believe that is a good idea. Especially, the MAG already
uses BRI to send a Global BRI. However, if I recall, there was some
opposition to this early on and that why we did not include it.

In order to add this to the draft, we need enough people to support that
on the ml.
 [Qin]: In mip4 scenario, binding revocation could be supported from fa to ha, or by generic notifcation draft. Am I right?
So I would like to support extending MAG to send BRI message for binding revocation in pmip6 scenario.
Also I wonder whether  MN sending BRI message for binding revocation is allowed in the draft-mext -binding-revocation-03.

> Regards,
> Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 2 Mar 2009 07:03:52 -0600

Hi Qin,

>  [Qin]: In mip4 scenario, binding revocation could be 
> supported from fa to ha, or by generic notifcation draft. Am I right?

[Ahmad]
This comparison is NOT valid here. Just as a note, generic notification
message is NOT used for revocation.

> So I would like to support extending MAG to send BRI message 
> for binding revocation in pmip6 scenario.
[Ahmad]
As I said, that need support of the wg before adding it.

> Also I wonder whether  MN sending BRI message for binding 
> revocation is allowed in the draft-mext -binding-revocation-03.
> 
> 
> > Regards,
> > Ahmad
> >
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 04 Mar 2009 16:16:40 -0800

Hello,

Qin Wu wrote:

> de-registration. BRI gives more information than what can be carried in
> multiple bindings revocation already. Is what you are saying: we need to
> If not and you are interested in PBU as a de-registration, then probably
> [Qin]Since the MAG can send BRI instead of PBU, may I suggest to specify how BRI can be used for revocation from the MAG?

We should not have two mechanisms to delete a particular mobile node's 
binding. The MAG can just use a de-registration PBU (lifetime set to 0) 
to delete the binding. There is no need for another mechanism using  the 
binding revocation message.

Vijay

---

From: Qin Wu <[email-masked]>
Date: Thu, 05 Mar 2009 11:06:03 +0800

Hi,Vijay:
See inline.
----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Ahmad Muhanna" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 05, 2009 8:16 AM
Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

> binding revocation message.
[Qin] I agree the de-registration PBU can be used to delete the binding of mobile node. However it is not enough to describe binding revocation mechanism. 
First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration.
Second in the bas PMIP6 protocol(RFC5213),  it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation.
Third  De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all the other reason for binding revocation as decribed as revocation trigger in section 6.1 of draft--ietf-mext-binding-revocation-03.txt.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 4 Mar 2009 20:12:37 -0800 (PST)

Hi Qin,

> Third  De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all…

The question would be, does the LMA need to distinguish between the
two:

- A dereg message from the MAG, when the mobile node is no longer attached
   to the access network
- An explicit revocation by sending a BRI for administrative reasons

The later message clearly provides the revocation intent, which a dereg
message cannot provide. If we need the LMA to differentiate between these
two, we need to allow the BRI message for a session termination. But, I'm
not sure if the reason for service termination is required in 3GPP or in
some other architectures. There seems to be a reason code, but, I'm not
sure how that is carried, if its carried in a simple dereg would be good
enough, or we need this message.

Secondly, we are clearly allowing the BRI message to be used by the MAG
for bulk termination, if so, allowing the same for a single session would
be fine as well. The messaging will be consistent.

But, there is also a valid point, why two messages for the same purpose ?
If we dont need this, we can as well eliminate this message.

So, bottom line, does the LMA needs to know the revocation intent ?

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 5 Mar 2009 00:32:29 -0600

Hi All,

> >> We should not have two mechanisms to delete a particular mobile 
> >> node's binding. The MAG can just use a de-registration PBU 
> (lifetime 
> >> set to 0) to delete the binding. There is no need for another 
> >> mechanism using  the binding revocation message.
> > [Qin] I agree the de-registration PBU can be used to delete 
> the binding of mobile node. However it is not enough to 
> describe binding revocation mechanism.
> > First of all, the de-registration PBU initiated by the MAG 
> falls short when it comes to Bulk deregistration.
> > Second in the bas PMIP6 protocol(RFC5213),  it does not 
> specifiy any mechanism for binding revocation. As Ahmad 
> already said, de-registation is totally different from 
> binding revocation.
> > Third  De-registation PBU is normally used when the mobile 
> node goes back to the home network or when the MAG detect the 
> mobile node detached from the access link. However it does 
> not summarize all the other reason for binding revocation as 
> decribed as revocation trigger in section 6.1 of 
> draft--ietf-mext-binding-revocation-03.txt.
> >
> 

[Ahmad]
Although de-registration can be used in PMIPv6, but the real intention
of de-registration is suited for Client MIP6 where the message is coming
from the client itself all the way to its home agent. When the client
request de-registration there is Nothing else the HA needs to know,
i.e., the client is requesting the termination of its mobility session.

In PMIPv6, there is a proxy agent which sends a PBU with lifetime=0 on
behalf of the mobile node. Of course, the LMA needs to know why the
Proxy agent is sending this de-registration. Currently, this is NOT
available to the proxy agent if de-registration is used and consequently
a richer mechanism is needed. IMO, we have two options:

1. define a new option which carries the cause of the session
termination which is strictly applicable to PMIPv6.

- OR - 

2. Use BRI message which the Proxy Agent already supports to communicate
the termination reason behind the proxy termination.

Due to inflation, I would call this My 2.5 cents:)

Cheers!

> The later message clearly provides the revocation intent, 
> which a dereg message cannot provide. If we need the LMA to 
> differentiate between these two, we need to allow the BRI 
> message for a session termination. But, I'm not sure if the 
> reason for service termination is required in 3GPP or in some 
> other architectures. There seems to be a reason code, but, 
> I'm not sure how that is carried, if its carried in a simple 
> dereg would be good enough, or we need this message.
> 
> Secondly, we are clearly allowing the BRI message to be used 
> by the MAG for bulk termination, if so, allowing the same for 
> a single session would be fine as well. The messaging will be 
> consistent.
> 
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 05 Mar 2009 15:01:29 +0800

Hi,Sri:
Thanks for your concern, Please see inline.
----- Original Message ----- 
From: "Sri Gundavelli" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Vijay Devarapalli" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 05, 2009 12:12 PM
Subject: Re: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

> - An explicit revocation by sending a BRI for administrative reasons

[Qin] Good question, I agree a de-reg message can achieve the same effect as an explicit revocation by sending a BRI, i..e., delete the mobile node's binding or resource release.
However  as you mentioned above, BRI message is defined for  adminitrative reasons while the dereg message is defined for detachment of mobile node.
I wonder whether the dereg message has the same purpose as BRI message?

> enough, or we need this message.

[Qin] You get to the point. It seems the difference between the BRI and dereg is whether they carry the revocation intent.
However the specific scenario the BRI is applicable to is quite different from deregistration. e.g., There are two case for deregistration, one case is when the mobile node goes back to the home network, the MAG should send deregistration on behalf of it. The other case is when the mobile detaches from the access link,  the MAG also need to send deregistation as described in RFC5213, so the question is how the LMA distinguish between two cases, Is it necessary for the LMA to distinguish these two cases? Besides this, there are many other reasons for the MAG sending deregistration. 
>From another perspective, I think these revocation intents are quite useful for mobility service managment and failure detection and position.

> be fine as well. The messaging will be consistent.
[Qin] It can does not mean it has specified in the RFC5213. If my memory is correct, the base PMIP6 protocol does not support bulk termination.
And besides bulk termination, the base PMIP6 does not support multiple-CoA binding termination. Am I right?
> If we dont need this, we can as well eliminate this message.

[Qin] Not quite simple for the same purpose. Anyhow, I have no objection if the base PMIP6 protocol can support carrying revocation intents.

> So, bottom line, does the LMA needs to know the revocation intent ?
[Qin] See above.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 05 Mar 2009 11:05:26 -0800

Hi.

> First of all, the de-registration PBU initiated by the MAG falls short when it comes to Bulk deregistration.

The current binding revocation draft allows the use of BRI if a MAG 
wants to delete the mobility sessions for a number of nodes. So this is 
already there in the document.

> Second in the bas PMIP6 protocol(RFC5213),  it does not specifiy any mechanism for binding revocation. As Ahmad already said, de-registation is totally different from binding revocation.

This doesn't make sense to me. RFC 5213 of course does not talk about 
binding revocation. We have a separate draft for that.

> Third  De-registation PBU is normally used when the mobile node goes back to the home network or when the MAG detect the mobile node detached from the access link. However it does not summarize all…

Why? The MAG can just send a PBU with lifetime set to 0.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 5 Mar 2009 14:08:22 -0500

Ahmad, Sri,

You guys are talking about solutions for conveying the reason for which
the MAG is  deleting the binding. You are not talking about why this is
required. :)

It's the MAG that created the binding with a PBU. It can use a PBU with
lifetime set to 0 to delete the binding. So why do you need another
mechanism to do the same?

Vijay 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ahmad Muhanna
> Sent: Wednesday, March 04, 2009 10:32 PM
> To: Sri Gundavelli; Qin Wu
> Cc: [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 6 Mar 2009 09:16:59 -0600

Hi Vijay,

That is very good. 
At least we agree that de-registration (PBU with lifetime=0) currently
does not have a mechanism to communicate the cause of the session
termination which is NOT required in the case of Client MIP6 (it is
always user initiated) but is needed in the case of PMIP6.

To address the question: why the cause of the session termination is
needed at the LMA?, I would like to say the following: The current
Binding Revocation draft has the following Revocation Trigger values:

	    8  User Initiated Session(s) Termination
          9  Access Network Session(s) Termination
          250-255 Reserved For Testing Purposes only 

IMO, these values make a lot of sense. Because, User Initiated Session
Termination is different than Access Network Session Termination. In the
first one, when the LMA receives a signal to indicate termination
initiated by the user, that could be helpful to the LMA to at least make
a note that the session was terminated based on the consensus of the end
user. 

When the termination signal (PBU with mobility option Termination cause
or BRI) indicates access termination, there is many possibilities which
could have triggered that kind of termination and that could help the
LMA to know many things: for example, what kind of service the access
provider offer the home provider's customers. In other case, if all of
these session very frequently is terminated by the access network, it
could be a reason that the end user is NOT receiving a good service,
etc.

Another thing, the values which are reserved for testing purposes, are
reserved for a purpose and could be used in this case.

Finally, when billing record is captured/collected and reported by the
LMA, reporting the session termination cause is very useful.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Thursday, March 05, 2009 1:08 PM
> To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli; Qin Wu
> Cc: [email-masked]
> You guys are talking about solutions for conveying the reason 
> for which the MAG is  deleting the binding. You are not 
> talking about why this is required. :)
> 
> It's the MAG that created the binding with a PBU. It can use 
> a PBU with lifetime set to 0 to delete the binding. So why do 
> you need another mechanism to do the same?
> 
> Vijay 
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Ahmad Muhanna
> > > the binding of mobile node. However it is not enough to describe 
> > > binding revocation mechanism.
> > > specifiy any mechanism for binding revocation. As Ahmad already 
> > > said, de-registation is totally different from binding revocation.
> > > node goes back to the home network or when the MAG detect 
> the mobile 
> > > node detached from the access link. However it does not summarize 
> > > all the other reason for binding revocation as decribed as 
> > > revocation trigger in section 6.1 of 
> > of de-registration is suited for Client MIP6 where the message is 
> > coming from the client itself all the way to its home 
> agent. When the 
> > client request de-registration there is Nothing else the HA 
> needs to 
> > know, i.e., the client is requesting the termination of its 
> mobility 
> > session.
> > 
> > available to the proxy agent if de-registration is used and 
> > consequently a richer mechanism is needed. IMO, we have two options:
> > 
> > 2. Use BRI message which the Proxy Agent already supports to 
> > communicate the termination reason behind the proxy termination.
> > 
> > > The later message clearly provides the revocation intent, which a 
> > > dereg message cannot provide. If we need the LMA to differentiate 
> > > between these two, we need to allow the BRI message for a session 
> > > termination. But, I'm not sure if the reason for service 
> termination 
> > > is required in 3GPP or in some other architectures. There 
> seems to 
> > > be a reason code, but, I'm not sure how that is carried, if its 
> > > carried in a simple dereg would be good enough, or we need this 
> > > message.
> > > 
> > > Secondly, we are clearly allowing the BRI message to be 
> used by the 
> > > MAG for bulk termination, if so, allowing the same for a single 
> > > session would be fine as well. The messaging will be consistent.
> > >

---

From: Qin Wu <[email-masked]>
Date: Mon, 09 Mar 2009 13:42:01 +0800

Hi, All:
I agree with Ahmad's point.
----- Original Message ----- 
From: "Ahmad Muhanna" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>; "Sri Gundavelli" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 06, 2009 11:16 PM
Subject: RE: [MEXT] Comments on draft-ietf-mext-binding-revocation-03

Hi Vijay,

That is very good. 

Regards,
Ahmad

---

From: Joel Hortelius <[email-masked]>
Date: Mon, 09 Mar 2009 14:05:56 +0000

A question regarding revocation;

The LMA may receive a request with the 'G' bit cleared, and information
that identifies multiple BCE's (multiple HNPs provided in the BRI). In
that scenario, the LMA revokes all bindings, and if one HNP is not
found, it will respond with a partial success and provide the HNP that
was not found.

In the MAG, there's no section that states the same, but the BRA section
indicates that its valid? with its "partial success" scenario? The MAG
does seem to act differently with regards to different triggers. What if
a BRI is received which identifies multiple BCEs, using a trigger such
as "unknown handoff", and one or more of the BCE's are deemed "still
attached"? Is that a partial success scenario? The BRA section specifies
that partial success only should be used if a BCE that has been
requested to be revoked is already released? Should the inter-mag
triggers require to only match a single node, like setting the 'V' flag
implicitly does?

Can all triggers be used with 'G', or only those that are specified?
What action should be taken if one receives a 'G' with a trigger such as
"v4 lease expired"? Ignore it, or send an error?

Basically, since some triggers require specific actions, I'm a bit
confused regarding the combinations. What if a future trigger appears
that requires another specific action, which is unknown to the current
implementation? 

Regards,
Joel Hortelius

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2009 14:55:49 +0800

Hi,Joel and Ahmad:
Good question,that's what I want to ask in the initial discussion as regarding "partial success" scenario.
I think the MAG also requires 'G'bit in the BRI/BRA to deal with partly terminating all the mobility bindings
Also the MAG need to consider how to deal with terminating some part of all the mobility bindings in the Proxy MIP6 use case.
Just as Joel said, it is quit possbile for the Mobile device attaches to multiple access links simultanesouly and allow the MAG terminating one or part of all the mobility bindings.
Also in some scenarios where the IPv4 and PMIP6 coexist, the MAG or LMA need to consider terminating all/part of the IPv4 mobility bindings and keep all/part of the IPv6 mobility bindings. Is that a partial success scenario? what we should do?

Best regards!
-Qin

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 13 Mar 2009 11:51:21 -0500

Hi Joel,
Sorry for not responding earlier, somehow I did not see your email
earlier:( 
I assume that you will be okay if I reply back to your follow-up email;
which have more points to address.

Regards,
Ahmad

> From: Joel Hortelius [mailto:[email-masked]] 
> Sent: Monday, March 09, 2009 9:06 AM
> To: Qin Wu
> Cc: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Sri 
> Gundavelli; [email-masked]
> The LMA may receive a request with the 'G' bit cleared, and 
> information that identifies multiple BCE's (multiple HNPs 
> provided in the BRI). In that scenario, the LMA revokes all 
> bindings, and if one HNP is not found, it will respond with a 
> partial success and provide the HNP that was not found.
> 
> In the MAG, there's no section that states the same, but the 
> BRA section indicates that its valid? with its "partial 
> success" scenario? The MAG does seem to act differently with 
> regards to different triggers. What if a BRI is received 
> which identifies multiple BCEs, using a trigger such as 
> "unknown handoff", and one or more of the BCE's are deemed 
> "still attached"? Is that a partial success scenario? The BRA 
> section specifies that partial success only should be used if 
> a BCE that has been requested to be revoked is already 
> released? Should the inter-mag triggers require to only match 
> a single node, like setting the 'V' flag implicitly does?
> 
> Basically, since some triggers require specific actions, I'm 
> a bit confused regarding the combinations. What if a future 
> trigger appears that requires another specific action, which 
> is unknown to the current implementation? 
> 
> Regards,
> Joel Hortelius
> 
> 
> 
> 
>