Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks
RFC 5287
Yes
(Mark Townsley)
No Objection
Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert
No Objection
Mark Townsley Former IESG member
Yes
Yes
()
Unknown
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-06-19)
Unknown
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.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
(2008-06-18)
Unknown
Section 3.6: bit diagram has type 0x0F, IANA Considerations text suggests value 0x11? Needs a normative reference to RFC 2119.
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
()
Unknown