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