Subject: TDM over IP - Last Call

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Mar 2005 18:59:55 +0000

This is to start the last call process for

TDM over IP
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-03.txt

Last Call will Finish 28th March 2005

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Mar 2005 19:07:04 +0000

Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
<draft-ietf-pwe3-vccv-04.txt>

Stewart

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Mar 2005 18:12:17 +0200

Stewart, Yaakov and all,
Please see belowsome comments to the draft in question.

1. SAToP Applicability and TDMoIP
=================================

About half a page in the Into section of the draft deals with the 
SAToP applicability issues. I am not sure that this is the
correct place to do so, especially since the SAToP draft itself
contains an Applicability Statement section. 

In addition, some statements in this part of the text are inaccurate. 
E.g., the following statement found in the draft:

<quote>
   Except for the shortest of packets, this ("all ones" - Sasha)
   pattern is interpreted by the TDM end equipment as an AIS 
   indication
<end quote>

is in explicit contradiction with the AIS definition for T1 (DS1)
circuits as given in ANSI T1.107 and/or G.775.
Both these documents define AIS condition of a DS1 circuit as a 
condition when more than 99.99% of "1" bits have been received 
during a configurable period of time T, where T is in the range from
3 to 75 ms. 

I suggest to remove this part of the draft altogether
replacing it (if deemed necessary) to a refrence to the 
Applicability Statement section of the SAToP draft.

2. TDMoIP over "Pure Ethernet"
==============================
Section 3.4 of the draft discusses encapsulation that uses "Pure
Ethernet" as the PSN. I do not question usefulness of such an
mechanism but, IMO, it is out of scope of the PWE3 as defined 
in its current Charter (which, AFAIK, does not mention
Ethernet as a PSN). Of course, this is rather a technicality.
However, I suggest removing this part of the text (if necessary,
an explicit reference to the appropriate sections of the
Metro Ethernet Forum standard MEF 8 can be used).

3. TDM Defect Handling Issues
=============================

This topic is discussed at length in Section 5. However, some 
issues seeminly have ben missed by the authors as described below:

The draft states that one of the options for handling a local TDM 
defect by a PSN-bound GW is (in addition to setting the L flag) to
fill the payload with the "trunk conditioning" code. It even states
that this option is mandatory if "channels taken from several TDM 
PWs are combined by the TDM-bound GW into a single TDM circuit".

At the same time the dratf states that 

<quote>
   When GW2 receives a local defect indication without "M"-field
   modification, it forwards (or generates if the payload has been
   suppressed) AIS or trunk conditioning towards ES2 (the choice between
   AIS and conditioning being preconfigured).  
<end quote>

IMO the latter statement is absolutely correct, but makes the requirement
to fill the payload with the "trunk conditioning" at GW1 meaningless.
In addition, GW1 does not have to know whether GW2 combines channels
taken from several TDM PWs into a single TDM circuit or not...

I suggest removing the requirement to fill the payload with trunk
conditioning at the PSN-bound GW (this may still be a useful
implementation trick).

Further in this section, the draft proposes to set a single bit R
in the control word to indicate two different conditions:
- RDI received from the local TDM network
- packet loss condition in the reverse direction of the PW.

This proposal precludes effective single-ended monitoring of PW
defects (the device receiving packets marked with the R bit set cannot
distinguish between unidirectional packet loss in the revers direction
and purely TDM problems in the remote TDM network) and contradicts the
already approved ITU-T Recommendation Y.1413.

I suggest to use different encodings of the TDM RDI and packet loss
conditions that are consistent with Y.1413 and MEF 8. 

Last, but not least, the draft states that

<quote>
	When failure is declared the PW MUST be withdrawn.
<end quote>

I am not sure I understand the intention of the authors as
"PW withdrawal" is not defined anywhere (AFAIK).
The neares thing to that I can think about is the PW Label
withdrawal. If thhis is what the authors have in mind, the
requirement seems to be in contadiction with the latest PWE3
Control Protocol draft (not to mention the situations where 
no control protocol has been defined).

IMO, at least a clarification of the authors' intention
is required.

4. TDMoIP Connectivity Verification
===================================

The situation described in Appendix D.1 is, IMO, only applicable
to "pure Ethernet" networks (IP or MPLS networks do not flood
packets if they do not know how to reach their destination).
As I have mentioned already, pure Ethernet seems to be out of scope
of PWE3.

At the very least, appropriate qualifiers should be applied, and
the proper terms used (e.g., the term "routing tables" in the
context of D.1 is not, IMO, appropriate).

5. Miscellaneous
================

The draft contains lots of text descibing things that can be found
elsewhere (e.g., the structure of IPv4 header, UDP header, RTP header,
MPLS label stack entry, IEEE 802.1q VLAN Tag). I think that most 
of these descriptions can be safely replaced by the appropriate 
references. This would make the draft shorter and more readable.

Hopefully these comments will be useful.

Regards,
                                  Sasha Vainshtein
email:                         [email-masked] <mailto:[email-masked]> 
phone:                       +972-3-7569993 (office)
fax:                            +972-3-6487779
mobile:                      +972-52-8674833 

> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Friday, March 04, 2005 9:00 PM
> To: pwe3
> Subject: [PWE3] TDM over IP - Last Call
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Mar 2005 21:43:09 +0200

> About half a page in the Into section of the draft deals with 
> the SAToP applicability issues. I am not sure that this is 
> the correct place to do so, especially since the SAToP draft 
> itself contains an Applicability Statement section. 

I AM sure.
The question is constantly being brought up.
We have a stadards track solution (SAToP),
so why do we need 2 informational ones?
The question has been asked so many times
that it is required to clearly state somewhere
why the structure-aware methods are needed.

If you want to add an applicability statement to SAToP
stating when it SHOULD NOT be used
(i.e. a non-applicability statement)
then I would go along. But I think that
logically the alternative to a standard should
be the one to explain why it exists.

> is in explicit contradiction with the AIS definition for T1 
> (DS1) circuits as given in ANSI T1.107 and/or G.775.

Sorry, all I said is that G.826 states EXPLICITLY that ANY detected
AIS triggers a severely errored second. I did not state how AIS
detection is triggered. For E1 64 bytes of ones is enough, which
indeed corresponds to all but the smallest of packets.

> Applicability Statement section of the SAToP draft.

I disagree, see above.

> Section 3.4 of the draft discusses encapsulation that uses 
> "Pure Ethernet" as the PSN. I do not question usefulness of 
> such an mechanism but, IMO, it is out of scope of the PWE3 as 
> defined in its current Charter (which, AFAIK, does not 
> mention Ethernet as a PSN). Of course, this is rather a technicality.
> However, I suggest removing this part of the text (if 
> necessary, an explicit reference to the appropriate sections 
> of the Metro Ethernet Forum standard MEF 8 can be used).

This section is indeed out of scope, being a non-IETF PSN.
However, in an informational draft I can add addition features.

> issues seeminly have been missed by the authors as described below:
> 
> The draft states that one of the options for handling a local 
> TDM defect by a PSN-bound GW is (in addition to setting the L 
> flag) to fill the payload with the "trunk conditioning" code. 
> It even states that this option is mandatory if "channels 
> taken from several TDM PWs are combined by the TDM-bound GW 
> into a single TDM circuit".
> 
> IMO the latter statement is absolutely correct, but makes the 
> requirement to fill the payload with the "trunk conditioning" 
> at GW1 meaningless.
> In addition, GW1 does not have to know whether GW2 combines 
> channels taken from several TDM PWs into a single TDM circuit 
> or not...

Sorry, I don't agree. It specifically says that one option is for
GW2 to FORWARD, and this can only be done if conditioning
is first placed there.

> 
> I suggest removing the requirement to fill the payload with 
> trunk conditioning at the PSN-bound GW (this may still be a 
> useful implementation trick).

I suggest leaving it there, as the decision as to whether to generate
AIS or conditioning should be done at the point where the physical layer
fault is detected.

> Further in this section, the draft proposes to set a single 
> bit R in the control word to indicate two different conditions:
> This proposal precludes effective single-ended monitoring of 
> PW defects (the device receiving packets marked with the R 
> bit set cannot distinguish between unidirectional packet loss 
> in the revers direction and purely TDM problems in the remote 
> TDM network) and contradicts the already approved ITU-T 
> Recommendation Y.1413.

It is, however, aligned with ITU draft recommendation dubbed Y.17tdm.
Y.1413 will be updated to remove any inconsistencies.

> 
> I suggest to use different encodings of the TDM RDI and 
> packet loss conditions that are consistent with Y.1413 and MEF 8. 

Unfortunately, the OAM experts don't agree with that technique.

> IMO, at least a clarification of the authors' intention is required.

I can add the word "label" if this makes it clearer for you.
However, I am not sure what contradiction you have in mind here.

> The situation described in Appendix D.1 is, IMO, only 
> applicable to "pure Ethernet" networks (IP or MPLS networks 
> do not flood packets if they do not know how to reach their 
> destination).
> As I have mentioned already, pure Ethernet seems to be out of 
> scope of PWE3.
> 
> At the very least, appropriate qualifiers should be applied, 
> and the proper terms used (e.g., the term "routing tables" in 
> the context of D.1 is not, IMO, appropriate).

Already discussed above.
Actually the techique is also for UDP/IP.

> 
> 5. Miscellaneous
> ================
> 
> The draft contains lots of text descibing things that can be 
> found elsewhere (e.g., the structure of IPv4 header, UDP 
> header, RTP header, MPLS label stack entry, IEEE 802.1q VLAN 
> Tag). I think that most of these descriptions can be safely 
> replaced by the appropriate references. This would make the 
> draft shorter and more readable.

The document is meant to be understood as-is, 
without having to refer to too many other documents.

If there is something WRONG please tell me.

---

From: [email-masked]
Date: Fri, 11 Mar 2005 17:07:14 -0000

Colleagues,

Below are some comments related to synchronisation & TDM over IP that I have been asked to pass onto the list on behalf of the synchronisation experts in BT...

Thanks
Ben

===
1) Introduction paragraph 2. TDM circuits are not the same rate in both directions. They are plesiochronous in each direction, but MAY be the same. This is a classic CE error.

2) 6.2 Timing Recovery paragraph 1. TDM networks are NOT inherently synchronous. Most private circuits operate at +/-50ppm, which only requires a crystal as a source, and not a G.811 source. TDM used for PSTN transport IS synchronous to a G.811 source.

3) 6.2 Timing Recovery paragraph 3. Clock provided by some means other than the PSN. Like what? I've just provided a packet circuit to a customer site and hope he has a suitable local clock! 

4) 6.2 Timing Recovery paragraph 4. Stating that FFL's and PLL's are well suited to the task maybe OK on a small scale but the cost of filtering for Adaptive increases dramatically with the increased cost of lower noise VCO's the more you try to filter. Also the buffer has to increase in size increasing both cost and, more importantly latency. This draft doesn't really link these two conflicting requirements.

5) 6.2 Timing Recovery end of paragraph 4. "For some applications, more stringent Jitter and Wander tolerances may be required." Like what? It's debatable whether we can meet the current requirements with this, so how much more stringent are we looking at?

6) Should this draft be liaised to SG15 as they are the TDM experts and can probably assist with it?
===

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 14 Mar 2005 09:55:18 +0200

Ben, 

Here are answers to your comments:

> 1) Introduction paragraph 2. TDM circuits are not the same 
> rate in both directions. They are plesiochronous in each 
> direction, but MAY be the same. This is a classic CE error.

The wording should probably be
"the same nominal rate in both directions";
at least that was the intent.

> 
> 2) 6.2 Timing Recovery paragraph 1. TDM networks are NOT 
> inherently synchronous. Most private circuits operate at 
> +/-50ppm, which only requires a crystal as a source, and not 
> a G.811 source. TDM used for PSTN transport IS synchronous to 
> a G.811 source.

TDM networks are inherently synchonous to SOME source,
and carrier operated networks are traceable to a G.811 source.

> 3) 6.2 Timing Recovery paragraph 3. Clock provided by some 
> means other than the PSN. Like what? I've just provided a 
> packet circuit to a customer site and hope he has a suitable 
> local clock! 

By "some" means could be a local rubidium clock,
a GPS derived clock, and many other alternatives.
Since in many cases all the customer wants is "stratum 3"
behavior, the local source may just be a TCXO.

Please do not confuse all customers with carriers.

In fact, it was you who insisted at the ITU that this work is
primarily focused on enterprise applications, and not for carriers.
So why are you insisting on carrier-quality clocking now?
 
> 4) 6.2 Timing Recovery paragraph 4. Stating that FFL's and 
> PLL's are well suited to the task maybe OK on a small scale 
> but the cost of filtering for Adaptive increases dramatically 
> with the increased cost of lower noise VCO's the more you try 
> to filter. Also the buffer has to increase in size increasing 
> both cost and, more importantly latency. This draft doesn't 
> really link these two conflicting requirements.

I am not sure what you are trying to add here.

FLLs or PLLs may be used to track time sources,
and in fact are the basis of SEC and SSU methods
used by carriers. 

Yes, if we want more stringent wander behavior 
we have to use a loop filter with a smaller bandwidth, 
and thus it takes longer to converge.

No, that does not translate to longer latency,
as the buffer size is determinted by the PDV JITTER
not the wander.

However, there ARE many trade-offs in design of clock
recovery mechanisms. That does not mean that these mechanisms
do not work. It only means that you have to know how
to implement them.

> 5) 6.2 Timing Recovery end of paragraph 4. "For some 
> applications, more stringent Jitter and Wander tolerances may 
> be required." Like what? It's debatable whether we can meet 
> the current requirements with this, so how much more 
> stringent are we looking at?

More stringent means for example the requirements
of modern cellular systems, that in addition to wander masks
and jitter tolerances, have absolute accuracy requirements
(for example 50ppb).
 
> experts and can probably assist with it?

This has been liased with SG13 where the Y.1413 work
was done (which has an entire section on clocking scenarios).
SG13 did send and receive liasons from the G.pactiming
group in SG15.

Y(J)S