Re: [bess] [OPS-DIR] Opsdir last call review of draft-ietf-bess-fat-pw-bgp-03

[Mahesh Jethanandani <[e-mail]>]

Sorry for the formatting issue. Let me fix and resend the review.

> On Feb 20, 2018, at 1:46 PM, Mahesh Jethanandani <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir

Mahesh Jethanandani
[e-mail]