Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
draft-ietf-pwe3-tdm-requirements-08

[Note]: '-------- Original Message --------
Subject: Re: [Fwd: Re: draft-ietf-pwe3-tdm-requirements-07.txt]
Date: Tue, 29 Mar 2005 09:48:08 -0500
From: Russ Housley
To: W. Mark Townsley
References: <4248930B.1030600@cisco.com> Mark: I can live with that wording. Please let me know when the revision is posted, then I will clear the DISCUSS. Russ At 06:28 PM 3/28/2005, W. Mark Townsley wrote: >Hi Russ. Back to the TDM issue again.. Are you satisfied with the text >below enough to remove your DISCUSS?
>
>Thanks,
>
>- Mark
>
>-------- Original Message --------
>Subject: Re: draft-ietf-pwe3-tdm-requirements-07.txt
>Date: Tue, 29 Mar 2005 00:54:46 +0200
>From: Max Riegel
>Organization: --
>To: Stewart Bryant ,        "W. Mark Townsley" >
>CC: Danny McPherson
>References: ><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de> ><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de> ><5.1.1.6.2.20050324153249.01cd1008@139.21.212.200> ><4242FA77.9040703@cisco.com>  ><4243E6AE.1060003@cisco.com>
>
>Stewart,
>
>Your proposal sounds very reasonable and may provide the bit extra
>information Russ is expecting in the security considerations.
>
>Mark, can you verify that Russ is satiesfied with the text proposal:
>
>  "The security considerations in [PWE3-REQ] are fully applicable to the
>  emulation of TDM services. In addition TDM services are sensitive
>  to packet delay variation [section 7.6], and need to be protected
>  from this as a method of attack."
>
>If Russ agrees I would submit an updated version of the TDM-REQ I-D.
>
>Bye
>Max' added by Amy Vezza

[Note]: '-------- Original Message --------
Subject: Re: [Fwd: Re: draft-ietf-pwe3-tdm-requirements-07.txt]
Date: Tue, 29 Mar 2005 09:48:08 -0500
From: Russ Housley
To: W. Mark Townsley
References: <4248930B.1030600@cisco.com>

Mark:

I can live with that wording.

Please let me know when the revision is posted, then I will clear the DISCUSS.

Russ

At 06:28 PM 3/28/2005, W. Mark Townsley wrote:

>Hi Russ. Back to the TDM issue again.. Are you satisfied with the text
>below enough to remove your DISCUSS?
>
>Thanks,
>
>- Mark
>
>-------- Original Message --------
>Subject: Re: draft-ietf-pwe3-tdm-requirements-07.txt
>Date: Tue, 29 Mar 2005 00:54:46 +0200
>From: Max Riegel
>Organization: --
>To: Stewart Bryant ,        "W. Mark Townsley"
>
>CC: Danny McPherson
>References:
><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de>
><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de>
><5.1.1.6.2.20050324153249.01cd1008@139.21.212.200>
><4242FA77.9040703@cisco.com> 
><4243E6AE.1060003@cisco.com>
>
>Stewart,
>
>Your proposal sounds very reasonable and may provide the bit extra
>information Russ is expecting in the security considerations.
>
>Mark, can you verify that Russ is satiesfied with the text proposal:
>
>   "The security considerations in [PWE3-REQ] are fully applicable to the
>   emulation of TDM services. In addition TDM services are sensitive
>   to packet delay variation [section 7.6], and need to be protected
>   from this as a method of attack."
>
>If Russ agrees I would submit an updated version of the TDM-REQ I-D.
>
>Bye
>Max' added by Mark Townsley

[Note]: '
-------- Original Message --------
Subject: Re: [Fwd: Re: draft-ietf-pwe3-tdm-requirements-07.txt]
Date: Tue, 29 Mar 2005 09:48:08 -0500
From: Russ Housley
To: W. Mark Townsley
References: <4248930B.1030600@cisco.com>

Mark:

I can live with that wording.

Please let me know when the revision is posted, then I will clear the DISCUSS.

Russ

At 06:28 PM 3/28/2005, W. Mark Townsley wrote:

>Hi Russ. Back to the TDM issue again.. Are you satisfied with the text
>below enough to remove your DISCUSS?
>
>Thanks,
>
>- Mark
>
>-------- Original Message --------
>Subject: Re: draft-ietf-pwe3-tdm-requirements-07.txt
>Date: Tue, 29 Mar 2005 00:54:46 +0200
>From: Max Riegel
>Organization: --
>To: Stewart Bryant ,        "W. Mark Townsley"
>
>CC: Danny McPherson
>References:
><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de>
><47D438A0510BD611B9470002A58EDAE705C68BE5@mchh2a6e.mchh.siemens.de>
><5.1.1.6.2.20050324153249.01cd1008@139.21.212.200>
><4242FA77.9040703@cisco.com> 
><4243E6AE.1060003@cisco.com>
>
>Stewart,
>
>Your proposal sounds very reasonable and may provide the bit extra
>information Russ is expecting in the security considerations.
>
>Mark, can you verify that Russ is satiesfied with the text proposal:
>
>   "The security considerations in [PWE3-REQ] are fully applicable to the
>   emulation of TDM services. In addition TDM services are sensitive
>   to packet delay variation [section 7.6], and need to be protected
>   from this as a method of attack."
>
>If Russ agrees I would submit an updated version of the TDM-REQ I-D.
>
>Bye
>Max' added by Mark Townsley

[Note]: 'Russ'' DISCUSS point does not seem to have been addressed in the latest rev. Email sent to author/chairs and waiting on reply. Likely move to new ID Needed.' added by Mark Townsley

[Ballot comment]
Reviewed by Elwyn Davies, Gen-ART

The number of editorial comments is rather high for letting it go.... but none of them seem dramatic. Review in comment log.

[Ballot comment]
Reviewed by Elwyn Davies, Gen-ART

Review:
This document appears to be almost ready for Informational.  It is an extension
of RFC3916

S6.1: Worth making clear these are additional qualifications or applicability of
the PWE3-REQ requirements.  Not all of the points are actually phrased as
requirements which is a little confusing.  Notably 2/1, 3, 4 and 5.

I suspect the combination of the second part of 7.3.1 (2) on packet arrival time
estimation, 7.8 on congestion control and 7.9 on fault detection mandate
something rather better than a generic packet switched Internet, and may or may
not be realistic!

Editorial nits:
Title/Abstract/s1: It would be useful to put the definitions of the
abbreviations PSN, PDH, SONET, SDH and PWE3 in Section 1 and leave them out of
the title and (maybe) the abstract.

S1.2, para 3: => This also includes a pointer based mechanism for carrying
  payload asynchronously.  ?? s/payload/payloads/

S2: The acronym PW is not defined.

S3: => However some terms and acronyms are specific in conjunction with the
  TDM services.  Maybe: s/some terms..conjunction/some specific terms and
acronyms are used in conjunction/

S6.1:  The second level numbered lists might be better with letter labels.

S6.1, bullet 2, sub-bullet 3: The acronym NSP is not defined.

S7.1: Acronym AC is not defined.

S7.5, bullet 2: s/edge- to-edge/edge-to-edge/

S8: This is (still) poorly phrased.  Suggest replacing with:
The security considerations in [PWE3-REQ] are fully applicable to the emulation
of TDM services, but there do not appear to be any additional considerations to
take into account.

S9.1: I have difficulties with Informational documents having Normative
references but [PWE3-REQ] has them…

[Ballot discuss]
The Security Considerations say:
  >
  > The security considerations listed in [PWE3-REQ] fully cover also to
  > the emulation of TDM circuits.
  >
  The Security Considerations in [PWE3-REQ] do not address packet delay,
  which is clearly important in the emulation of TDM.  At a minimum, a
  pointer to section 7.6 needs to be added to the Security Considerations.

From: Thomas Narten
To: Stewart Bryant , Danny McPherson
cc: maximilian.riegel@siemens.com
Date: Tue, 25 Jan 2005 12:45:18 -0500
Subject: AD review of draft-ietf-pwe3-tdm-requirements-05.txt

I've completed my review of this document. I don't see any big issues,
but I'm also not sure quite what this document is supposed to be
saying. Is there something in here you are worried is controversial?

The only thing that I think needs fixing (or I'd like to better
understand) is the wording surrounding "interworking"; this is a
hot-button issue  in the IESG, and as such, the current (unclear IMO)
wording will raise questions. Better to deal with that up front.

Finally, who is/are the real authors/editors of this? Are there really
6 authors? (the document seems to say there is one editor on the cover
page, but later in the document they are listed as "authors".)

Thomas

Expand acronyms in abstract, remove references.

>    TDM that consists of a raw bit-stream of rate defined in [G.702],
>    with all bits are available for payload.

s/are//

>    TDM with one ore more levels of structure delineation, including

s/ore/or/

>    transported over the MPLS network (specifically, the synchronization

s/MPLS/PSN/ ? (Isn't this generic technology?)

>    Structure-Aware Transport:
>    Transport of structured TDM taking at least some level of the
>    structure into account. In structure-aware transport there is no
>    guarantee that all bits of the TDM bit-stream will be actually
>    transported over the MPLS network (specifically, the synchronization
>    bits and related overhead may be stripped at ingress and usually will
>    be regenerated at egress), or that bits transported are always
>    situated in the packet in their original order.

Bit order can be changed? But then restored at other endpoint?

>    TDM networks employ CAS or CCS signaling to supervise and advertise

expand CAS and CCS on first use?

>    Enc
>      PSN-bound interface of the PW
>
>    Dec
>      CE-bound interface of the PW. It contains a compensation buffer

For both of these, what does "enc" stand for or expand to? is it a
shorthand for something?

> 7.1  Interworking
>
>    1.  The emulation MUST support network interworking between ACs of
>        the same type (see Section 5) and, wherever appropriate,
>        bit-rate.
>
>    2.  The encapsulation layer SHOULD remain unaffected by specific
>        characteristics of connection between the ACs and PE devices at
>        the two ends of the PW.

What exactly must be "interworked"?

> 8.  Security Considerations
>
>    The security considerations listed in [PWE3-REQ] fully apply also to
>    the emulation of TDM circuits.

Need to say what other issues apply just for TDM, or if none, just say
that.

Cover lists Riegel as "editor", but later the document says:

> Co-Authors
>
>    The following are co-authors of this document:
>
>    Sasha Vainshtein  Axerra Networks
>    Yaakov Stein      RAD Data Communication
>    Prayson Pate      Overture Networks, Inc.
>    Ron Cohen          Lycium Networks
>    Tim Frost          Zarlink Semiconductor

Please clarify (best to list the significant contributors in a
"contributers section", where there contributions can be laid out in
more detail.)