Subject: [MEXT] [RFC3775 changes] Next steps

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 9 Dec 2007 14:06:23 +0100

Hi,

We are chartered to update RFC3775 with minor changes. According to  
our charter:

(B.1) Create and maintain issue lists that are generated on the basis
of implementation and interoperability experience. Address
specific issues with specific updates or revisions of the base
specification. One specific area of concern that should be
analyzed and addressed relates to multilink subnets.

This work item relates only to corrections and
clarifications. The working group shall not revisit design
decisions or change the protocol.

Dec 2008 Submit I-D(s) related to specific updates and corrections of  
RFC 3775 to IESG for publication as Proposed Standard.

So in order to proceed with this, we will do the following:

Anyone that thinks that there is something that need to be updated in  
RFC3775, send a mail to the ml for discussion in a diff format,  
meaning, the current text (OLD text) and the proposed text (NEW text)  
and the motivation for the change. Please specify the section and sub  
section and paragraph number for the proposed modification. Please  
send the mails with [RFC3775 changes] included in the subject so we  
can easily keep track of these.

So, the format for these request are:

------------------------------------------------------------------------ 
------
Subject: [RFC3775 changes] Modification title

Section, sub-section and paragraph involved: XXXXXX

OLD TEXT: XXXXXXXXXXXXXXXXX

NEW TEXT: XXXXXXXXXXXXXXXXXXXXXXXX

Motivation: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
------------------------------------------------------------------------ 
------

We (the chairs) will keep a list of proposed updates and the comments  
received for each of those.
Near the deadline we will produce a rfc3775bis with the changes that  
have reached consensus.

We already have a list of issues presented and discussed in the  
vancouver meeting, please convert them into the OLD/NEW text approach  
if you think they are relevant and need to be addressed

Regards, marcelo

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 10 Dec 2007 08:31:12 -0600

Hi Marcelo/All,

Please find the details related to the last accepted sequence number.
This issue have been discussed before on MIP6 and was submitted to the
RFC3775 issue tracker on May 14, 2007.

Please find the details below.
Please feel free to discuss this issue.

Best Regards,
Ahmad

+++++++++++++++++++++++++++++++++++++++++++++++

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.

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Sunday, December 09, 2007 7:06 AM
> To: [email-masked]
> Cc: Julien Laganier
> Subject: [MEXT] [RFC3775 changes] Next steps
> 
> Hi,
> 
> We are chartered to update RFC3775 with minor changes. 
> According to our charter:
> 
> 
> (B.1) Create and maintain issue lists that are generated on 
> the basis of implementation and interoperability experience. 
> Address specific issues with specific updates or revisions of 
> the base specification. One specific area of concern that 
> should be analyzed and addressed relates to multilink subnets.
> 
> Dec 2008 Submit I-D(s) related to specific updates and 
> corrections of RFC 3775 to IESG for publication as Proposed Standard.
> 
> Anyone that thinks that there is something that need to be 
> updated in RFC3775, send a mail to the ml for discussion in a 
> diff format, meaning, the current text (OLD text) and the 
> proposed text (NEW text) and the motivation for the change. 
> Please specify the section and sub section and paragraph 
> number for the proposed modification. Please send the mails 
> with [RFC3775 changes] included in the subject so we can 
> easily keep track of these.
> 
> We (the chairs) will keep a list of proposed updates and the 
> comments received for each of those.
> Near the deadline we will produce a rfc3775bis with the 
> changes that have reached consensus.
> 
> We already have a list of issues presented and discussed in 
> the vancouver meeting, please convert them into the OLD/NEW 
> text approach if you think they are relevant and need to be addressed
> 
> Regards, marcelo
> 
> 
>