Re: [mpls] Last Call: <draft-ietf-mpls-mldp-node-protection-05.txt> (mLDP Node Protection) to Proposed Standard

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 02 September 2015 17:27 UTC

From: Adrian Farrel <adrian@olddog.co.uk>
To: ietf@ietf.org
References: <20150825221944.10283.10646.idtracker@ietfa.amsl.com>
In-Reply-To: <20150825221944.10283.10646.idtracker@ietfa.amsl.com>
Date: Wed, 02 Sep 2015 18:27:39 +0100
Message-ID: <029c01d0e5a4$ab85bc10$02913430$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQEqIwc7hetHUf8AKCZhmWU6iSerQZ93AjeQ
Content-Language: en-gb
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/R8LgrIHvvqrnhOAT-Hz2hOTjepc>
Cc: mpls@ietf.org, draft-ietf-mpls-mldp-node-protection@ietf.org
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-mldp-node-protection-05.txt> (mLDP Node Protection) to Proposed Standard
Precedence: list
Reply-To: adrian@olddog.co.uk

Hi,

I took a  look at this I-D although I was not lucky enough to win the ballot to
be Routing Directorate reviewer. At least that saves me from some boilerplate
:-)

IMHO this I-D describes useful function that is practical to implement. The
document is clear and ready for publication. It might benefit from another read
to fix a few points of grammar, but I am sure the RFC editor will handle that
without risking the meaning of the document.

I provide a few pointless nits to prove I read the document.

Thanks,
Adrian

===

Abstract
s/has/have/

---

Abstract
I regret that "LSR" is not a well-known abbreviation and has to be 
expanded. Ditto "P2P"

---

Section 1
Same issues with abbreviations. Add LFA.
s/setup/set up/
s/LST/LSR/

---

Section 2.1
The sentence "After determining..." has unbalanced parentheses.
s/don't/does not/

---

I suspect that Section 6 is enough and that the Sec ADs will wonder
whether or not it is. 

What is new here? Well I suppose there is the potential for an LSR to
get hit with a lot of tLDP sessions and a multiplier of tLDP LSPs (one
for every protected LSP that transits the LSR). Is that a vector for 
attack? I don't think so.

So you could add something like...

   The procedures in this document add two new TLVs to existing LDP
   messages.  Those TLVs can be protected by the mechanisms that are
   used to protect LDP messages as described in [RFC6388] and [RFC5920].
   If it were possible to attack the mechanisms described in this 
   document an LSR (a PLR or a MPT) could be induced to support a large
   number of tLDP sessions and set up an even larger number of LSPs.
   The security mechanisms in [RFC6388] and [RFC5920] are believed to be
   adequate, but an implementation could provide additional protection
   by counting such protection sessions and LSPs and producing a log
   message to the operator if a threshold is crossed.

[mpls] Last Call: <draft-ietf-mpls-mldp-node-prot… The IESG
Re: [mpls] Last Call: <draft-ietf-mpls-mldp-node-… Adrian Farrel