Re: [MEXT] Processing of BRI (Binding Revocation) by MAG
"Ahmad Muhanna" <amuhanna@nortel.com> Tue, 20 January 2009 09:55 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: nemo-archive@megatron.ietf.org
Delivered-To: ietfarch-nemo-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 921E228C0EE; Tue, 20 Jan 2009 01:55:48 -0800 (PST)
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 F394F3A6A36; Tue, 20 Jan 2009 01:55:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.468
X-Spam-Level:
X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pm6fCXbk16BL; Tue, 20 Jan 2009 01:55:45 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3BC5E3A69B3; Tue, 20 Jan 2009 01:55:45 -0800 (PST)
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 n0K9tPL27973; Tue, 20 Jan 2009 09:55:25 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 20 Jan 2009 03:55:14 -0600
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E1CB35D0B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <200901200635.n0K6ZFxA016051@ricky.india.internal.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Processing of BRI (Binding Revocation) by MAG
Thread-Index: Acl6MbWiLAZ2wPBbRNyWgrShkUmdqQADGOwAACLlBcAABe3McA==
References: <C5A96676FCD00745B64AE42D5FCC9B6E1CA92CFF@zrc2hxm0.corp.nortel.com> <200901200635.n0K6ZFxA016051@ricky.india.internal.net>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: Magesh Shanmugam <mshanmugam@intellinet-india.com>
Cc: netlmm@ietf.org, mext@ietf.org
Subject: Re: [MEXT] Processing of BRI (Binding Revocation) by MAG
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/pipermail/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>
Content-Type: multipart/mixed; boundary="===============0814517156=="
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Ahmad I have a query regarding the handling of Binding Revocation by MAG for individual binding session. Following is the scenario: Scenario: 1. Proxy Mobile Initial Registration, MAG sends PBU to LMA with HNP option set to ALL_ZERO for MN 1. 2. LMA in turn sends back PBA with 3 HNP(s) assigned to MN 1 and updates Binding Cache Entry. 3. MAG updates Binding Update List entry and sends Router Advertisement to the MN with all the prefixes and prefix lifetime. Note: MAG considers the prefix lifetime as binding lifetime and starts Binding Lifetime timer. 4. Bi-directional tunnel is established between MAG and LMA. 5. Prefix Route(s) are created for all the prefixes at MAG. 6. MN 1 gets one IP Address from the alloted 3 HNP(s). 7. LMA sends BRI message with one HNP (out of the alloted 3 HNPs) with revoke trigger as "ADMINISTRATIVE REASON". After step 7, when MAG receives BRI message with only one HNP and MN-ID: Queries: 1. Will MAG stop the binding lifetime timer (started after binding session establishment), due to the received BRI message? 2. Will MAG delete the complete Binding Update List maintained for the MN (MN 1) or will it delete only the corresponding HNP entry from the BUL and send RA message to MN 1 (eventhough the IP Address used by MN is not from the HNP received in BRI message)? If it deletes only the corresponding HNP entry, what will happen to the Binding Lifetime timer? [Ahmad] If the LMA assigned 3 HNP for MN1, then if the LMA would like to revoke all of the HNPs, the LMA have one of the following options: 1. Send BRI with MN-ID option ONLY. This means that all HNPs are revoked, or [Magesh] If there are multiple interfaces (multi-homed) for the same MN, will MAG remove the Binding Update List maintained for all the interfaces, as there is no Link Layer Identifier Option in the BRI message? [Ahmad] The intention is to have this work sort of a mini global revocation. In other words, if the LMA would like to revoke all of the MN bindings, then including the MN-ID alone will suffice. I do not see any problem in that and should be applicable to multihomed too. If the LMA would like to revoke a single HNP, then LMA need to include the one that needs to be revoked. 2. Send a BRI with MN-ID and all HNPs. Although, the draft recommend Number 1 BUT does not prevent No. 2. On the other hand, if the LMA sends a BRI with MN-ID and a single HNP, then the MAG MUST consider the revocation of that single HNP and MUST NOT remove the MN1 from the BUL. [Magesh] What will be the status of binding lifetime timer? Will the timer be running even though the single HNP is removed from BUL entry (or will the timer be stopped). [Ahmad] I probably need to clarify this one. If each HNP maps to a separate binding, then that binding timer which is defined by the included HNP should be cancelled. please see more below. [Magesh] IMO, if LMA tries to revoke a particular mobility session (Binding Cache Entry), it has to send the MN-ID and all the HNP(s) allocated for the particular session. Sending of one HNP out of the allocated n HNP(s) should be treated as Invalid Case. The behavior should be same as PBU received from MAG for De-Registration (where all the HNP(s) allocated are present in the PBU message). [Ahmad] I guess we have two cases here. If the BCE is allocated more than one HNP in the same PBU/PBA, then the LMA should send BRI with MN-ID and no HNP(s) included to revoke the MN BCE. In this specific case, if the LMA chooses to include the HNP option, the LMA SHOULD include all of the allocated HNP(s). IMO, the LMA should include the MN-ID ONLY and should suffice. The other usecase, if the MN with multihoming has multiple BCE(s) with different HNPs for each BCE. In this case, the LMA MAY send a BRI to revoke a single BCE, e.g. with HNP=HNP1. In case the LMA sends a BRI with MN-ID ONLY, i.e. without any HNP(s), the MAG should handle this as if all of the MN BCE(s) have been revoked. In other words, if the MN-ID has multiple BCE with different HNP(s), then the inclusion of the HNP in the BRI is crucial for defining the MN BCE that is being revoked. I will make sure that the text in the draft is clear on this. Regards, Ahmad Hope this help. Regards, Ahmad Thanks S Magesh
_______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext
- [MEXT] Processing of BRI (Binding Revocation) by … Magesh Shanmugam
- Re: [MEXT] Processing of BRI (Binding Revocation)… Ahmad Muhanna
- Re: [MEXT] Processing of BRI (Binding Revocation)… Magesh Shanmugam
- Re: [MEXT] Processing of BRI (Binding Revocation)… Ahmad Muhanna