Re: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09

[Vishnu Pavan Beeram <[e-mail]>]

Rakesh, Hi!

This is a valid comment. <GMPLS-LSP-FRR> doesn’t modify any of the existing procedures defined in RFC4090, but it does supplement it. As per RFC2223, this is sufficient grounds to set the “Updates” field.

Courtesy RFC2223:

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

@Deborah — Are you ok with this?
Regards,
-Pavan

From: "Rakesh Gandhi (rgandhi)" <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 4, 2017 at 10:55 AM
To: Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: DEBORAH BRUNGARD <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Zafar Ali <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>, Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, July 4, 2017 at 10:55 AM

Thanks Rifaat for the review of this document.

Hi Deborah, Lou, Pavan,

Any thoughts on the following suggestion?

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

Thanks,
Rakesh


From: Rifaat Shekh-Yusef <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 4, 2017 at 9:32 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Subject: [secdir] secdir review of draft-ietf-teas-gmpls-lsp-fastreroute-09
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: "=SMTP:mtaillon@cisco. com" <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, "=SMTP:rgandhi@cisco. com" <[e-mail]<mailto:[e-mail]>>, Zafar Ali <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, DEBORAH BRUNGARD <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, July 4, 2017 at 9:40 AM

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