Last Call Review of draft-ietf-pwe3-mpls-transport-
review-ietf-pwe3-mpls-transport-secdir-lc-perlman-2009-08-06-00

This document describes how to make an MPLS-TP path one one party (party A)
appear to be an MPLS-TP link of another (party B), in other words, tunneling
party B's MPLS-TP information over party A's -provided path.

As noted in the security considerations section, there are no new security
issues raised by using this already-existing mechanism for this purpose.

One comment: Rao Cherukuri's email address seems to be missing
from "authors' addresses".

A couple of questions, really...it looks like the term "Transport" is used
in the MPLS/ITU context to mean more like layer 3, rather than end-to-end
layer 4 (like TCP). Although this always seemed a much more natural use


of the term "transport" (since layer 3 and layer 2 really do transport 


things



and layer 4 doesn't), why is it is called "TP" here?

And in the security considerations section it mentions the problem of
static configuration having the possibility of a forwarding loop. Again just
a comment -- admittedly a packet can go round the loop a few times before
the TTL expires, but given that there is a TTL, it seems like a looping MPLS


path might not be too bad. Especially if part of the static 


configuration would



be the TTL to initiate packets on, for a particular MPLS path.

But as for the document being reviewed -- no security issues.

Radia