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: monami6-archive@megatron.ietf.org
Delivered-To: ietfarch-monami6-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