Subject: RE: draft-ietf-pwe3-sonet-05.txt - Last Call

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 11 May 2004 14:42:09 +0300

David, 

> The difference between SONET and the pure TDM case is that a 
> SONET signal may contain significant portion of unequipped 
> payloads, so network wide with large number of connections 
> you can take advantage of the statistical saving. For AIS, I 
> agree that the saving is non-significant but once the 
> mechanism is there why not use it?

Yes, I know that you do "DBA" for the unequipped case as well.

This case obviously doesn't occur for the low-rate emulation,
which is the context I was refering to.

However, for the SONET case, do you envision the unequipped
payload to be a transient state, or a particular SONET PW will run this
way
all the time?

Y(J)S

---

From: David Zelig <[email-masked]>
Date: Tue, 11 May 2004 16:16:26 +0200

> payload to be a transient state, or a particular SONET PW 

Not all the time, but for significant portion of the time - on a large
enough network (or more precisely large enough number of connections) you
may gain some BW for other type of services.

David

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Mon, 10 May 2004 11:24:05 -0500

Stewart, Ron, all,

Here's some minor edits to align with T1X1.5 updates to T1.105 (aligning with 2001 version) and ITU-T updates:

6 SONET/SDH Maintenance Signals
- as multiple functionalities (LTE, PTE, etc) may be supported at a NSP, it may help clarify to add,
"Failure detection capabilities and performance monitoring capabilities will be dependent on the NSP functionality e.g. LTE, PTE, Tandem Connection Monitoring (refer to [G.707]), or Non-intrusive Monitoring (intermediate connection monitoring)."

6.1.1 AIS-P/V Indication
- minor edits on included defects, and suggest to say "for example" as SDH and SONET differ on AIS insertion:
"The mapping of SONET/SDH failures into the PATH/VT layer is considered part of the NSP function, and is based on the principles specified in [GR253], [SONET], [G.707], [G.806], and [G.783]. Should for example the Section Layer detect a Loss of Signal (LOS) or Loss of Frame (LOF) or Section Trace Mismatch (TIM) conditions, it sends AIS-L up to the Line Layer. If the Line Layer detects AIS-L or Loss of Pointer (LOP), it sends AIS-P to the Path Layer. If the Path Layer detects AIS-P or UNEQ-P or TIM-P or PLM-P and is terminated at the NSP (i.e. PTE), it sends AIS-V to the VT Layer. Note, a non-intrusive monitor only detects failures, it must not do AIS insertion."

6.1.2 Unequipped Indication
- minor edit to add test signal differentiation:
"The declaration of SPE/VT unequipped MUST conform to [GR253], [SONET], or [G806] and [G783]. [GR253] detection is based on the presence of an unequipped Signal Label. [SONET]/SDH detection is based on the presence of an unequipped Signal Label and an all zeros Trail Trace Identifier (TTI) to distinguish the presence of an unequipped signal or a [SONET] test signal (Supervisory-Unequipped [G707])."

- suggest to remove the next paragraph "STS PTE shall detect an STS Path Unequipped (UNEQ-P) defect..". The detection/clearing definition used for the UNEQ defect is based on GR253, G783 has a different defect detection. As AIS defect detection is also not included in the draft, the first paragraph referring to the appropriate standards is sufficient.

9.1 Near-end Performance Monitors
- suggest adding a CEP-NE failure similar to the CEP-FE failure (section 9.2),
"CEP Near-end (CEP-NE) failure is declared after 2.5 +/- 0.5 seconds of Type 2 CEP defect, and cleared after 10 seconds free of CEP defect state. Sending notification to the OS for CEP failure is local policy."

10 Payload Compression Options
- suggest adding a sentence on use of DBA (at end of 2nd paragraph) to clarify:
"The use of DBA will be dependent on network architectures e.g. support of Tandem Connection Monitoring, test signals."

Regards,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Stewart Bryant
Sent: Tuesday, April 27, 2004 8:25 AM
To: Ron Cohen
Cc: PWE3 (IETF)
Subject: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call

This formally starts the two week Last Call process.

Last Call will end Wednesday 12th May

- Stewart

Ron Cohen wrote:
> Dear PWE3ers
> 
> The updated CEP draft is now available at
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-05.txt
> 
> Below please find the list of modification made since the 04 version.
> The authors believe the draft is now ready for last call. 
> 
> 1. Section 11: Signaling of CEP pseudo-wires: Added mandatory/optional
> attribute for each parameter. Clarified which error codes are returned
> when signaling fails and referenced the IANA draft for actual values.
> Added a table of values for the CEP/TDM bit rate parameter. Fixed
> language.
> 
> 2. Draft 04 appendix B discussing actual payload sizes of fractional
> payload compression modes was folded into section 10. This removed
> duplication of data and clarified in-context the actual payload sizes.
> Verify that the draft body (without appendixes) includes all information
> required for implementation and interoperability.
> 
> 3. Removed non-ASCII characters. Aligned formats and language (DS-3, DS3
> and T3 to T3). Removed empty open issues section. Added VT payload size
> table. Updated authors contact addresses. 
> 
> 4. Security section rewritten
> 
> Thanks
> Ron & Co-authors
> 
> Ron Cohen
> CTO
> Lycium Networks 
> Mobile: 650.823.7672
> Mobile:  +972.55.245.104
> Tel:  650.234.4010
> Fax:  650.854.8183
> 
> ===================================================== 
> This email message and any files transmitted with it contain
> confidential information intended only for its addressee(s). If you are
> not the addressee of this message, any reading, disclosure, copying,
> printing, distribution or forwarding by you of this message or its
> content or attachments is strictly forbidden. In such case, please
> notify us immediately by replying to this message or by calling
> 650.234.4010 and delete the message from your computer. Thank you.
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 11 May 2004 09:44:21 +0300

Ron/Andy, 

I have a question about the original of the term "DBA" you use in the
draft.

Earlier versions had a reference after the first use of the term
([CEP-SPE]),
but unfortunately this reference didn't resolve.
It has since been removed altogether.

Was this term previously used in a similar context
or was is sui generis ?

The reason I ask is that to me "Dynamic Bandwidth Allocation"
sounds much more like LCAS 
than a mechanism that simply suppresses transmission 
of a payload known to be meaningless.  

In SAToP, CESoPSN and TDMoIP
we have a similar optional mechanism whereby bandwidth 
can be conserved when the TDM input is meaningless,
but we avoid such an impressive nomenclature.

Actually, I believe that the entire concept of conserving bandwidth 
by suppressing defective TDM payloads is a bit suspect.

Carrier class TDM has "five nines" reliability, 
so the amount of BW conserved will certainly be below 
one tenth of one percent. This can hardly be called
significant bandwidth conservation,
let alone dynamic bandwidth allocation.

For enterprise TDM the "network"
is often a single link, so its chance of failure is equally small.

So why do we bother?

Y(J)S

---

From: David Zelig <[email-masked]>
Date: Tue, 11 May 2004 10:21:55 +0200

Yaakov,
The difference between SONET and the pure TDM case is that a SONET signal
may contain significant portion of unequipped payloads, so network wide with
large number of connections you can take advantage of the statistical
saving. For AIS, I agree that the saving is non-significant but once the
mechanism is there why not use it?

David

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, May 11, 2004 8:44 AM
> To: Ron Cohen; Andrew G. Malis
> Cc: PWE3 (IETF)
> Subject: RE: [PWE3] draft-ietf-pwe3-sonet-05.txt - Last Call
> 
> 
>  Ron/Andy, 
>

---

From: [email-masked]
Date: Tue, 11 May 2004 11:30:04 +0100

Hi Yaakov....small remark (in support) below.  regards, Neil

> Yaakov Stein
> Sent: 11 May 2004 07:44
NH=> I agree.  I think you would find others (eg Maarten) who would also agree....probably even more strongly than I do.  The rationale you give in the para below is compelling IMO.

Aside - I also think that the compression of clients is something to be avoided in general because I do not believe the benefits (BW savings) outweigh the (management) consequences of violating the architectural requirement for client/server independence.  Real networks don't run near their congestion-knee over the vast majority of their life, ie planning cycles are relatively long (and these increase as we move towards the duct), and one can't in general exceed ~70% load at the end of the current planning cycle for resilience reasons, noting that this must include the effects of daily peak/mean variation too.  And if you start stacking layer networks (which one invariably does) the efficiency fill of the top layer can be quite low, eg 4 nested layer networks each at 70% load (ie remarkably high) = 24% max fill.  As a general observation, we should be looking to use BW wisely to remove complexity.....we should not be seeking to add complexity (read 'opex/capex' costs) to save small amounts of BW.  This also has implications wrt the real benefit of having lots of QoS classses too and ensuring consistent/meaningful service differentiation over a large range of load points....but that is another story.