MPLS Transport Profile Data Plane Architecture
draft-ietf-mpls-tp-data-plane-04

Routing Area Directorate Review Comments

Document:      draft-ietf-mpls-tp-data-plane-03
Reviewer:      Ross Callon
Review Date:    June 14, 2010
IETF LC End Date: June 14, 2010
Intended Status: Standards Track

Summary: This document is basically ready for publication, but has minor editorial nits that should be considered prior to publication.

Comments: This draft is easy to read, and is quite well done. I have only editorial nits and one question that the authors should consider.

Major Issues:  None

Minor Issues:

Section 3.2, first two paragraphs:  It is clear from the first paragraph that the lowest level LSP occurs at level 0 (thus we could n from zero, rather than from one). However, the second sentence begins:

  Note that the MPLS label stack associated with an MPLS-TP section at
  layer n consists of n labels, in the absence of stack optimisation
  mechanisms.

Should this really specify that a stack at level n consists of n+1 labels? Alternatively, should we be counting LSPs starting at n=1 in the first paragraph?

Nits:

Section 2, page 5, first full paragraph on this page, first sentence:

  At an LSR, S-PE, or T-PE, further processing occurs to determine the
  context of a packet occurs when a swap operation is interrupted by
  TTL expiry.

There seems to be a grammatical error, the word "occurs" should only occur once. This would seem to read better if the first occurrence of "occurs" were deleted.

Section 4, third paragraph (page 9):

        When the the control message is carried over a section or an
        LSP,...

First of all the word "the" occurs twice in succession.

It seems to me that the term "section" was defined in section 3.2 to include either an underlying data link or an LSP at the next lower level. Thus the phrase "section or LSP" seems to be redundant -- although clear.

[Ballot comment]
Comments:
section2: "occurs" is used twice as the verb in a sentence
s/further processing occurs to determine the
  context of a packet occurs when/
further processing occurs to determine the
  context of a packet when/

3.2 lists the service types. It would seem nice to be consistent with the list of LSP types in 3.1.3; on first glance, it appears only three of the four LSP types are permitted to be supported in a section. If I understand correctly, you simply chose to aggregate the bidirectionals into one entry here, while not aggregating them in 3.1.3.

3.3 might be more easily readable if you included titles (or hints) about the contents of the RFCs listed. It would be nice if the list was in numerical order.

s/the the/the/

"note that" is seldom actually needed, since you are noting it.
s/Note that
  a swap
/A swap

s/Note that, except for/Except for

s/Note that the requirements/The requirements

s/Note that this does not preclude the future definition
/This does not preclude the future definition

s/Note that the payload of an MPLS-TP LSP may be a packet
/The payload of an MPLS-TP LSP may be a packet/

s/Note that the MPLS label stack/The MPLS label stack /

s/Note also that in order/In order

s/Note that an LSP of any of the types listed/An LSP of any of the types listed

s/Note however that MPLS-TP forwarding/MPLS-TP forwarding

s/Note that normal packet forwarding/Normal packet forwarding

s/Note that what appears/What appears

[Ballot discuss]
Hi,

1) Section 3.3 contains a list of RFCs; in the References, some are listed as normative, others as informational. Since they are the subject of a SHALL, I think they should all be normative.

2) There is a "MAY unless" that is itself inside a conditional. Normative language might be clearer specified outside the conditional, and specified as a "MUST NOT if".
Are the following equivalent?
OLD:
  Where enhanced security is desirable, and a trust relationship exists
  between an LSR and its peer, the LSR MAY choose to discard a packet
  received from a particular neighbour unless one of the following two
  conditions holds:
NEW:
  Where enhanced security is desirable, and a trust relationship exists
  between an LSR and its peer, the LSR MAY choose to discard a packet
  received from a particular neighbour. The LSR MUST NOT discard the
  packet if:

3) The conditions for the "MAY unless" talk about "Any MPLS label". Is this any label in the relevant packet, or a global "any label"?

The MPLS WG requests that:
  MPLS Transport Profile Data Plane Architecture
  draft-ietf-mpls-tp-data-plane-03

is published as an RFC on the standards track.


> (1.a) Who is the Document Shepherd for this document? Has the
>      Document Shepherd personally reviewed this version of the
>      document and, in particular, does he or she believe this
>      version is ready for forwarding to the IESG for publication?

Loa Andersson is the Document Shepherd.
He has reviewed the document and believes it is ready to be
forwarded to the IESG for publication.

> (1.b) Has the document had adequate review both from key WG members
>      and from key non-WG members? Does the Document Shepherd have
>      any concerns about the depth or breadth of the reviews that
>      have been performed?

The document has been reviewed in
- mpls, ccamp and pwe3 working groups
- the ITU-T MPLS-TP Ad Hoc Team
- the ITU-T SG15, Q9, Q10, Q12 and Q14, where liaisons has been
  exchanged to agree on how to address ITU+T comments.

The shephered is convinced that this is sufficient review for this
framework document.


> (1.c) Does the Document Shepherd have concerns that the document
>      needs more review from a particular or broader perspective,
>      e.g., security, operational complexity, someone familiar with
>      AAA, internationalization or XML?

No.

> (1.d) Does the Document Shepherd have any specific concerns or
>      issues with this document that the Responsible Area Director
>      and/or the IESG should be aware of? For example, perhaps he
>      or she is uncomfortable with certain parts of the document, or
>      has concerns whether there really is a need for it. In any
>      event, if the WG has discussed those issues and has indicated
>      that it still wishes to advance the document, detail those
>      concerns here. Has an IPR disclosure related to this document
>      been filed? If so, please include a reference to the
>      disclosure and summarize the WG discussion and conclusion on
>      this issue.

No such concerns. There is no IPR claim for this draft.



> (1.e) How solid is the WG consensus behind this document? Does it
>      represent the strong concurrence of a few individuals, with
>      others being silent, or does the WG as a whole understand and
>      agree with it?

The mpls-tp project is a joint project between IETF and ITU-T, this document
has been in focus when we sorted out differences between IETF and ITU-T
perspectives on how to define the subset of the MPLS functionality
necessary for an MPLS-TP data plane.



> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
>      discontent? If so, please summarise the areas of conflict in
>      separate email messages to the Responsible Area Director. (It
>      should be in a separate email because this questionnaire is
>      entered into the ID Tracker.)

No threats or extreme discontent.

> (1.g) Has the Document Shepherd personally verified that the
>      document satisfies all ID nits? (See the Internet-Drafts Checklist
>      and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
>      not enough; this check needs to be thorough. Has the document
>      met all formal review criteria it needs to, such as the MIB
>      Doctor, media type and URI type reviews?

The nits tool does not report any nits.


> (1.h) Has the document split its references into normative and
>      informative? Are there normative references to documents that
>      are not ready for advancement or are otherwise in an unclear
>      state? If such normative references exist, what is the
>      strategy for their completion? Are there normative references
>      that are downward references, as described in [RFC3967]? If
>      so, list these downward references to support the Area
>      Director in the Last Call procedure for them [RFC3967].

References are correctly split.


> (1.i) Has the Document Shepherd verified that the document IANA
>      consideration section exists and is consistent with the body
>      of the document? If the document specifies protocol
>      extensions, are reservations requested in appropriate IANA
>      registries? Are the IANA registries clearly identified? If
>      the document creates a new registry, does it define the
>      proposed initial contents of the registry and an allocation
>      procedure for future registrations? Does it suggest a
>      reasonable name for the new registry? See [RFC5226]. If the
>      document describes an Expert Review process has Shepherd
>      conferred with the Responsible Area Director so that the IESG
>      can appoint the needed Expert during the IESG Evaluation?

There are no IANA actions requested by this document.


> (1.j) Has the Document Shepherd verified that sections of the
>      document that are written in a formal language, such as XML
>      code, BNF rules, MIB definitions, etc., validate correctly in
>      an automated checker?

No such formal language.

> (1.k) The IESG approval announcement includes a Document
>      Announcement Write-Up. Please provide such a Document
>      Announcement Write-Up? Recent examples can be found in the
>      "Action" announcements for approved documents. The approval
>      announcement contains the following sections:

Technical Summary

  The MPLS Transport Profile (MPLS-TP) is the set of functions that
  meet the requirements in RFC5654. The MPLS transport Profile allow
  the deployment and operation of of MPLS based packet-switched
  transport networks.  MPLS-based packet transport networks
  are defined and described in MPLS-TP Framework.

  This document defines the set of functions that comprise the MPLS-TP
  data plane: the architectural layer concerned with the encapsulation
  and forwarding of packets within an MPLS-TP network.  This layer is
  based on the data plane architectures for MPLS (RFC3031) and
  (RFC3032)) and for Pseudowires (RFC3985).


Working Group Summary

  Since the document is an output from the MPLS-TP project it is the
  joint output of several IETF working groups and Qustion 9, 10, 12 and
  14 of ITU-T SG15.

Document Quality

The document is well reviewed in all the groups mentioned above.