[netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received

Xiangsong Cui <Xiangsong.Cui@huawei.com> Wed, 15 July 2009 04:53 UTC

Return-Path: <Xiangsong.Cui@huawei.com>
X-Original-To: netext@core3.amsl.com
Delivered-To: netext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E3928C0D9 for <netext@core3.amsl.com>; Tue, 14 Jul 2009 21:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.438
X-Spam-Level:
X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
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 wpnBOVCPahMb for <netext@core3.amsl.com>; Tue, 14 Jul 2009 21:53:32 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D67923A696E for <netext@ietf.org>; Tue, 14 Jul 2009 21:53:31 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMT00LBK47FU3@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 12:52:27 +0800 (CST)
Received: from c00111037 ([10.111.16.64]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMT006BN47EJN@szxga04-in.huawei.com> for netext@ietf.org; Wed, 15 Jul 2009 12:52:27 +0800 (CST)
Date: Wed, 15 Jul 2009 12:52:26 +0800
From: Xiangsong Cui <Xiangsong.Cui@huawei.com>
To: Basavaraj.Patil@nokia.com, netext@ietf.org, Sri Gundavelli <sgundave@cisco.com>
Message-id: <002a01ca0508$0d0132a0$40106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <C6822BEF.2AC55%basavaraj.patil@nokia.com>
Subject: [netext] Discussion about "Retransmit Message Identifier Option"//Re: Agenda Requests received
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 04:53:34 -0000

Good idea.

I have a question about item 5, "Retransmit Message Identifier Option".
I ever posted a mail on 27 June, but it was ignored. So I copy the mail 
here:

The draft says:
----------------------------------------
1.  Introduction

   The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the
   ability for the sender of a signaling message to mark retransmitted
   messages with a proper tag, so the receiver can differentiate between
   the original message to a retransmitted message.  This semantic is
   important for the receiver to determine when to ignore processing a
   retransmitted packet, or for various other reasons.
---------------------------------------------

Is the motive is just to distinguish the original and retransmitted PBU?


I ask this question just because I think it is unnecessary. The reason is:

1, section 6.1.7 [RFC3775] shows there is a "Sequence #" field in BU
message, and
   section 11.8 [RFC3775] says:
   --------------------------------------------------------
      Retransmitted Binding Updates MUST use a Sequence Number value
   greater than that used for the previous transmission of this Binding
   Update.
   ----------------------------------------------------
   So the BU messages are different for their sequence number.

2,  section 6.6 [RFC5213] says:
     -----------------------------------------
     6.6.  Acquiring Mobile Node's Identifier

   All the network entities in a Proxy Mobile IPv6 domain MUST be able
   to identify a mobile node, using its MN-Identifier.  This identifier
   MUST be stable and unique across the Proxy Mobile IPv6 domain.  The
   mobility entities in the Proxy Mobile IPv6 domain MUST be able to use
   this identifier in the signaling messages and unambiguously identify
   a given mobile node.  The following are some of the considerations
   related to this MN-Identifier.
   -------------------------------------------
   In [RFC3775] LMA MUST distinguish the mobile node by the MN-ID.
   PBU message format also shows there is a sequence # field in PBU
   message and "Mobile Node Identifier option" is valid.

3, section 6.9.4 [RFC5213] has specified the rule for Retransmissions and
Rate Limiting.


For these reasons, I believe the LMA can recognize the duplicate PBUs.
The LMA has been capable of making binding for the first PBU and ignore
other PBUs for the same mobile node.


Do I make any mistakes? and why we need a new extension?


Because I will not go to the meeting, I want to discuss the topic in list
before the meeting.

Thanks and regards

Xiangsong

=================================================
----- Original Message ----- 
From: <Basavaraj.Patil@nokia.com>
To: <Basavaraj.Patil@nokia.com>; <netext@ietf.org>
Sent: Wednesday, July 15, 2009 1:34 AM
Subject: Re: [netext] Agenda Requests received


>
> As of 7/14 the chairs have received requests for agenda slots at IETF75.
> We would like to encourage WG members to review the I-Ds and provide
> feedback on the list prior to the meeting itself.
>
> -Chairs
>
>
> Agenda requests received:
>
> 1. Runtime LMA Assignment Support for Proxy Mobile IPv6
>   I-D: draft-korhonen-netext-redirect-02
>   Jouni Korhonen - 10 Mins
>
> 2. Localized Routing
>   PMIPv6 Localized Routing Problem Statement
>   I-D: draft-liebsch-netext-pmip6-ro-ps-01.txt
>   PS and Scope discussion    10 Mins
>   Solutions        15 Mins
>   Marco Liebsch et al.
>
>   Proxy MIP extension for local routing optimization
>   I-D: draft-wu-netext-local-ro-02.txt
>   Behcet Sarikaya    5 Mins
>
> 3. Tunnel Negotiation for Proxy Mobile IPv6
>   I-D: draft-xia-netext-tunnel-negotiation-01.txt
>   Frank Xia        10 Mins
>
> 4. Mobile Node Group Identifier Option:
>   I-D: draft-gundavelli-netext-mn-groupid-option-01
>   Sri Gundavelli    10 Mins
>
> 5. Retransmit Message Identifier Option:
>   I-D: draft-gundavelli-netext-pmipv6-retransmit-option-00.txt
>   Sri Gundavelli    10 Mins
>
> 6. Mobility session suspend
>   I-D: draft-muhanna-netext-mobility-session-suspend-00.txt
>   Ahmad Muhanna    10 Mins
>
> 7. Trace Control Support for Proxy Mobile IPv6
>   I-D: draft-wang-netext-trace-control-00.txt
>   Yungui Wang        10 Mins
>
> 8. Multihoming extensions for Proxy Mobile IPv6
>   I-D: draft-bernardos-mif-pmip-00.txt
>   Telemaco, Pierrick and Carlos    10 Mins
>
> 9. 3GPP MN-AR interface
>   I-D: draft-melia-netext-3gpp-mn-ar-if-00.txt
>   Telemaco                5 Mins
>
> 10. Service Flow Identifier in Proxy Mobile IPv6
>    I-D: draft-hui-netext-service-flow-identifier-00.txt
>    Min Hui        10 Mins
>
> 11. Connection Identifier for Proxy Mobile IPv6
>    I-D: draft-wolfner-netext-pmip6-connid-00
>    Jouni Korhonen    5 Mins
>
> 12. Bulk Re-registration for Proxy Mobile IPv6
>    I-D: draft-premec-netlmm-bulk-re-registration-02
>    Jouni Korhonen    5 Mins
>
> 13. Partial Handoff Support in PMIPv6
>    I-D: draft-jeyatharan-netext-pmip-partial-handoff-00
>    Mohana Jeyatharan
>
>
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext