Subject: [secdir] review of draft-ietf-mpls-gmpls-lsp-reroute-04

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 27 Aug 2009 20:31:45 -0700

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 abstract does a good job of summarizing: This document describes how 
Resource ReserVation Protocol (RSVP) PathErr Messages may be used to 
trigger rerouting of Multi-Protocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label 
Switched Paths (LSPs) without first removing LSP state or resources.

The security considerations section says the document introduces no new 
security considerations as it describes usage of existing formats and 
mechanisms, and I agree. It also points the reader to the security 
considerations sections of RFC4920 and RFC4736, and these do seem to do 
a reasonable job of summarizing.

I see no issues of concern for the security area ADs with this document.

--Scott

---

From: Lou Berger <[email-masked]>
Date: Fri, 28 Aug 2009 07:45:39 -0400

Thank you for the review!

Lou

---

From: JP Vasseur <[email-masked]>
Date: Mon, 31 Aug 2009 09:50:03 +0200

Thanks Scott.

JP.

On Aug 28, 2009, at 5:31 AM, Scott G. Kelly wrote:

> 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 abstract does a good job of summarizing: This document describes  
> how Resource ReserVation Protocol (RSVP) PathErr Messages may be  
> used to trigger rerouting of Multi-Protocol Label Switching (MPLS)  
> and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE)  
> Label Switched Paths (LSPs) without first removing LSP state or  
> resources.
>
> The security considerations section says the document introduces no  
> new security considerations as it describes usage of existing  
> formats and mechanisms, and I agree. It also points the reader to  
> the security considerations sections of RFC4920 and RFC4736, and  
> these do seem to do a reasonable job of summarizing.
>