Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt

"Ahmad Muhanna" <amuhanna@nortel.com> Fri, 11 September 2009 22:12 UTC

Return-Path: <AMUHANNA@nortel.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3466B3A6961 for <mext@core3.amsl.com>; Fri, 11 Sep 2009 15:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.632
X-Spam-Level:
X-Spam-Status: No, score=-6.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU-iMxV1N5MJ for <mext@core3.amsl.com>; Fri, 11 Sep 2009 15:12:30 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D12C73A6803 for <mext@ietf.org>; Fri, 11 Sep 2009 15:12:29 -0700 (PDT)
Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n8BMD0806001; Fri, 11 Sep 2009 22:13:00 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 11 Sep 2009 17:12:43 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E2038AA0C@zrc2hxm0.corp.nortel.com>
In-Reply-To: <C6D013E7.B238%vijay@wichorus.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt
Thread-Index: Acox4lFU+sSdQrm5Rx2QjG6qUkRxswAAQ/CwACQhAgEAC/ZdAAAZ/jxUAAZPGkAAAS+TSQAAbegA
References: <C5A96676FCD00745B64AE42D5FCC9B6E2038A973@zrc2hxm0.corp.nortel.com> <C6D013E7.B238%vijay@wichorus.com>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: Vijay Devarapalli <vijay@wichorus.com>, mext@ietf.org
Subject: Re: [MEXT] I-D Action:draft-ietf-mext-binding-revocation-12.txt
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2009 22:12:31 -0000

Hi Vijay,


> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay@wichorus.com] 
> Sent: Friday, September 11, 2009 4:49 PM
> To: Muhanna, Ahmad (RICH1:2H10); mext@ietf.org
> Subject: Re: [MEXT] I-D 
> Action:draft-ietf-mext-binding-revocation-12.txt
> 
> Hi Ahmad,
> 
> On 9/11/09 2:31 PM, "Ahmad Muhanna" wrote:
> 
> >> Your proposal above says the LMA should go ahead, process 
> the BRI and 
> >> remove a set of bindings and not send an Ack. This is 
> contradictory 
> >> to the above.
> > [Ahmad]
> > Because, rev. 12 text says that the LMA SHOULD silently discard the 
> > BRI message and you objected and I was trying to work to hopefully 
> > satisfy what you are looking for.
> > 
> > However, If the (A) bit is NOT set in the BRI with (G) bit 
> is set, the 
> > receiving node SHOULD silently discard the message. WHY?
> > 
> > 1. The sending node is fully aware of the severity of the 
> BRI with the
> > (G) bit set and revocation trigger="Per-Peer Policy", thus the 
> > initiator which comply to this specification knows that it is doing 
> > something illegal and wrong.
> > 
> > 2. On the other hand, even if the receiving node would like 
> to send a 
> > BRA with a status "unsuccessful", there is NO guarantee that the 
> > initiator will ever process that message and learn what happened, 
> > because it does NOT track the BRI in the outstanding BRI messages 
> > list, because it did not set the (A) bit.
> > 
> > So, I was wrong, will keep the existing text.:)
> 
> You have confused the heck out of me. :) Ok, back to the 
> issue. The MAG sends a bulk revocation message with the 'G' 
> flag set, but with the 'A' flag not set. What is the LMA 
> behavior for this?
> 
> The current text says the LMA must silently discard the BRI. 
> This doesn't make sense.
> 
> Can you first explain what the LMA should do before we try to 
> change any text?
[Ahmad]
Agreed. I was thinking that the message comes from the LMA to the MAG :(

1. If the MAG does not set the (A) bit, it is communicating to the LMA
that it is NOT interested in getting back a BRA.
2. Consequently, when the MAG does not set the (A) bit, it does not
retransmits the BRI and it does not track the BRI as one of the
outstanding BRI messages.

3. NOW, when the LMA receives such message, as per this specification
the MAG MUST have set the (A) bit in this case, but it did not. What the
options for the LMA:

3.1. Process the message and remove all bindings without sending a BRA,
but the MAG did violate the protocol and mandating that the MAG set the
(A) bit in this case means something.
3.2. Process the message and send a BRA with an unsuccessful status
code, well, the LMA can do that, BUT unfortunately it wont help in
anything. Because as I said the MAG is NOT expecting a BRA and is not
tracking the BRI as an outstanding message.
3.3. LMA consider this BRI as a violation of the protocol and does not
remove the mobility sessions based on this message. In addition, since
the (A) bit is not set, the LMA does not send a BRA. This means, LMA
discard the message. 

IMO, option No. 3 is the correct one and that what rev 12 text says.

Hope it is clearer this time.

Regards,
Ahmad

> 
> Vijay
> 
> > 
> > Regards,
> > Ahmad
> > 
> >> 
> >> Just removing the 'A' bit would help. :)
> >> 
> >> Vijay
> >> 
> >>> 
> >>> Regards,
> >>> Ahmad
> >>> 
> >>>> 
> >>>> Vijay
> >>>> 
> >>>> 
> >>>> On 9/9/09 11:58 PM, "Ahmad Muhanna" wrote:
> >>>> 
> >>>>> FYI,
> >>>>> 
> >>>>> A new revision has been published which clarifies further
> >> the wild
> >>>>> card NAI as per Pasi's comment. It also uses proper RFC2119 
> >>>>> requirements in couple of places as per Ralph's comment.
> >>>>> 
> >>>>> Regards,
> >>>>> Ahmad
> >>>>>  
> >>>>> 
> >>>>>> -----Original Message-----
> >>>>>> From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org]
> >>>> On Behalf
> >>>>>> Of Internet-Drafts@ietf.org
> >>>>>> Sent: Thursday, September 10, 2009 1:45 AM
> >>>>>> To: i-d-announce@ietf.org
> >>>>>> Cc: mext@ietf.org
> >>>>>> Subject: [MEXT] I-D
> >>>> Action:draft-ietf-mext-binding-revocation-12.txt
> >>>>>> 
> >>>>>> A New Internet-Draft is available from the on-line
> >> Internet-Drafts
> >>>>>> directories.
> >>>>>> This draft is a work item of the Mobility EXTensions for
> >>>> IPv6 Working
> >>>>>> Group of the IETF.
> >>>>>> 
> >>>>>> 
> >>>>>> Title           : Binding Revocation for IPv6 Mobility
> >>>>>> Author(s)       : A. Muhanna, et al.
> >>>>>> Filename        : draft-ietf-mext-binding-revocation-12.txt
> >>>>>> Pages           : 43
> >>>>>> Date            : 2009-09-09
> >>>>>> 
> >>>>>> This document defines a binding revocation mechanism to
> >>>> terminate a
> >>>>>> mobile node's mobility session and the associated
> >>>> resources.  These
> >>>>>> semantics are generic enough and can be used by mobility
> >>>> entities in
> >>>>>> the case of Mobile IPv6 and its extensions.  This
> >> mechanism allows
> >>>>>> the mobility entity which initiates the revocation 
> procedure to 
> >>>>>> request its peer to terminate either one, multiple or all
> >>>> specified
> >>>>>> binding(s).
> >>>>>> 
> >>>>>> A URL for this Internet-Draft is:
> >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-re
> >>>>> vocation-12.txt
> >>>>>> 
> >>>>>> Internet-Drafts are also available by anonymous FTP at:
> >>>>>> ftp://ftp.ietf.org/internet-drafts/
> >>>>>> 
> >>>>>> Below is the data which will enable a MIME compliant 
> mail reader 
> >>>>>> implementation to automatically retrieve the ASCII
> >> version of the
> >>>>>> Internet-Draft.
> >>>>>> 
> >>>>> _______________________________________________
> >>>>> MEXT mailing list
> >>>>> MEXT@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/mext
> >>>> 
> >>>> 
> >> 
> >> 
> 
>