Last Call Review of draft-ietf-pwe3-mpls-transport-
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
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
be the TTL to initiate packets on, for a particular MPLS path.
But as for the document being reviewed -- no security issues.