Skip to main content

Last Call Review of draft-ietf-bess-pta-flags-02
review-ietf-bess-pta-flags-02-opsdir-lc-brownlee-2016-04-23-00

Request Review of draft-ietf-bess-pta-flags
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-03
Requested 2016-04-10
Authors Eric C. Rosen , Thomas Morin
I-D last updated 2016-04-23
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 Nevil Brownlee
State Completed
Request Last Call review on draft-ietf-bess-pta-flags by Ops Directorate Assigned
Reviewed revision 02 (document currently at 03)
Result Ready
Completed 2016-04-23
review-ietf-bess-pta-flags-02-opsdir-lc-brownlee-2016-04-23-00
Hi all:

I have performed an Operations Directorate review of
   draft-ietf-bess-pta-flags-02

  "The BGP-based control procedures for Multicast Virtual Private
   Networks make use of a BGP attribute known as the "P-Multicast
   Service Interface (PMSI) Tunnel" attribute.  The attribute contains a
   one-octet "Flags" field.  The purpose of this document is to
   establish an IANA registry for the assignment of the bits in this
   field.  Since the Flags field contains only eight bits, this document
   also defines a new BGP Extended Community, "Additional PMSI Tunnel
   Attribute Flags", that can be used to carry additional flags for the
   PMSI Tunnel attribute.  This document updates RFC 6514."

This is a short draft that does exactly what its abstract (above) says.

The reason for asking IANA to create two new registries are explained -
it seems that this is because providers now want to support Multicast
Virtual Private Networks by using PMSI Tunnels in BGP; that makes it
clear that the new registries are needed.

The draft spells out exactly how the PMSI Tunnel Flags and its (new)
Extended Community Additional FLags should be handled by BGP - that's
spelt out clearly, so - as far as I can see - it should not cause
any operational problems.

Overall, the draft is clear, simple and easy to understand.
I believe it is ready for publication as an RFC.

Cheers, Nevil

--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand