Last Call Review of draft-ietf-bess-pta-flags-02
review-ietf-bess-pta-flags-02-secdir-lc-huitema-2016-04-28-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The document is ready with issues.

The document defines an extension mechanism for the "flags" field in the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry
information in BGP about multicast routing inside VPN. RFC 6514 describes an
8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one
of the 7 bits as an extension mark, and proposes to create an IANA registry
for the remaining 6 values, and for the values of the newly defined
extension field.

The draft is pretty simple, but it poses the generic issue of extensions.
What happens if some routers in a domain are aware of the newly assigned
extension and some are not? The authors argue that this behavior is properly
defined in the documents describing the future extensions. This is
plausible, but the draft does define a generic mechanism, and does switch
the meaning of one of bits marked as "reserved" in RFC 6514. We have thus
two possible issues:

1) A router supports RFC 6514 but does not implement the extension
mechanism.
2) A router supports the extension mechanism, but does not support the
specific extension.

I am able to guess a plausible behavior based on the text in the draft and
the reference to " Treat-as-withdraw" option of RFC 7606, but I would much
prefer if there was a recommended behavior in the draft. 

-- Christian Huitema