Subject: [netlmm] Alternatives to RECOMMENDED timestamp

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 14 Sep 2007 19:59:47 +0200

I've had a nice chat with Ahmad on the phone.  We agree on many things,
but not all.

I personally don't agree with the paragraph that says that PMIPv6
RECOMMENDS (SHOULD) timestamps.  I would at most write that PMIPv6
RECOMMENDS:
-timestamps or
-seq numbers of IKEv2 or
-seq numbers in policy profile.

The problem the timestamps are trying to solve is not new to PMIPv6 and
the problem was already there originally: how could the MAG learn the
HNP of MN, or its MN-ID?  Thus the seqno could be made part of that
policy profile, as HNP and MN-ID are.  Ahmad doesn't like this method a
lot, because... well he can explain.

Seqnumbers in AH, coming from IKEv2 initial exchanges, was probably
discussed already.(?)

These are at least two alternative methods to timestamps, and they have
their advantages and their inconvenients, exactly as timestamps have
advantages and inconvenients.

I really don't see the timestamps should be the only RECOMMENDED (SHOULD).

Alex
PS: draft says:
> For solving this [ordering] problem, this specification RECOMMENDS
> the use of Timestamp option [Section 8.4].  The basic principle
> behind the use of timestamps in binding registration messages is that
> the node generating the message inserts the current time-of-day, and
> the node receiving the message checks that this timestamp is greater
> than all previously accepted timestamps.

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

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 14 Sep 2007 11:30:30 -0700

I'm afraid, this thread is going out of control. I really
do not think, we should go back to basics. 

After converging with Federico and Kilian, we agreed one
the following:

- The timestamp in the PBA is not intended for the MAG to
syncup to the lMA clock, but should be used for diagnostics and
additionally the MAG should sync up to an external clock. The
draft never mandated that the MAG should sync up to the LMA
clock. We will clarify this.

- When TS is supported, it is mandatory requirement for the
MAG clocks to sync up to a clock source. If this requirement
is not met, the LMA will end up processing stale requests. We
will add some text on the imporantance of this requirement.

- We also highly recommend NTP protocol to be used for syncing
the MAG clocks.

Now, there is only one issue and that is Alex's issue. Other
than this, we clearly have consensus on the approach and on the
text. Lets stick to this.

- Is it mandatory for the implementations to implement Timestamp
based solution. [Y/N]. Just a YES or NO, will be more than 
sufficient.

Please comment on this and avoid going back to basics. We need
to complete this work. IMHO, for this entire race condition to
occur, quite a few things have to fall in place, some dramatic
affects and all the stars have to alligned in a pattern. Lets not
kill ourselves on this useless issue. Please help me close this.

Regards
Sri

---

From: "Alexandru Petrescu" <[email-masked]>
Date: Fri, 14 Sep 2007 22:00:57 +0200

On 9/14/07, Sri Gundavelli <[email-masked]> wrote:
[...]
> based solution. [Y/N]. Just a YES or NO, will be more than

Yes, together with mandating seqnos.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 14 Sep 2007 13:49:56 -0700

Thanks Alex. Just one clarification.

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 1:01 PM
> To: Sri Gundavelli
> Cc: netlmm
> Subject: Re: [netlmm] Alternatives to RECOMMENDED timestamp
> 

Mandating both as a MUST implement is not an issue. Seq numbers is
supported per 3775 any ways. But, we cannot force the MAG to learn
the seq number from the old MAG. That we cant mandate. If you are
ok with this, we can close this last issue.

Thanks
Sri

---

From: "Alexandru Petrescu" <[email-masked]>
Date: Sat, 15 Sep 2007 00:18:49 +0200

> ok with this, we can close this last issue.

As I said privately to Ahmad: I'm not trying to suggest bringing CTX
in the picture.

The seqno can be learnt by MAG2 from LMA, as part of profile.  Not from MAG1.

I think the issue can thus be closed.  The disturbing text is the only
occurence of the word RECOMMEND, which means SHOULD.  How, or do you
plan to modify that phrase?

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Sep 2007 17:40:06 -0500

> > supported per 3775 any ways. But, we cannot force the MAG 
> to learn the 
> > seq number from the old MAG. That we cant mandate. If you 
> are ok with 
> > this, we can close this last issue.
> 
> As I said privately to Ahmad: I'm not trying to suggest 
> bringing CTX in the picture.
> 

[Ahmad]
Alex,

In the case of CT, the draft is referring to that as out-of-scope since
it is not defined yet. In the case of your proposal of MAG2 learns the
latest per-MN SQN from the LMA as part of profile, is that mechanism
documented anywhere so the draft can reference it?

> 
> I think the issue can thus be closed.  The disturbing text is 
> the only occurence of the word RECOMMEND, which means SHOULD. 
>  How, or do you plan to modify that phrase?
> 
> Alex
> 
> >
> > Thanks
> > Sri
> >
> >
> > > Alex
> > >
> > > >
> > > >
> > > >
> > > > Please comment on this and avoid going back to basics. 
> We need to 
> > > > complete this work. IMHO, for this entire race 
> condition to occur, 
> > > > quite a few things have to fall in place, some dramatic affects 
> > > > and all the stars have to alligned in a pattern. Lets not kill 
> > > > ourselves on this useless issue. Please help me close this.
> > > >
> > > >
> > > >
> > > > Regards
> > > > Sri
> > > >
> > > >
> > > >

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 14 Sep 2007 15:46:52 -0700 (PDT)

Hi Alex,

> The seqno can be learnt by MAG2 from LMA, as part of profile.  Not from MAG1.

How the MAG learns seq num is out of scope, for both the
CT based approach or uploading it to a policy store.

> plan to modify that phrase?

Ok. I will rephrase that and state that both are two alternative
approaches and with out any preference for a given approach. If
the MAG has the ability to learn the seq number, some how, it
can use the Seq number scheme, else it can use the timestamp
based approach. What ever suits the deployment.

Thanks
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 14 Sep 2007 15:50:20 -0700 (PDT)

Hi Ahmad,

> documented anywhere so the draft can reference it?

No. I dont think, the draft should reference this. Its out
of scope for the base draft.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 14 Sep 2007 17:51:16 -0500

Hi Sri,

That is fine with me.

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, September 14, 2007 5:50 PM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Alexandru Petrescu; netlmm
> Subject: RE: [netlmm] Alternatives to RECOMMENDED timestamp
> 
> Hi Ahmad,
> 
> >
> > In the case of CT, the draft is referring to that as out-of-scope 
> > since it is not defined yet. In the case of your proposal of MAG2 
> > learns the latest per-MN SQN from the LMA as part of 
> profile, is that 
> > mechanism documented anywhere so the draft can reference it?
> >
> 
> No. I dont think, the draft should reference this. Its out of 
> scope for the base draft.
> 
> Thanks
> Sri
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 17 Sep 2007 18:38:16 +0200

Sri Gundavelli wrote:
> How the MAG learns seq num is out of scope, for both the CT based
> approach or uploading it to a policy store.

Right, and I can offer a third way on a separate thread, if need is (MAG
  builds a seqno from the MN's NA Target address and increments it from
there, while LMA uses windows of acceptance).

>> I think the issue can thus be closed.  The disturbing text is the
>> only occurence of the word RECOMMEND, which means SHOULD.  How, or
>> do you plan to modify that phrase?
>> 
> 
> approaches and with out any preference for a given approach. If the
> MAG has the ability to learn the seq number, some how, it can use the
> Seq number scheme, else it can use the timestamp based approach. What
> ever suits the deployment.

I agree.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Sep 2007 12:45:27 +0200

> based solution. [Y/N]. Just a YES or NO, will be more than

YES.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Sep 2007 07:32:23 -0500

I am not sure if I answered this question earlier or not, just in case.

YES.

Regards,
Ahmad

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Tuesday, September 18, 2007 5:45 AM
> To: [email-masked]
> > - Is it mandatory for the implementations to implement 
> Timestamp based 
> > solution. [Y/N]. Just a YES or NO, will be more than sufficient.
> 
> YES.
> 
> --julien
>