Reviewer: Mahesh Jethanandani Review result: Has Issues {\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf200 {\fonttbl\f0\fswiss\fcharset0 Helvetica;\f1\fmodern\fcharset0 Courier;} {\colortbl;\red255\green255\blue255;\red0\green0\blue0;} {\*\expandedcolortbl;;\cssrgb\c0\c0\c0;} \margl1440\margr1440\vieww10800\viewh8400\viewkind0 \deftab720 \pard\pardeftab720\partightenfactor0 \f0\fs24 \cf0 \expnd0\expndtw0\kerning0 I have reviewed this document as part of the Operational directorate\'92s\'a0ongoing effort to review all IETF documents being processed by the IESG. \'a0These\'a0comments were written with the intent of improving the operational\'a0aspects of the IETF drafts. Comments that are not addressed in last call may be\ included in AD reviews during the IESG review. \'a0Document editors and\'a0WG chairs should treat these comments just like any other last call\'a0comments.\ \ Document reviewed: \'a0draft-ietf-bess-fat-pw-bgp-03\ \ Summary: \ \ \pard\pardeftab720\sl300\partightenfactor0 \cf2 \outl0\strokewidth0 \strokec2 This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures. \f1\fs26\fsmilli13333 \ \pard\pardeftab720\partightenfactor0 \f0\fs24 \cf0 \outl0\strokewidth0 \ Document Status:\ \ Has Issues\ \ Comments:\ \ The following comments look at the document both from an operational perspective as well as a management perspective. \ \ Operational Considerations:\ \ Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation.\ \ The draft defines an OPTIONAL mode of operation. An OPTIONAL definition, per RFC 2119 is:\ \ \pard\pardeftab720\sl280\partightenfactor0 \f1 \cf2 \outl0\strokewidth0 \strokec2 An implementation which does not include a particular option MUST be\ prepared to interoperate with another implementation which does\ include the option, though perhaps with reduced functionality. In the\ same vein an implementation which does include a particular option\ MUST be prepared to interoperate with another implementation which\ does not include the option\ \pard\pardeftab720\partightenfactor0 \f0 \cf0 \outl0\strokewidth0 \ The draft needs to describe what the reduced functionality is acceptable, what the box that supports the implementation of the optional feature do when the other implementation does not, and what is the behavior of the device which does not support the feature do, when it has to interoperate with a device which does support it. Note, this is more about what the device is supposed to do, after the said device may have signaled to the other end about the expected behavior. E.g. If the devices have exchanged T=1 and R=1, but the other end does not send a flow-label, what is the receiver supposed to do? See more below under management considerations.\ \ The document defines the default mode of operation, i.e. a single path to preserve the packet delivery order, is important from an initial installation and setup point of view. The draft also makes a note that the default value of T and R is set to zero for implementations that do not support this feature, which is helpful for installations that do not have this feature.\ \ Management Considerations:\ \ Management considerations include interoperability, fault management, configuration management, accounting, performance and security.\ \ The interoperability will be a little more clear once the draft documents the optional behavior for the fault condition raised above. Related to that, if a fault is detected, say by the receiver, how is that indicated to any management station?\ \ I assume that the configuration of this feature will be taken by the BGP or a related YANG model.\ \ For accounting purposes, the documents needs to describe how an operator would know where all in the network, the feature is in use, and how well the feature is helping in load-balancing the traffic. Is this also going to be captured in the YANG model?\ \ A run of idnits reveals two warnings, the second of which can be ignored:\ \ \pard\pardeftab720\sl280\partightenfactor0 \f1 \cf2 \outl0\strokewidth0 \strokec2 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may\ have content which was first submitted before 10 November 2008. If you\ have contacted all the original authors and they are all willing to grant\ the BCP78 rights to the IETF Trust, then this is fine, and you can ignore\ this comment. If not, you may need to add the pre-RFC5378 disclaimer. \ (See the Legal Provisions document at\ https://trustee.ietf.org/license-info for more information.)\ \ IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):\ This document may contain material from IETF Documents or IETF\ Contributions published or made publicly available before\ November 10, 2008. The person(s) controlling the copyright in\ some of this material may not have granted the IETF Trust the\ right to allow modifications of such material outside the IETF\ Standards Process. Without obtaining an adequate license from the\ person(s) controlling the copyright in such materials, this\ document may not be modified outside the IETF Standards Process,\ and derivative works of it may not be created outside the IETF\ Standards Process, except to format it for publication as an RFC\ or to translate it into languages other than English.\ \ -- The document date (August 23, 2017) is 181 days in the past. Is this\ intentional?\ }