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

From: Dan Frost <[email-masked]>
Date: Tue, 13 Apr 2010 08:39:23 +0100

--------- Begin forwarded message

Subject: Re: AD review of draft-ietf-mpls-tp-data-plane
From: Dan Frost <[email-masked]>
To: Adrian Farrel <[email-masked]>
Cc: Stewart Bryant <[email-masked]>, BOCCI Matthew <[email-masked]>
Date: Mon, 12 Apr 2010 17:38:41 +0100

Hi Adrian,

Thanks for the review; please see the responses below.  We will be doing
some further editing tomorrow to address the ITU-T comments, so if you
happen to see this by then and want to add anything, we can address it
then.

Adrian Farrel <[email-masked]> writes:
> 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/)

OK

> ---
>
> 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.

OK

> ---
>
> 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.

Text currently reads:

   Support for Internet Protocol (IP) host and router data-plane
   functionality by MPLS-TP interfaces and in MPLS-TP networks is
   OPTIONAL.

> ---
> Throughout
> s/data-plane/data plane/

OK

> ---
>
> 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.

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.

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

Yes, fixed.

> ---
>
> 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.

We discussed this issue and agree that it's best to move the Ethernet
text to a separate draft.  Section 5 now reads:

   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.  Note that what appears to be
   a single server layer link to the MPLS-TP network may be a
   complicated construct underneath, such as an LSP or a collection of
   underlying links operating as a bundle.  Special care may be needed
   in network design and operation when such constructs are used as a
   server layer for MPLS-TP.

   Encapsulation of MPLS-TP packets for transport over specific
   server-layer media is outside the scope of this document.

We have also removed the IANA Considerations to match.

> ---
>
> 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].

Current text reads:

   The MPLS data plane (and therefore the MPLS-TP data plane) does not
   provide any security mechanisms in and of itself.  The following
   behaviour, however, is considered a best current practise for MPLS
   LSRs which is also applicable to MPLS-TP:

   An LSR SHOULD discard a packet received from a particular
   neighbour unless one of the following two conditions holds:

      o Any MPLS label processed at the receiving LSR, such as an LSP or
        PW label, has a label value that the receiving LSR has
        distributed to that neighbour; or

      o Any MPLS label processed at the receiving LSR, such as an LSP or
        PW label, has a label value that the receiving LSR has
        previously distributed to the peer beyond that neighbour (i.e.,
        when it is known that the path from the system to which the
        label was distributed to the receiving system is via that
        neighbour).

   Client layers that wish to secure data carried over MPLS-TP
   transport entities are REQUIRED to apply their own security
   mechanisms.

   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
   [I-D.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?

OK

- Dan, Stewart, and Matthew

--------- End forwarded message