Re: [MEXT] A comment on draft-ietf-mext-binding-revocation-00
"Ahmad Muhanna" <amuhanna@nortel.com> Mon, 04 August 2008 17:18 UTC
Return-Path: <mext-bounces@ietf.org>
X-Original-To: mip6-archive@megatron.ietf.org
Delivered-To: ietfarch-mip6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9073A6BFB; Mon, 4 Aug 2008 10:18:22 -0700 (PDT)
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 C6BEE3A6BFB for <mext@core3.amsl.com>; Mon, 4 Aug 2008 10:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.213
X-Spam-Level:
X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 Ro9kyySeEk1k for <mext@core3.amsl.com>; Mon, 4 Aug 2008 10:18:19 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 618443A6B50 for <mext@ietf.org>; Mon, 4 Aug 2008 10:18:19 -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 m74HFpp00022; Mon, 4 Aug 2008 17:15:51 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 04 Aug 2008 12:15:49 -0500
Message-ID: <C5A96676FCD00745B64AE42D5FCC9B6E19CFA13B@zrc2hxm0.corp.nortel.com>
In-Reply-To: <e75f55e20808040101y10555164i187b73049d6ce74b@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MEXT] A comment on draft-ietf-mext-binding-revocation-00
Thread-Index: Acj2CGA0e9muQ2FaR5KKrs0XlZFgRgAR7lQQ
References: <e75f55e20808040101y10555164i187b73049d6ce74b@mail.gmail.com>
From: Ahmad Muhanna <amuhanna@nortel.com>
To: Sandesh <sksodhi@gmail.com>, mext@ietf.org
Subject: Re: [MEXT] A comment on draft-ietf-mext-binding-revocation-00
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mext-bounces@ietf.org
Errors-To: mext-bounces@ietf.org
Hi Sandesh, Thanks for reviewing the draft. Let me try to address your concern. It seems to me that sending a BRI with (G) bit when the eth0 goes down, is a MAG local policy and we can not specify that kind of behavior in the draft. I personally believe that the use of the (G) bit should be taken more carefully. In reality, the MAG implementation should use the (G) bit more responsibly or let me say with a clear understanding of its consequences. The intent was to allow the MAG to delete all sessions with a specific LMA for a scheduled maintenance which may take sometime. In your case, the use of the (G) bit may cause the network a problem by introducing an unnecessary signaling traffics. If an implementation would like to use the (G) bit in a less restrictive manner, then I believe that implementation should make sure that its use does not create new complexity or a corner case race condition as you mentioned. In other words, since there is a possibility for eth0 to go up and down relatively quickly, then an implementation should take that in consideration if it decides to send a BRI with the (G) bit for such a case. IMO, that is an implementation decision. Finally, what we could clarify in the draft is to say something like: When the (G) bit is set, the revoking node SHOULD wait for the BRA or exhaust all retransmits before deleting the associated mobile nodes bindings. Will think of some cautious text to add to the LMA behavior in the case when the Revocation Trigger is "Per-Local Policy". Regards, Ahmad ________________________________ From: mext-bounces@ietf.org [mailto:mext-bounces@ietf.org] On Behalf Of Sandesh Sent: Monday, August 04, 2008 3:01 AM To: mext@ietf.org Subject: [MEXT] A comment on draft-ietf-mext-binding-revocation-00 Hi All, IMO following case is possible with PMIPv6 protocol defined in http://tools.ietf.org/html/draft-ietf-mext-binding-revocation-00 and http://tools.ietf.org/html/draft-ietf-netlmm-proxymip6-18 lt = lifetime eth0 is the interface og MAG to the LAN in which MN1 is present. MAG has another interface eth1 through which it is connected to LMA. MN1 ---- eth0 MAG eth1 -------LMA MAG LMA | | | | | | eth0 down | | |\ BRI(G) | eth0 up | \ | (MN1 attaches)| \ PBU(lt!=0)| |----------------->| | \ +-------| | \ / | | +----------->| | / +-------| | BRA / / | |<----/--+ | | / | | / | |<-+ | | PBA | (BUL entry for MN1) (no BCE MN1) Reason - 1. As per these drafts BRI and PBU has their own (independent) sequence numbers. 2. BRI/BRA does not have timestamp option. 3. These drafts do not say that PBU cannot be sent if MAG has already sent BRI(G) to LMA. 4. In IP network missequencing of packets is possible. Thanks and Regards, Sandesh _______________________________________________ MEXT mailing list MEXT@ietf.org https://www.ietf.org/mailman/listinfo/mext