Skip to main content

Last Call Review of draft-ietf-teas-gmpls-lsp-fastreroute-09
review-ietf-teas-gmpls-lsp-fastreroute-09-secdir-lc-shekh-yusef-2017-07-04-00

Request Review of draft-ietf-teas-gmpls-lsp-fastreroute
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-07-07
Requested 2017-06-23
Authors Mike Taillon , Tarek Saad , Rakesh Gandhi , Zafar Ali , Manav Bhatia
I-D last updated 2017-07-04
Completed reviews Rtgdir Last Call review of -07 by Mach Chen (diff)
Secdir Last Call review of -09 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -09 by Francis Dupont (diff)
Assignment Reviewer Rifaat Shekh-Yusef
State Completed
Request Last Call review on draft-ietf-teas-gmpls-lsp-fastreroute by Security Area Directorate Assigned
Reviewed revision 09 (document currently at 12)
Result Has nits
Completed 2017-07-04
review-ietf-teas-gmpls-lsp-fastreroute-09-secdir-lc-shekh-yusef-2017-07-04-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.

Summary: Ready with Nits


I did not have enough background on MLPS and GMPLS and their related RFCs,
so I had to do some reading to get some familiarity with this subject to be
able to provide some reasonable review of this document.

This document builds on an existing mechanism, "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels" defined in RFC4090, which defines a mechanism to
establish a backup tunnels for local LSP tunnels. One limitation of the
existing mechanism is that in some situations it might assign different
uni-directional bypass tunnels for the forward and reverse directions.

This document extends the mechanism defined in RFC4090, by adding a new
BYPASS_ASSIGNMENT subobject to the existing RECORD_ROUTE Object (RRO) used
in PATH and RESV requests, to allow the establishment of a bi-directional
bypass tunnel.

The security of the existing mechanism still applies with the new mechanism,
and the security section discusses the implications of the new subobject and
the new error associated with that, which seems reasonable.

The document also points to an MPLS/GMPLS Security Framework (RFC5920)
document that has an extensive discussion of the security of MPLS/GMPLS
network in general that also applies to this document.


Nits

Because the document extends RFC4090, it should add "Updates: 4090" at the
top of the document.

Regards,
 Rifaat