Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Queries/comments on 'Binding Revocation for IPv6 Mobility' draft
Hi Sandesh,
Thanks again. Please see inline.
Regards,
Ahmad
> Subject: [MEXT] Queries/comments on 'Binding Revocation for
> IPv6 Mobility' draft
>
> Hi,
>
> I was going through the draft
> draft-ietf-mext-binding-revocation-00.txt
> (http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00)
>
> I have following queries/comments -
>
>
> 1.-------------------------
> There should a provision to bring a binding administratively
> DOWN/UP revoke/unrevoke mechanism without deleing entry from
> in BUL/BC.
> Administrator (at LMA or MAG) can use this to prohibit a MN
> from using a PMIv6 for some time (without deleting entry from
> in BUL/BC).
> This provision can be useful during testing/maintenance.
[Ahmad]
If the MN needs to be revoked for sometime, why do we need to keep its
BCE. It seems to me that one of the most important functionality that
Binding Revocation is trying to do is to help mobility nodes clear
resources and avoid stale sessions. May be you can elaborate more to
understand what you are trying to do.
>
> 1.-------------------------
> If administrator at LMA revokes a binding (does a revoke
> administrative
> action) (I would call is bringing binding administratively
> down) in this case a BRI message is sent to MAG (and BRA
> received in return).
>
> If after some time the same administrator unrevokes the
> binding (i.e. and makes this binding administratively up)
[Ahmad]
What is your definition of this administrative up and administrative
down events.
When the MN Binding is revoked for administrative reason, the MN is no
longer allowed to receive mobility service. If that the case, then there
is no need to keep the BCE around.
>
> Option 1:
> In this case should there be message which LMA can send to
> MAG to indicate that MAG can send PBU to register the MN
> binding with LMA.
>
> OR
> Option 2:
> When binding is administratively down MAG keeps on
> transmitting PBU and LMA replies PBA with status =
> Administratively prohibited.
> MAG keeps on sending PBU until LMA responds with PBA (status = 0)
[Ahmad]
I seem to have difficulties with the logic here.
If the MN session is revoked for administrative reason, all resources
associated with the MN session are deleted.
If the MN tries to access the network again, the MN should not be
allowed to receive PMIPv6 mobility services unless the Mobile node is
authorized to receive PMIPv6 which is communicated to the MAG during
access authentication.
As per PMIPv6 base protocol, the MAG receives the MN profile and also if
the MN is allowed for PMIPv6 service or not. Therefore, both options
above are not applicable.
>
>
> 2.-------------------------
> IMHO this draft should include the changes for
> 'IPv4 Support for Proxy Mobile IPv6' also.
> i.e.
> In the sections related to MAG and LMA there should be
> mention of IPv4 home address also.
[Ahmad]
Okay. I will make sure that we mention the IPv4 address. Although, that
is independent of the BRI process. If a BCE is revoked all resources are
removed including the IPv4 Home address.
>
> 3.-------------------------
> Section 8.2.2. 4th bullet
> s/The local mobility MAY set/The local mobility anchor MAY set
[Ahmad]
Ok, thx.
>
> 4.-------------------------
> Section 8.2.2. 4th bullet
> It would be good if few cases of 'partial success' can be mentioned.
[Ahmad]
I believe the text is generic and applicable.
Do you have a case that is not addressed by the current text?
>
> 5.-------------------------
> Section 9.2.2
> It would be good if few guidelines can added for the case
> when MAG receives BRA (status = partial success)
[Ahmad]
Like what?
>
> 6.-------------------------
> As per section 9.2.1 MAG will always set A bit in BRI message
> which it sends to LMA Following lines gives an impression
> that that there may be some case in which MAG sends BRI
> without setting A bit.
> IMHO following line of section 3.1 should be modified to
> reflect the spirit of section 9.2.1.
> "If the local mobility anchor processes the BRI message
> successfully and the (A) bit is set in the BRI, the local
> mobility anchor responds to the mobile access gateway by
> sending a BRA message.
[Ahmad]
The intent is to mandate the MAG to set the (A) bit whenever the (G) bit
is set. We will try to clarify the text.
>
> Thanks and Regards,
> Sandesh Kumar Sodhi
> _______________________________________________
> MEXT mailing list
> MEXT at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.