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

From: "William Allen Simpson" <[email-masked]>
Date: Mon, 24 Nov 97 18:43:58 GMT

> From: Stuart Venters <[email-masked]>
> > > From: Stuart Venters <[email-masked]>
> > > First the "Applicability" section. IMHO, (and given the benefit of 20-20
> > > hind site,) I think you are solving the wrong problem.  While there may
> > > be a need for an intra-campus Sonet spec, there is definitely a need for
> > > a full wide area spec which is fully Sonet compatible.  Wouldn't overall
> > > interoperability be better served if we gave up interoperability with the
> > > original 1619 and cut over to some other scheme which is fully compatible
> > > with the actual wide area Sonet installed base?
> > >
> > Where is this not fully compatible?
>
> Please clarify the ground rules for me:
>
>      The Applicability section of rfc-1619 has consistantly said that the
>      PPP over Sonet spec IS NOT ACCEPTABLE for the public Sonet
>      infrastructure.
>
>      You (in your above response) appear to be saying that it
>      IS ACCEPTABLE for the public Sonet infrastructure.
>
>      Which way do you think it should be?
>
I don't see how this follows from your previous comment, that the
specification is not fully SONet compatible.  I wish that you would
answer my question, one way or the other.  After all the weeks of
review, nobody else has been able to find any reason.

The Applicability Statement (part of our standards process) clearly
states in its first sentence (including the grammatical error):

   This specification is intended for those implementations which desire
   to use the PPP encapsulation over high speed private point-to-point
   links, such as intra-campus single-mode fiber which may already be
   installed and unused.

I don't see the words "NOT ACCEPTABLE" there anywhere.  What I see is
"private".  This is about private links.  Only private links.  Indeed,
it would be hard for it to be otherwise, as optics are hard to share.

As to "public" infrastructure (assuming government owned), I see no
difference.  There is no reason why that private link cannot be leased
from a government, a teleopoly (not public), or anyone else.

Now, you could be misusing the term "public", and mean some form of time
division multiplexing of the private link with other private links.  But
in that case, say over the pond, VC4s are interleaved byte by byte.  So,
as far as the PPPSDH group has been able to determine, there is no issue.
No single user can control the optic timings.

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

---

From: [email-masked]
Date: Mon, 24 Nov 1997 15:34:55 -0500

I really don't think there were any PPPSDH group consensus decisions to
be represented.

James [email-masked]

---

From: Tony Li <[email-masked]>
Date: 24 Nov 1997 13:26:47 -0800

> I really don't think there were any PPPSDH group consensus decisions to

Agreed.  In particular, that 'group' seems to have never taken any polls of
consensus and been a forum for one person's agenda.

Tony

---

From: Stuart Venters <[email-masked]>
Date: Mon, 24 Nov 97 19:43:20 CST

Bill,

We appear to have confusion in my use of the word public.  To speed things up,
I will try to switch to your terminology, and answer your question.

I see two different kinds of your private point-to point links.

A single-owner private link is one where a single entity is responsible
for maintaining both the Sonet link and the RFC-1619 terminal equipment.
An example of this is the intra-campus example in the Applicability
paragraph.  (This is what i previously meant by private.)

A multi-owner private link is one where multiple entities are
responsible for maintaining the Sonet link and RFC-1619 terminal
equipment.  An example could be your over the pond example which
would definately include multiplexors.  (This is what i previously
meant by public.)

I believe that, although they are built from the same components, there
is a significant difference when it comes to operating these two kinds of
links.  I think this difference means that your proposal may cause problems
on the multi-owner link.  A description of the failure mechanism follows:

There is a correspondence between how long a string of constant valued bits 
is transmitted on the fiber and how far off the receive timing, receive
slicing threshold, and transmit automatic level control shift from optimal.
One way to look at the effect of these shifts on the system is to remember
that there is some receiver power level threshold necessary to provide
reliable data recovery.  The shifts from optimal raise this threshold so
that a stronger signal is required for reliable data recovery.

For various reasons, most communications systems are designed to provide
extra signal power at the receiver above that required for reliable data
recovery.  This extra is called margin.

My understanding of your proposal for setting the nasty sequence
detection threshold is as follows:
	1) Measure how many sequential bytes it takes to cause a problem.
	2) Set the threshold slightly below this.
	3) Turn it on and watch it run.

What you a really measuring is now much margin there is in the Sonet link.
What you are actually setting is how much margin to use when the nasty
sequence goes by.

On a multi-owner link, this results in an operational problem.  When 
telephone companies build complex networks, they engineer links with extra
margin.  This extra margin is to allow the telephone company to sell a
relatively reliable link without requiring a lot of maintainance effort to
keep it running over time.  The result is that a link should not make any
significant number of errors unless it is broken.  If it makes errors, it
must be broken, so effort is expended to fix it.  In effect, the margin
is a capital investment that they are using to lower maintenance costs.

Your proposal has the effect that the owner of the rfc-1619 terminal
equipment can take the margin that the telephone company is counting
on to keep their maintenance costs down.

A more concrete example is as follows: 
	1) Suppose a telephone company engineers a private circuit
	     such that one of it's internal section margins is 10dB.
	2) Suppose that the terminal equipment owner connects to
	     the circuit and calibrates his insertion trheshold
	     so that it consumes 8dB of margin when the nasty 
	     sequence goes by.
	3) Suppose a year later, some equipment change is made in
	     the internal link and the margin is now 6dB.
	4) When a nasty packet goes by, the telephone company is
	     going to be spending money trying to figure out what
	     is wrong when the fault is with terminal equipment
	     which is sending sequences which Sonet is not
	     designed to transport.

This is where i think your proposal is not fully compliant with the
deployed Sonet infrastructure.

As for the Sonet specs, Sonet is designed assuming the bit stream on
the fiber is random with lots of transitions and approximatly a 50%
duty cycle.  (To run without transitions for over a byte time
not the expected operating point.)
The Sonet specs detail a method for testing Sonet equipment
at the extremes of it's operating envelope.  (This is the LOS test and
the G.958 PBRS/72ones/72zeros/PBRS test.)  IMHO, these are testing not
operating specs.  For arbitrary payloads, there are likely no official Sonet
specs.  You are in the process of making one.

It seems to me that the rules for making a spec for handling a new payload
should be that the new payload should not negatively affect the network any
more than the current official payloads.  IMHO, when transporting
the nasty sequence, your proposal does not meet this criteria.  If it did,
then you would not be talking about envelope edge tests because you would
be in the middle of the envelope like the other payloads.

On another point, you said 'VC4s are interleaved byte by byte'.
Since VC4's are like STC-3c this is true.

This looks like it might not still be true for higher speed circuits.
It looks like SCS-12c's are interleaved in 4 byte chunks.
(This is in figure 5-2 of GR-253-CORE dec-1995. TR-NWT-253 dec-1991 does
not show the figure. Fax maybe?)

So, let me try my question again in your terminology.

The Applicability section says for use 'over high speed private point-to-point'
links. This could either mean single-owner private or multi-owner private, or
both.  The Applicability section goes on to give an example, 'such as
intra-campus single-mode fiber'.  This means single-user is supported but
leaves an ambiguity for the support of multi-owner private links.

What is your intended support level for multi-owner links?
	1) Not supported.
	2) Supported under engineering judgment of user.
	3) Fully compiant and supported.
	4) Other.

Sincerely,
Stuart Venters
(The views expressed do not necessarily reflect those of my employer.)

---

From: [email-masked] (Charles M. Heard)
Date: Mon, 24 Nov 1997 23:50:34 -0800

On 24 Nov 1997 13:26:47 -0800 Tony Li <[email-masked]> wrote,
in reply to [email-masked]'s message of 24 Nov 97 20:34:55 GMT
> consensus and been a forum for one person's agenda.

There certainly was no call for consensus.  For the record:  although I did
participate in the e-mail discussion on the pppsdh list, I take issue with
significant parts of this document, and I do not endorse it.

> Tony

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]