Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
draft-ietf-pwe3-tdm-control-protocol-extensi-07

[Ballot comment]
Review by Christian Vogt:

This Internet draft specifies the establishment of TDM pseudowires
over MPLS.  It defines the usage of existing protocols and information
elements for this purpose, as well as required extensions.

The document is complete in my non-expert view, although it should be
revised for clarity.  While likely understandible for all pseudowire
specialists, readers not directly involved in this engineering area
may need more guidance.  This is editorial only.  A few suggestions:

- Introduction:  The introduction mixes the description of the
  document scope, items not in scope of the document, and a survey
  of related documents.  Consider restructuring.  Also, for
  non-experts in things pseudowires, adding a problem statement
  would be helpful.

- Section 2:  The key message of this section is that certain existing
  pseudowire FECs can be reused for TDM pseudowire establishment,
  with some restrictions in the parameters used.  The message is
  somewhat lost throughout the section.  Suggestion: State this
  clearly already at the beginning of the section.

- Section 3.1:  The unit of interface parameter length in the table is
  different than the unit used in the text.  This is confusing
  because the table does not state its unit.  Suggestion: State the
  unit in the table and use the same unit both in the table and in
  the text.

- Section 3.2:  The terms "SAToP" and "CESoPSN" are used to refer to
  groups of pseudowire types.  These terms haven't been defined
  before.  So to avoid confusion or misunderstanding, I suggest to
  explicitly name the pseudowire types in question at this point. (I
  do understand that "SAToP" refers to pseudowires 0x0011, 0x0012,
  0x0013, 0x0014, and that "CESoPSN" refers to pseudowires 0x0015
  and 0x0017.  But I think it should be clarified.)

- Section 3.3 specifies for which pseudowire types the CEP/TDP Bit
  Rate parameter may be omitted (item 1 in numbered list).  Suggest
  to name the affected pseudowire type codes, perhaps in
  parentheses, just to avoid misunderstandings.

- Section 8:  The security considerations do not consider
  vulnerabilities that non-perfect emulation of a particular link
  layer (TDM, in this case) could introduce.  Legacy applications
  may rely on TDM-specific properties that the emulated version over
  MPLS does not provide.  If there are no such vulnerabilities,
  which seems likely, then this should be state.

IANA Last Call comments:

Upon approval of this document, IANA will replace the current
references for the assignments below with references to this
document:

Registry Name: Pseudowire Interface Parameters Sub-TLV type Registry

Parameter ID Length Description Reference

--------- --------- -------------------------------------- ---------
0x0E 4 Number of TDMoIP AAL1 cells per packet [TDMctrl]
0x10 4 TDMoIP AAL1 mode [TDMctrl]
0x11 8 or more TDMoIP AAL2 Options [TDMctrl]

Proto statement by Stewart Bryant:

The PWE3 Chairs would like to request Standards Track publication of this document.

(1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Stewart Bryant (stbryant@cisco.com) is the Shepherd. I have reviewed the document and it is ready for publication.

    (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

This document (-04 revision) has been reviewed by the WG. A detailed list of all of this issues and the resolution was presented to the WG and published as (-05) and a minor editorial was published one week later (-06) which is the version that we propose to advance.
The proposed advancement of this document was discussed at the last IETF.

I have no concerns about state of readiness of this document, although it needs a minor edit to change the affiliation of one of the authors which we can do as an editor's note.

    (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

I have no concerns regarding the requirement for further review.

    (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.

I have no specific concerns about this document, nor are there concerns that should be conveyed to the IESG or Responsible AD.

    (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document is fully understood and supported by the PWE3 WG.  There is no contention as to whether this work provides utility and it is generally supported across the WG.

    (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.
          (It should be in a separate email because this questionnaire
          is entered into the ID Tracker.)

No one has indicated to the WG chairs or WG mailing list that they have intentions of appealing any proposed publication of this document.

    (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

I have reviewed nits output on IETF tools, and there is nothing that should prevent this document advancing.

    (1.h)  Has the document split its references into normative and
          informative?

Yes.

          Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All references are RFCs (two are listed under draft names, but have recently advanced. This will be fixed in the edit phase).


    (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggested a
          reasonable name for the new registry?  See
          [I-D.narten-iana-considerations-rfc2434bis].  If the document
          describes an Expert Review process has Shepherd conferred with
          the Responsible Area Director so that the IESG can appoint the
          needed Expert during the IESG Evaluation?


Yes.

Also note that we have been requested by the authors to provide early allocation of three Interface Parameters Sub-TLV type values and I propose that we should do this.


    (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Not applicable

    (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Writeup?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

This document defines extension to the PWE3 control protocol [RFC4447]
and PWE3 IANA allocations [RFC4446] required for setup of TDM (RFC4553,
RFC5086 and RFC5087) pseudowires in MPLS networks.

            Working Group Summary

This document has been reviewed by the experts in the PWE3 WG and there are no outstanding issues.

          Protocol Quality

This is a simple extension to RFC4447 to allow the provisioning of some additional (well known) PW types using the already established rules and procedures.


          Personnel
              Who is the Document Shepherd for this document?

Stewart Bryant (stbryant@cisco.com)

              Who is the Responsible Area Director?

Mark Townsley (townsley@cisco.com)