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

From: "William Allen Simpson" <[email-masked]>
Date: Mon, 24 Nov 97 15:01:55 GMT

> From: [email-masked] (C. M. Heard/VVNET, Inc.)
> > Where is this not fully compatible?  There have been no verified
> > examples given where it is not....  Please be specific.
>
> The I-D <draft-ietf-pppext-pppsonet-scrambler-00.txt> by Manchester,
> Krishnaswamy, et al. was pretty clear about this, and I for one
> find its conclusions hard to fault.

The draft is completely without specifics.  What chips?  What links?

Remember, there have been no SONET compliant chipsets cited that signal
LOS at 2.3 us.  And SDH compliant chips are not allowed to enter LOS at
any time while good frame markers (A1A2) are found, as they only fall
out on a BER.  You provided us that text.

And even if either of them did, they are required to recover on the next
frame markers.  So, no serious effect.

I'm really sick and tired of the hypothetical handwringing.  This is not
a real world problem.

The conclusions of Manchester et alia have been demonstrated to be
completely without merit.  And their proposed solution is overly
complicated, not a 100% solution, and not backward compatible.

> If the purpose of PPP over SONET/SDH is to take advantage of existing
> infrastructure, then the PPP over SONET/SDH spec needs to be compatible
> with the specs to which that existing infrastucture is required to comply,
> even if in your judgement good engineering practice would dictate that
> the equipment should be built to follow tighter specs.
>
That's right, we are talking about _existing_ infrastructure.  Show us
the existing infrastructure with this problem!

And as for the recent weakening of the "standards", this proposed IETF
profile simply does not recommend _new_ infrastructure to be deployed
with shoddy chipsets, and has a testing and remediation procedure.  What
more do you want?

> This is a dandy way to locate bit transitions at low speeds.  Most
> UARTS use it, as do DPLLs in some low- to moderate-speed HDLC devices.
>
> But at OC-3 rates it would imply circuitry clocking at
>
>    16 * 155.52 Mhz = 2.48832  Ghz
>
> which is not so easy to do.
>
Are you saying that folks are _not_ deploying STM-16 (OC-48) and even
(non-"standard") STM-64 (OC-192)?  Easy is relative.

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