Subject: [mext] #1: Last Accepted SQN [Ahmad Muhanna <[email-masked]>]

From: "mext" <[email-masked]>
Date: Mon, 17 Dec 2007 13:51:17 -0000

#1: Last Accepted SQN [Ahmad Muhanna <[email-masked]>]
-------------------------------------+--------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  defect                   |      Status:  new                    
 Priority:  major                    |   Milestone:                         
Component:  RFC3775 changes          |     Version:                         
 Keywords:                           |  
-------------------------------------+--------------------------------------
 {{{
 ISSUE:
 ======

 In response to a BU which contains an out of range sequence number, as
 per sections 9.5.1 and 11.7.1, the CN or HA is allowed to send a BA with
 a status of 135 after inserting the last accepted sequence number
 received in the last valid BU in the sequence number field (Different
 from the sequence number received in the outstanding BU)

 According to MN processing of the BA as specified under section 11.7.3.,
 the MN will silently discard the received BA rather than picking the
 last accepted sequence number and then generate a new sequence number.

 I think the intention was to allow the HA or CN to communicate back to
 the MN the last accepted sequence number, however, we are breaking the
 protocol by using this mechanism.

 This issue becomes critical in the case of PMIPv6 since the PMIP client
 would have thousands of outstanding P-BU and the received P-BA most
 probably will collide with another outstanding P-BU causing the PMIP
 client to drop the P-BA and continue to stay out of sync with the
 LMA/HA.

 OLD TEXT:
 =========

 To my recollection, there is no need to change any of the existing text
 since the current text of RFC3775 goes inline with the original
 intention. However, the proposed text needs to be added.

 SOLUTION:
 =========

 The most straightforward solution for this issue is to enable the
 original intention of RFC3775. i.e. by communicating back the last
 successful sequence number in a option:

 Las Valid Sequence Number Mobility Option:
 6.2.x.  Last Valid Sequence Number

    The Last Valid Sequence Number option has an alignment requirement
    of 2n. Its format is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |   Type=TBD    |   Length = 2  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Last Valid Sequence Number  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 The Last Valid Sequence Number option is only valid in a BA, sent from
 the mobile node's home agent in reply to a home registration, with a
 status of 135. The Last Valid Sequence Number is the last sequence
 number that the Home Agent received in the last successful Binding
 Update for the specified session. In case the Home Agent receives a
 Binding Update with a sequence number outside the valid sequence number
 range, the Home Agent sends a BA with a status of 135. HA must copy the
 sequence number from the BU into the sequence number field of the BA. HA
 must include the last Valid Sequence Number into the Last valid Sequence
 Number Mobility option.
 }}}

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/1>
mext <http://tools.ietf.org/wg/mext/trac/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "mext" <[email-masked]>
Date: Tue, 18 Dec 2007 14:02:50 -0000

#1: Last Accepted SQN [Ahmad Muhanna <[email-masked]>]
--------------------------------------+-------------------------------------
  Reporter:  [email-masked]  |       Owner:  [email-masked]
      Type:  defect                   |      Status:  new                    
  Priority:  major                    |   Milestone:                         
 Component:  RFC3775 changes          |     Version:                         
Resolution:                           |    Keywords:                         
--------------------------------------+-------------------------------------
Comment (by [email-masked]):

 Alexandru Petrescu wrote:
 > But this is new software to write and implement, right? This is not a
 > minor modification to rfc3775.

 Ahmad Muhanna wrote:
 >
 > That's true. However, do you agree with the issue?
 >
 > This proposal is one solution for the issue; if you have a
 > different solution which does not require this change, please go
 > ahead and propose it. I do not have any interest in having this
 > proposal adopted, however, IMO, this issue needs to be resolved.

 Marcelo Bagnulo wrote:
 >
 > If you agree that this is true, then this particular proposal is a
 > non starter
 >
 > If you come with an alternative proposal that is a minor change the
 > resubmit it to the ml using the same format please, so we can keep an
 >   ordered track of the proposed issues

 Ahmad Muhanna wrote:
 >
 > I believe this is an issue that needs to be fixed. Many implementation
 did not test if this
 > work in their software or not until this issue was pointed out. IMO,
 this is an error needs
 > to be fixed.
 >
 > On the other hand, I do not see any quick fix for this issue, however,
 if there is someone
 > who can point a quick fix, he is welcome to post it. If the group think
 that fixing this
 > issue is not needed, that is fine with too.
 >
 > BTW: This issue was also discussed before and was submitted to MIP6
 tracker.

 Alexandru Petrescu wrote:
 >
 > While reading it, looks as a situation difficult to reproduce, to
 > start with.  If the proposed solution is not implemented then the MN
 > may start over from a fresh seqno.
 >
 > That's why I don't see why correcting this as part of the minor
 > rfc3775 corrections.

 Ahmad Muhanna wrote:
 >
 > I see what you are saying, since that what you think is the solution for
 > this issue, I suggest that you propose some text to capture what you
 > just said to fix RFC3775 text. On the other hand, if restarting the
 > client is not meaningful in other MIP6 extensions, then where do you
 > think this issue should be fixed, under the other extensions/activities
 > or as a fix to RFC3775?

 Alexandru Petrescu wrote:
 >
 > I don't think I can propose text right now for last accepted seqno
 > issue.  I think it could wait until more implementers share an opinion
 > on this.

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/1#comment:1>
mext <http://tools.ietf.org/wg/mext/trac/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext