Sorry for the formatting issue. Let me fix and resend the review.
> On Feb 20, 2018, at 1:46 PM, Mahesh Jethanandani <mjethanandani@xxxxxxxxx> wrote:
>
> 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?\
> }
>
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ops-dir
Mahesh Jethanandani
mjethanandani@xxxxxxxxx
