[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
Hi, Ahmad:
Please see the followup comments.
-Qin
----- Original Message -----
From: "Ahmad Muhanna" <amuhanna at nortel.com>
To: "Qin Wu" <sunseawq at huawei.com>; "Joel Hortelius" <joel.hortelius at interpeak.se>
Cc: <netlmm at ietf.org>; "mext" <mext at ietf.org>
Sent: Monday, March 16, 2009 2:46 PM
Subject: RE: [MEXT] Review of draft-ietf-mext-binding-revocation-03.txt
Hi, Qin,
> draft-ietf-mext-binding-revocation-03.txt
>
> Hello,
> >> 2; What combinations are possible? What triggers may be
> used with the
> >> 'G' bit? Some triggers have been indicated that they
> should be used
> >> with 'G', but others do not. Some combinations do not make sense.
> >> Does 'G'
> >> ONLY work with those explicitly specified? If so, what
> should one do
> >> with the other combinations if they appear?
> >
> > [Ahmad]
> > Yes, Global Revocation is meant to communicate a Mass
> revocation which
> >impact all mobility sessions between the pair MAG-LMA.
> Another use case
> >was discussed to allow the LMA, for example, to revoke multiple
> >sessions that belong to all MN(s) which share a specific criteria,
> >e.g., MN-ID belong to a certain realm. The receiving node
> need to be
> >able to differentiate between the two cases. Thus, there was two
> >different Revocation Triggers.
> >Any other combinations of (G) bit and other R. T. is NOT supported.
> >IMO, the receiving node should reject that BRI.
> >We can add text for this one.
>
> Sound good to me, But I wonder whether multiple sessions
> reovocation for Proxy MIPv6 use case is covered in the draft?
> Because in the section 3.4.2, only global revocation is covered.
[Ahmad]
It is covered.
If the (G) bit is set and the R. T. is set to "Revoking Node Local
Policy", then you need to include more information that are common to
all BCE, for example: you could send the MN-ID to "* at abcde.com". This
means that the sending node is requesting that all BCE with the MN-ID
that match the MN-ID above should be revoked.
Here is the related text:
1. under section 6.1:
Global (G)
The Global (G) bit is set by the sending mobility node, LMA or
MAG, to request the termination of all Per-Peer mobility Bindings
or Multiple Bindings which share a common identifier that are
served by the sending and receiving mobility entities as in
Section 9.1.1 and Section 10.2.1.
[Qin]: Just As you said, the multiple bindings revocation has already been included in the definition of Global(G).
However the multiple bindings revocation is quite different from multiple per-peer bindings revocation what I understand. Let me give you one exmaple on multiple per-peer bindings revocation.
One mobile device owning three interfaces which share the same NAI registers to the same LMA, if the LMA want to revoke two per-Peer bindings associated with two interfaces of the mobile devices.What should the LMA do using bulk PMIP6 binding revocation?
I wonder whether this example can be viewed as multiple bindings revocation and whether this use case should be considered in this binding revocation draft.
2. Under section 9.1.1:
When the LMA needs to revoke all mobile nodes proxy BCE that belong
to a specific realm, e.g. @companyabc.com, and are registered with
the LMA and hosted at the MAG, the local mobility anchor MUST set the
Global (G) bit and the value of the Revocation Trigger field to
"Revoking Node Local Policy". In this case, the local mobility
anchor MUST include a mobility option to identify the impacted
bindings, e.g. MN-ID option with a wildcard NAI, e.g.
* at companyabc.com, to identify all the mobile nodes BCEs that need to
be removed.
[Qin] If all mobile nodes BCEs belong to the same specific realm and are hosted at the different MAGs which register to the same LMA,
what should this LMA do using multiple bindings revocation mechanism? It seems multiple BRA messages to the different MAG are required.
>
> Regards!
> -Qin
>