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

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Dec 2007 16:49:27 +0100

[A series of 4 mails happened on mip6 list, due to my error initiating
  the exchange there.  I should have done it here on the mext list.]

It's discussion around the Last Accepted SQN.

>>> But this is new software to write and implement, right? This is
>>> not a minor modification to rfc3775.
> 
> [Ahmad] 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.

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.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

Subject: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna <[email-masked]>]
From: Alexandru Petrescu<[email-masked]>
To: Mobile IPv6 Mailing List<[email-masked]>
Date: Mon, 17 Dec 2007 15:28:28 +0100
List-Id: mip6.ietf.org

mext wrote:
> #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:                         
[...]
>  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. }}}

But this is new software to write and implement, right? This is not a
minor modification to rfc3775.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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

Subject: RE: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna <[email-masked]>]
From: "Ahmad Muhanna"<[email-masked]>
To: "Alexandru Petrescu"<[email-masked]>, "Mobile IPv6 Mailing List"<[email-masked]>
Date: Mon, 17 Dec 2007 08:37:00 -0600

Hi Alex,
Please see comments inline.

Regards,
Ahmad
> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Monday, December 17, 2007 8:28 AM
> To: Mobile IPv6 Mailing List
> Subject: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad 
> Muhanna <[email-masked]>]
> 
> mext wrote:
> > #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:         
>                 
> [...]
> >  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. }}}
> 
> But this is new software to write and implement, right? This 
> is not a minor modification to rfc3775.

[Ahmad]
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.

> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit 
> http://www.messagelabs.com/email 
> ______________________________________________________________________
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

Subject: Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna<[email-masked]>]
From: marcelo bagnulo braun<[email-masked]>
To: Ahmad Muhanna<[email-masked]>
Cc: "Alexandru Petrescu"<[email-masked]>, "Mobile IPv6 Mailing List"<[email-masked]>
Date: Mon, 17 Dec 2007 15:51:48 +0100

El 17/12/2007, a las 15:37, Ahmad Muhanna escribió:

> [Ahmad]
> That's true.

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

Regards, marcelo

> 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.

Subject: RE: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad Muhanna<[email-masked]>]
From: "Ahmad Muhanna"<[email-masked]>
To: "marcelo bagnulo braun"<[email-masked]>
Cc: "Alexandru Petrescu"<[email-masked]>, "Mobile IPv6 Mailing List"<[email-masked]>
Date: Mon, 17 Dec 2007 08:58:21 -0600

Hi Marcelo,
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.

Regards,
Ahmad

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Monday, December 17, 2007 8:52 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Alexandru Petrescu; Mobile IPv6 Mailing List
> Subject: Re: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad 
> Muhanna<[email-masked]>]
> 
> 
> El 17/12/2007, a las 15:37, Ahmad Muhanna escribió:
> 
> > [Ahmad]
> > That's true.
> 
> 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
> 
> Regards, marcelo
> 
> > 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.
> 
> 

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 17 Dec 2007 11:05:07 -0600

> Sent: Monday, December 17, 2007 9:49 AM
> To: [email-masked]
> Subject: [Fwd: [Mip6] Re: [mext] #1: Last Accepted SQN [Ahmad 
> Muhanna <[email-masked]>]]
> 
> >>> But this is new software to write and implement, right? 
> This is not 
> >>> a minor modification to rfc3775.
> > 
> 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]
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?

Regards,
Ahmad

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Dec 2007 22:34:44 +0100

Ahmad Muhanna wrote:
>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Monday, December 17,
>> 2007 9:49 AM To: [email-masked] Subject: [Fwd: [Mip6] Re: [mext] #1:
>> Last Accepted SQN [Ahmad Muhanna <[email-masked]>]]
>> 
>> [A series of 4 mails happened on mip6 list, due to my error
>> initiating the exchange there.  I should have done it here on the
>> mext list.]
>> 
>> 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] 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?

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.

Alex