Subject: Re: draft-ietf-pppext-sonet-ds-00

From: "William Allen Simpson" <[email-masked]>
Date: Mon, 1 Dec 97 16:47:14 GMT

> From: Stuart Venters <[email-masked]>
> > Note that Stuart did not include most of my comments and questions.
>
>    Noted, but the reasons are 1) you are wearing me down, and 2) I
>    feel that things will go faster if the scope of the discussion
>    narrows until we get to common ground and then look and see
>    what issues are left.
>
Heck, I'm getting worn down myself.  If you cannot answer technical
details asked, then you have not given me sufficient information to
reply.  I don't see why I should waste my time guessing.

Step back.  Look at the WHOLE picture.

> > Which ones?  Specifically?  I have a pile from 1991 and 1992....
>
>  Again, the point was that they were _all_ like this.

No, _NONE_ that I have were "like this".  _NONE_ displayed at Interop
'91, '92 or '93 were "like this".  Since that is the time frame when
RFC-1619 was researched, and the first implementation was developed, you
cannot expect anything else.

>  It appears to be
>  the way things are done.  However, the data sheets I looked at today
>  were the current Amp, Lucent, and Hp single mode OC-3 units with Pecl
>  interfaces but no clock recovery.
>
No clock recovery?  What does this mean?  Clock recovery is required for
both SONet and SDH.

Are you saying that none of these interfaces meets the requirements?

Bring these latest data sheets to IETF.  This isn't going to be solved
on a mailing list.

> > less than 20KHz???
> > That's many orders of magnitude less than we are talking about here....
> >
>   Consider an atacker sending a 1500 byte packet thru which results in a
>   fiber bit stream with a one sprinkled every two or three bytes (overhead
>   bytes excluded of course).  The nasty pattern detector would be none
>   the wiser, but the duty cycle and transition density would be way off
>   for 80uS.  This seems sufficient time for something with a
>   50uS time constant to be affected.
>
>   What's wrong with this attack senario?
>
I cannot make any sense of this scenario.

Are you sure that you didn't mistype KHz for MHz?

Why are overhead bytes excluded?  They are in the middle of the stream,
too.

And forget about two or three bytes.  A one sprinkled every nine bytes
(72 bits), to give the worst case meeting the SDH G.957 pseudo-test,
would be:

Mbps    KHz (sic)
 155    2153
 622    8639
 etc

Orders of magnitude....

[email-masked]
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32