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?\
}
