Skip to main content

Last Call Review of draft-ietf-bess-pta-flags-02

Request Review of draft-ietf-bess-pta-flags
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-05-03
Requested 2016-03-31
Authors Eric C. Rosen , Thomas Morin
I-D last updated 2016-04-28
Completed reviews Genart Last Call review of -02 by Brian E. Carpenter (diff)
Genart Telechat review of -02 by Brian E. Carpenter (diff)
Secdir Last Call review of -02 by Christian Huitema (diff)
Opsdir Last Call review of -02 by Nevil Brownlee (diff)
Assignment Reviewer Christian Huitema
State Completed
Request Last Call review on draft-ietf-bess-pta-flags by Security Area Directorate Assigned
Reviewed revision 02 (document currently at 03)
Result Has issues
Completed 2016-04-28
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
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