Subject: [mpls-tp] AD review of draft-ietf-mpls-tp-data-plane

From: Adrian Farrel <[email-masked]>
Date: Fri, 02 Apr 2010 13:31:58 +0100

Don't panic!

Hi,

I have carried out my AD review slightly earlier than usual in the
process so I have probably found a number of issues that you will
be fixing as part of mark-ups after WG last call.

The purpose of an AD review is to check that the document is ready
to go to IETF last call and IESG review. The intention is to find
most of the issues that might be found at those stages and so smooth
the passage of the I-D and reduce the load on the IESG in general.

All in all, I found this to be a readable document with lots of
good detail. Thanks!

Adrian

---

id nits (http://tools.ietf.org/tools/idnits/) says...
  == You're using the IETF Trust Provisions' Section 6.b License Notice from
     12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
     http://trustee.ietf.org/license-info/)

---

Section 1
   Packet transport networks are
   defined and described in [I-D.ietf-mpls-tp-framework].
To be fair, I think that that I-D only describes MPLS-based PTNs.

---

Section 3.1.1

   Data-plane support for Internet Protocol (IP) packet encapsulation,
   addressing, and forwarding is OPTIONAL.

I think this needs qualification.  You are referring to support of IP
encapsulation by MPLS-TP interfaces and in MPLS-TP networks.

---

Throughout
s/data-plane/data plane/

---

Section 3.1.3

Should we comment about parallel links?
Suppose in your example that nodes N1 and N2 are connected by links
L12a and L12b. Suppose that the "forward" direction LSP traverses link
L12a, is there any statement we can make about which link the "reverse"
direction LSP traverses? A statement of requirement or non-requirement
would be good.

Note that I am not talking about component links of a bundle, nor about
link members of a LAG. I am talking about parallel TE links.

---

Section 3.2

In talking about the GAL, you have a lower case "must". Should be upper
case?

---

Section 5

I am unclear why Ethernet gets special attention, but other server
layers do not.

Actually, I am not sure why this section exists at all. In what way
does the server layer impact the operation of the client layer? Isn't
it the case (as you say) that "the MPLS-TP network has no awareness of
the internals of the server layer of which it is a client, requiring
only that the server layer be capable of delivering the type of service
required by the MPLS-TP transport entities that make use of it".

I think you should delete the words "in general" from Section 5, and
consider deleting sections 5.1. The alternative would appear to be
the inclusion of a number of other sections to cover other
encapsulations (PoS, GFP, HDLC, MPLS, etc., etc.) I don't think we
either want or need to go there!

This also gets you off the hook of "This topic is for further study."

OTOH, I *do* see the need for this discussion and the associated
section 7. It seems to me, however, that "MPLS-TP Encapsulation in
Ethernet Links" should be the subject of a separate I-D.

---

Section 6

Factually correct, but rather light.
In order to keep the security folk happy, I think you need to talk about
MPLS-TP data plane security. Fortunately, there is not much to say...

The MPLS data plane (and so the MPLS-TP data plane) does not provide any
security mechanisms. It is a requirement that client layers wanting to
secure data carried over MPLS-TP transport path must apply their own
security.

Where management or control plane protocols are used to install label
switching operations necessary to establish MPLS-TP transport paths,
those protocols are equipped with security features and network
operators may use those features to securely create the transport paths.

Further details of MPLS security can be found in
[ID.ietf-mpls-mpls-and-gmpls-security-framework].

---

Sections 8.1 and 8.2

Would you consider ordering the references so that it is easier to
find them?

---

---

From: Dan Frost <[email-masked]>
Date: Tue, 13 Apr 2010 14:32:29 +0100

Hi Adrian,

On Mon, Apr 12, 2010 at 11:19:21PM +0100, Adrian Farrel wrote:
> [...]
> >We assume your comment refers to co-routed bidirectional LSPs.
> >According to RFC5654:
> >
> >  Co-routed Bidirectional path: A path where the forward and backward
> >  directions follow the same route (links and nodes) across the
> >  network.  Both directions are setup, monitored and protected as a
> >  single entity.  A transport network path is typically co-routed.
> >
> >The description of co-routed bidirectional LSPs in this document
> >reflects this requirement.  Here's the current text (with minor updates
> >to normative language):
> >
> >  A point-to-point co-routed bidirectional LSP is a point-to-point
> >  associated bidirectional LSP with the additional constraint that its
> >  two unidirectional component LSPs follow the same path in the
> >  network.  This means that if one of the component LSPs follows the
> >  path through the nodes N0, ..., Nk, originating on N0 and terminating
> >  on Nk, then the path of the other component LSP MUST be Nk, ..., N0,
> >  and that at each node an ingress interface of one component LSP MUST
> >  be an egress interface of the other.  In addition, each node along
> >  the path is REQUIRED to be aware of the pairing relationship between
> >  the component LSPs.  An important property of co-routed bidirectional
> >  LSPs is that their unidirectional component LSPs share fate.
> 
> Yes, I agree with your reference to 5654.
> My problem with your text is that is says "...follows the same path in the 
> network" and then describes this in terms of nodes only. Thus, reading this 
> draft (and not 5654) one might think that different TE links can be used in 
> opposite directions.

The original text actually does address links also via the statement "at each
node an ingress interface of one component LSP MUST be an egress interface of
the other", but we agree this could be clearer.  Current text reads simply:

  A point-to-point co-routed bidirectional LSP is a
  point-to-point associated bidirectional LSP with the additional
  constraint that its two unidirectional component LSPs in each
  direction follow the same path (in terms of both nodes and
  links).

-d

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 13 Apr 2010 22:33:06 +0100

Hi Dan,

Thanks, that does the trick.

Adrian
----- Original Message ----- 
From: "Dan Frost" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, April 13, 2010 2:32 PM
Subject: Re: [mpls-tp] AD review of draft-ietf-mpls-tp-data-plane

> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>