Re: [netlmm] Retransmitting a PBU when HI=1 and MN LL ID is non-zero (draft-ietf-netlmm-proxymip6-18)

Sri Gundavelli <sgundave@cisco.com> Thu, 24 July 2008 15:06 UTC

Return-Path: <netlmm-bounces@ietf.org>
X-Original-To: netlmm-archive@optimus.ietf.org
Delivered-To: ietfarch-netlmm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C516328C11E; Thu, 24 Jul 2008 08:06:17 -0700 (PDT)
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D622828C0E0 for <netlmm@core3.amsl.com>; Thu, 24 Jul 2008 08:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.534
X-Spam-Level:
X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 F5d+NGcCjANO for <netlmm@core3.amsl.com>; Thu, 24 Jul 2008 08:06:16 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id F07C628C126 for <netlmm@ietf.org>; Thu, 24 Jul 2008 08:06:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.31,246,1215388800"; d="scan'208";a="89700004"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2008 15:07:01 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6OF71RE016995; Thu, 24 Jul 2008 08:07:01 -0700
Received: from irp-view13.cisco.com (irp-view13.cisco.com [171.70.120.60]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m6OF70U7024804; Thu, 24 Jul 2008 15:07:00 GMT
Date: Thu, 24 Jul 2008 08:07:00 -0700
From: Sri Gundavelli <sgundave@cisco.com>
To: Tero Kauppinen <tero.kauppinen@ericsson.com>
In-Reply-To: <D34CB2979BAB35448AB0A5FBAC56778D04476745@esealmw114.eemea.ericsson.se>
Message-ID: <Pine.GSO.4.63.0807240756460.23483@irp-view13.cisco.com>
References: <D34CB2979BAB35448AB0A5FBAC56778D04476745@esealmw114.eemea.ericsson.se>
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2346; t=1216912021; x=1217776021; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:=20Sri=20Gundavelli=20<sgundave@cisco.com> |Subject:=20Re=3A=20[netlmm]=20Retransmitting=20a=20PBU=20w hen=20HI=3D1=20and=20MN=20LL=20ID=20is=20non-zero=0A=20(draf t-ietf-netlmm-proxymip6-18) |Sender:=20; bh=RMMOl1JAgNyFvT94diQLc1iSSMhyviVkhscaWyQjw6Q=; b=qbBcYk5W37wNr77bl8mq7a/g7GzQM3QxpinmHdvEVTyxRroX+4W2LyTTjv OtXkYy5tPh6VhTdzHzsmQjt/fCKh9YEd3cZz5E0hVN5PAeCqM5DLq9sXUI2g HzCHTs49WUnXkKfg6+r3giW5FdubBQ/qZUmD8yreYTmIa0MkotxyA=;
Authentication-Results: sj-dkim-1; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: netlmm@ietf.org
Subject: Re: [netlmm] Retransmitting a PBU when HI=1 and MN LL ID is non-zero (draft-ietf-netlmm-proxymip6-18)
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: netlmm-bounces@ietf.org
Errors-To: netlmm-bounces@ietf.org

Hi Tero,



On Thu, 24 Jul 2008, Tero Kauppinen wrote:

> Hello
>
> Let's consider the following case where MAG sends a PBU where HI=1
> (Attachment over a new interface) and MN LL ID is non-zero (no HNP).
> When LMA receives the initial PBU it creates a new BCE and sends back a
> PBA. If that PBA is lost, MAG will retransmit the PBU. If MAG leaves HI
> to 1 (I didn't find any indication from the spec that it should do
> otherwise) and retransmits the request, LMA will come to a conclusion
> that this is 'Binding Lifetime Extension - After handoff'. This because:
>

This is the correct behaviour. The LMA has the state for that session
and it should just update that session and not create a new session.
>From the MAG perspective, it never received the ACK and it just
retransmits the PBU with the same parameters, except seq num/time
stamp values.


> Section 5.4.1.1. skipped (no HNP)
> Section 5.4.1.2. hit (MN LL ID non-zero) checks 1) and 2) match -> a
> request for updating an existing Binding Cache entry
> Section 5.3.1. check 13 results in the third option (Binding Lifetime
> Extension - After handoff) because HI=1
>
> However, if HI would be set to a value of 5 (Handoff state not changed)
> for retransmissions, LMA would choose (Binding Lifetime Extension- No
> handoff) which I think should happen in this case. However, I'm still a
> bit unsure if this would break some other cases. Even if the initial PBU
> is not received by LMA, setting HI to 5 would result in the correct
> behavior because there is no existing BCE with matching {MN ID, AT, MN
> LL} triplet and thus LMA will create a new BCE regardless of the value
> of HI.
>

The MAG cannot set HI=5 (Re-Reg), we clearly require all the session
parameters in re-reg or de-reg messages. In this case, the MAG would not
even know the HNP as it never received the PBA.

Thanks
Sri




> Br,
>
> Tero Kauppinen                                 Tel: +358 9 299 3057
> Research Scientist, NomadicLab, IP Networks,   Fax: +358 9 299 3535
> Ericsson Research, Corporate Unit.             Mobile: +358 40 590 7560
> Oy L M Ericsson Ab
> mailto:tero.kauppinen@ericsson.com
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm
>
_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www.ietf.org/mailman/listinfo/netlmm