I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Document reviewed:  draft-ietf-bess-fat-pw-bgp-03

Summary: 

This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures.

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:

   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

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:

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