Skip to main content

Last Call Review of draft-ietf-pwe3-mpls-transport-

Request Review of draft-ietf-pwe3-mpls-transport
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-08-11
Requested 2009-07-09
Authors Rao Cherukuri , Monique Morrow, Thomas Nadeau , George Swallow , Neil Harrison , Ben Niven-Jenkins , Stewart Bryant
I-D last updated 2009-08-06
Completed reviews Secdir Last Call review of -?? by Radia Perlman
Assignment Reviewer Radia Perlman
State Completed
Request Last Call review on draft-ietf-pwe3-mpls-transport by Security Area Directorate Assigned
Completed 2009-08-06
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, 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 

configuration would

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

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