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.