Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06056 for ; Thu, 11 Jul 2002 17:00:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16069; Thu, 11 Jul 2002 16:57:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16040 for ; Thu, 11 Jul 2002 16:57:12 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05868 for ; Thu, 11 Jul 2002 16:56:17 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6BKuWl00955; Thu, 11 Jul 2002 16:56:32 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Jul 2002 16:56:32 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4C14@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'Dirk.Trossen@nokia.com'" , kempf@docomolabs-usa.com, seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Date: Thu, 11 Jul 2002 16:56:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2291D.6DEF8CA2" Sender: seamoby-admin@ietf.org Errors-To: seamoby-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/plain; charset="iso-8859-1" Dirk: A valid point. There is a certain atomic level of granularity which has to be dealt with - that is, there's no protocol in the world that can synchronize changes in information that occur at the source while the information is "in-flight" or being received at the destination. If changes in context while the context is being transferred make a different to the successful performance of CT, then there is no hope. The problem is most significant for state context transfer. E.g. counters will continue to count while CT is moving the context to the destination. Either these changes have no significant impact upon the forwarding service provided at the new AR (e.g. it may not matter that a policing meter misses a few packet counts), or a different mechanism has to be defined for re-establishing the state context. The handover is real and unavoidable. Mitigating the disruption to the service at the new AR is the challenge. It would be nice if the disruption was nil, but unlikely. Gary -----Original Message----- From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com] Sent: July 11, 2002 16:30 To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG Hi all, jumping in as somebody who has been an observer so far, struggling with the current discussion on 'integrity'. When I look at the current wording, i.e., "5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time. For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context at the supporting AR must be replicated at those ARs that have already received context for that MN.", and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics) that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement is talking about. If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word 'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text, namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other end, i.e., it talks about distributed data integrity in my interpretation of the requirement text. Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides within each AR. Or on the contrary, they do not see this important topic covered appropriately. Regards, Dirk -----Original Message----- From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com] Sent: Thursday, July 11, 2002 3:48 PM To: 'James Kempf'; seamoby@ietf.org Subject: RE: [Seamoby] CT Requirements Comments from IESG You call it fidelity, I call it data integrity. I've seen "data integrity" used in publications (no, I cannot quote references). What we need is a term that everyone, including the IESG, can agree upon. > -----Original Message----- > From: James Kempf [ mailto:kempf@docomolabs-usa.com ] > Sent: July 11, 2002 12:22 > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org > Subject: Re: [Seamoby] CT Requirements Comments from IESG > > > > Perhaps the actual answer is to state exactly what was intended > > originally: that the bit order and bit values have to arrive exactly > > as they were transmitted. > > > > So this requirement is talking about transmission fidelity? I > sure would not have guessed that from reading it. I thought it > intended to talk about usability. > > I would suggest that the wording you have above is really a > lot more precise that what is currently in the spec. > > Any other comments? Could we substitute Gary's wording above > for "meaning" in the current requirement. > > jak > > ------_=_NextPart_001_01C2291D.6DEF8CA2 Content-Type: text/html; charset="iso-8859-1" RE: [Seamoby] CT Requirements Comments from IESG
Dirk:
 
  A valid point. There is a certain atomic level of granularity which has to be
dealt with - that is, there's no protocol in the world that can synchronize changes in
information that occur at the source while the information is "in-flight" or being
received at the destination. If changes in context while the context is being transferred
make a different to the successful performance of CT, then there is no hope.
 
  The problem is most significant for state context transfer. E.g. counters will continue
to count while CT is moving the context to the destination. Either these changes have no
significant impact upon the forwarding service provided at the new AR (e.g. it may not
matter that a policing meter misses a few packet counts), or a different mechanism
has to be defined for re-establishing the state context.
 
  The handover is real and unavoidable. Mitigating the disruption to the service at the new
AR is the challenge. It would be nice if the disruption was nil, but unlikely.
 
Gary
-----Original Message-----
From: Dirk.Trossen@nokia.com [mailto:Dirk.Trossen@nokia.com]
Sent: July 11, 2002 16:30
To: Kenward, Gary [WDLN2:AN10:EXCH]; kempf@docomolabs-usa.com; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

Hi all,
 
jumping in as somebody who has been an observer so far, struggling with the current discussion on
'integrity'.
 
When I look at the current wording, i.e.,
"5.5.2 A context update MUST preserve the integrity, and thus the meaning, of the context
at each receiving AR. The context at the AR actually supporting an MN's traffic will change with time.
For example, the MN may initiate new microflow(s), or discontinue existing microflows. Any change of context
at the supporting AR must be replicated at those ARs that have already received context for that MN.",
 
and compare this to the plain integrity of the actually transmitted data (i.e., its bits and therefore its semantics)
that has been brought to the table as a replacement now, I'm quite confident that this is not what the requirement
is talking about.
 
If we remove the word 'meaning' (which is very vague and free for interpretation for me as well), it is still the word
'integrity' left, which is more than plain integrity of the transmitted data, in particular if we look at the following sentences
in the requirement, which state what kind of integrity is meant (which probably also builds the bridge to the vague
term 'meaning'), namely that the integrity of a context must be preserved in the sense that a received context at new
AR at some point t must be the same as the context at old AR at the same time t. This is by far more than plain data
integrity of the transmitted data. Even if your data has been transmitted correctly, the context might be stale (and therefore
its integrity is lost) because it had changed at old AR in the meanwhile. The action to be taken is also given in the text,
namely the change of context has to be replicated to the new AR. As you can (hopefully) see this is by far more than
preserving the 'meaning' of each bit. It mandates that changes in the bit values at one end are reflected at the other
end, i.e., it talks about distributed data integrity in my interpretation of the requirement text.
 
Hence, the actual concern might have been (just guessing) whether or not it is the task of the CT protocol to
preserve the abovementioned integrity. Maybe, the IESG wants to see this functionality left to the replication logic that resides
within each AR. Or on the contrary, they do not see this important topic covered appropriately.
 
Regards,
 
 
Dirk 
-----Original Message-----
From: ext Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 11, 2002 3:48 PM
To: 'James Kempf'; seamoby@ietf.org
Subject: RE: [Seamoby] CT Requirements Comments from IESG

You call it fidelity, I call it data integrity.
I've seen "data integrity" used in publications
(no, I cannot quote references).

What we need is a term that everyone, including the
IESG, can agree upon.

> -----Original Message-----
> From: James Kempf [mailto:kempf@docomolabs-usa.com]
> Sent: July 11, 2002 12:22
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@ietf.org
> Subject: Re: [Seamoby] CT Requirements Comments from IESG
>
>
> > Perhaps the actual answer is to state exactly what was intended
> > originally: that the bit order and bit values have to arrive exactly
> > as they were transmitted.
> >
>
> So this requirement is talking about transmission fidelity? I
> sure would not have guessed that from reading it. I thought it
> intended to talk about usability.
>
> I would suggest that the wording you have above is really a
> lot more precise that what is currently in the spec.
>
> Any other comments? Could we substitute Gary's wording above
> for "meaning" in the current requirement.
>
>             jak
>
>

------_=_NextPart_001_01C2291D.6DEF8CA2-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby