Liaison Statement: LS214 - MPLS-TP survivability framework draft reviewed (ref # 28.05)
|From Contact||Stewart Bryant|
Thank you for your further liaison discussing our disposition of your comments on draft-ietf-mpls-tp-survive-fwk. As you will be aware, this document is now in an advanced state in the IETF process. We have examined your comments and respond as follows: Comment 1 No further action is required Comment 2 (2.1) Similar text to that which you requested has been added to the end of Section 4.3.2 (2.2) No further action is required Comment 3 (3.1) Text to clarify that this case applies only to linear protection has been added. A forward pointer to section 4.8 has been added for ring protection. (3.2) The indicated document is present as an Informative reference and is in accordance with normal IETF practice. It is our understanding from reading A.5 and http://www.itu.int/dms_pub/itu-t/oth/3E/01/T3E010000010001MSWE.doc that you are able to make bibliographic reference to Internet-Drafts that are work in progress. Further, it is our understanding that only Normative references are cascaded. Comment 4 This substantial proposal of new text has been received too late in the IETF review cycle to be included. This text would need to be introduced via a new Internet-Draft. Comment 5 (5.1) No further action is required (5.2) The current document shows RFC4427 as a Normative reference and G.808.1 as an Informative reference. This is appropriate for how they are used in this document and this has been confirmed through IETF consensus. If the ITU-T believe that there is a discrepancy between RFC4427 and G.808.1, we suggest that this should be addressed by proposing revised a revised version of RFC4427. Comment 6 No further action is required Comment 7 No further action is required Comment 8 Thank you for highlighting the continued confusion over the word "level". We think that your proposed change to "type" does not convey the different qualities of recovery, and may lead to confusion with "mechanism". We have changed to use the word "grade". This change can be seen in sections 1.4, 4, 4.1.1, 4.3, 4.3.2, 4.4.1, 4.4.2, 4.4.3, 4.6, and 4.9.1. Comment 9 No further action is required Comment 10 Please see resolution for comment 3 Comment 11 This reference to draft-ietf-mpls-tp-linear-protection has been retained (see resolution for comment 3). This reference documents where the solution that will be described, but, within the IETF process, makes no pre-judgment about the explicit solution. Please note also that the solution documented in the draft-ietf-mpls-tp-linear-protection can be changed at any time by working group consensus. Comment 12 No further action is required General Comments No further action is required New Comment A The current IETF consensus on this document is that the term "span" is as defined in this document and is distinct from a "link" as explained in this document. We are therefore unable to make this change to this document at this stage in the process. We hope that the Editors of draft-ietf-mpls-tp-rosetta-stone will bring that document into line with these definitions. New Comment B The change has been made as suggested. New Comment C The text has been changed to highlight that segment recovery (section 4.2.2) is not a form of span recovery. New Comment D Text has been added to section 4.3 along the lines of your suggestion. New Comment E This document is not a requirements document and sets no MPLS-TP requirements. There is, therefore, no need for any change. Also it is now too late in the IETF process to make any movement between normative and non-normative. New Comment F It looks as if the correct reference is to section 4.4.3. This text has been clarified. New Comment G This is not new text - it was present in the 00 version of this document. The text has been previously reviewed by the ITU-T experts and there is no scope for further review. New Comment H This proposal for the removal of a significant piece of text that has been present since the 00 version of the document comes after IETF consensus and is therefore too late in the IETF process for this change to be considered. Please note, however, that section 6.4 makes explicit, normative reference to OAM Framework, and that the removal of a section on OAM would give the impression that the various functions can be performed through the management plane and the control plane, but not using OAM. Such an impression would not be desirable.