Subject: [mpls] Routing Directorate review of G.8110.1

From: David Sinicrope <[email-masked]>
Date: Fri, 4 Feb 2011 13:25:20 -0500

I have been selected as the Routing Directorate reviewer for this
document. The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate, please
see http://www.ietf.org/iesg/directorate/routing.html

Document: https://datatracker.ietf.org/documents/LIAISON/file1155.pdf
Reviewer: David Sinicrope
Review Date: 31 January 2011
IETF LC End Date: N/A
Intended Status: N/A

*Summary and General Comments*

In general the document should be progressed pending satisfactory response
to the comments below.

The document eliminates Penultimate Hop Popping in several places while
saying it is an option in Annex A. I believe Penultimate Hop Popping is
allowed, although as Annex A points out, it is not the preferred mode of
operation.  Given this the text must not mandate that it cannot be used.
It would be helpful to the reader if its use was addressed in the modeling.

*Major Comments*

- Summary, Paragraph 2, 2nd sentence - "In the event of a difference
between this ITU-T Recommendation and any of the normatively referenced
IETF RFCs, the RFCs will take precedence."  The RFCs should take
precedence in all cases.  Change the text to read: "In the event of a
difference between this ITU-T Recommendation and any of the referenced
IETF RFCs, the RFCs take precedence."

- Section 10 MPLS-TP DiffServ Architecture, paragraph 3 states: "The
setting of the traffic class (TC) field is as defined in [IETF RFC 3270]
and [IETF RFC 5462] for the short-pipe and uniform models with no
Penultimate Hop Popping (PHP)."  However Annex A allows PHP.  Please
change the text to "The setting of the traffic class (TC) field is as
defined in [IETF RFC 3270] and [IETF RFC 5462] for the short-pipe and
uniform models."

- Section 10 MPLS-TP DiffServ Architecture, paragraph 5 states: "In order
to support short-pipe and uniform tunnelling modes, as defined in [IETF
RFC 3270], the Server/MT_A_So function is configured, on individual MT_CP
basis, to encode the TC field based on one of the following QoS Encoding
Modes:
- QoS Encoding Mode A where the TC field is encoded according to the
outgoing PHB information;
- QoS Encoding Mode B where the TC field is encoded with any value
(representing non-meaningful Diff-Serv information)."

The TC field must never be used for any purposed other than encoding
traffic class information.  Please remove Mode B and add the following
text "The TC field is encoded and used for QoS indications or, if not
used, is silently ignored."

- Section 10.1.1 Short Pipe Model, 1st sentence: "The transport processing
functions and processes for the short-pipe model (without penultimate hop
popping) are described in Figure 10-1.  Remove "(without penultimate hop
popping)" from the sentence per the inconsistency with Annex A highlighted
in the comment above.  Please add a second figure showing the PHP case for
consistency with Annex A.

- Section 10.1.2 Uniform Model, 1st sentence: "The transport processing
functions and processes for the Uniform model (without penultimate hop
popping) are described in Figure 10-2.  Remove "(without penultimate hop
popping)" from the sentence per the inconsistency with Annex A highlighted
in the comment above.  Please add a second figure showing the PHP case for
consistency with Annex A.

*Minor Comments*

- Section 1 Scope, paragraph 6 - "MPLS-TP is a connection-oriented
packet-switched transport layer network technology that uses MPLS-TP LSPs
and PWs"  Should read "MPLS-TP is a connection-oriented packet-switched
transport layer network technology that uses PWs and MPLS-TP LSPs per the
definition in section 1.3.4 of RFC 5921]"  There is no definition of an
MPLS-TP PW, and the text should be clear on the definition of an MPLS-TP
LSP.

- Section 1 Scope, paragraph 6 - "... allows consistent operations with
other transport technologies" should be "... allows operation consistent
with other transport technologies."

- Section 2 References -  What is the reason for moving the Survivability
framework draft reference (top of page 8) to the Bibliography (bottom of
page 46)?  It is still listed in the "Scope" clause (1), Functional
architecture clause (6), MPLS-TP MEG clause (8.1.3), MPLS-TP survivability
techniques clause (9) and Security aspects clause (12). Since the
referenced document has now been approved for publication as an RFC, it
would make sense to move this reference back to the References section
from the Bibliography.

- Section 6.1 MPLS-TP Network Layered Structure -  No definition of "the
MPLS-TP network architecture".  Please provide a reference to the
definition of the architecture.  Reference section 1.3 of RFC 5921.

- Section 6.1 MPLS-TP Network Layered Structure - "PWs in MPLS-TP can only
be carried over MPLS-TP LSPs." should be "While PWs can only be carried
over MPLS LSPs, this document only addresses the case where PWs are
carried over MPLS-TP LSPs."  The structure as defined is overly
restrictive.

- Section 6.1 MPLS-TP Network Layered Structure - "The MPLS architecture
does not have a minimum packet length. When MPLS packets are transmitted
over a non-MPLS-TP server layer with a minimum frame size, the
Server/MPLS-TP adaptation function will pad these packets to the minimum
frame size of that non-MPLS-TP server layer. This padding is removed at
the adaptation sink of the non-MPLS client. The mechanisms for mapping
clients over MPLS-TP provide appropriate information (e.g. the length
field in the Control Word) to remove the padding at that MPLS-TP/Client
adaptation sink function."  This paragraph discusses MPLS client
adaptation to non-MPLS-TP server layers.  Please explain the relevance to
MPLS-TP Network Layered Structure.

- Figure 6-5 see comment on Section 1 Scope paragraph 6.

- Section 6.1.2/6.2.3.1 MPLS Trail Termination  section 6.1.2 states "the
assignment of the S and TTL fields in the LSP or PW Label Stack Entry
(LSE) of a G-ACh packet is defined in the MPLS-TP Trail Termination
(MT_TT) function"  however, nothing is mentioned about the S bit in
section 6.2.3.1.

- Section 6.1.2 MPLS-TP Characteristic Information - States "The MT_CI
traffic units (MT_CI_D) are accompanied by the MT_CI_iPHB, MT_CI_oPHB,
MT_CI_SSF and optional MT_CI_APS signals."  There is no definition of
MT_CI_APS that I can find in G.8110 or other ITU-T documents. Please add
specific normative references to the definition of MT_CI_APS.

- Section 6.4 MPLS-TP Network Topology  Last sentence before section 6.4.1
"The control plane aspects are out of the scope of this Recommendation."
should read "The control plane aspects are not prohibited, but are outside
the scope of this Recommendation."  Control plane function is part of the
MPLS-TP requirements.

- Section 6.4.1 Unidirectional and bidirectional connections and trails -
Need to clarify this text.  It sounds like unidirectional connections in
the server layer cannot be combined to carry bidirectional MPLS-TP
connections.  If this is the intention of the text, it should be brought
out more strongly.  However, it seems like an unnecessary restriction.

- Figure 6-9 - Point to multipoint MPLS-TP subnetwork connection - The
previous paragraph states the traffic is broadcast from the root to the
leaves. Yet in this figure there are some leaves not receiving the
broadcast.  Is the traffic multicast instead of broadcast and if so what
is the criteria of the multicast?  Also if the traffic is sent from root
to leaf, what are the horizontal inter leaf communications in the figure?
The horizontal lines are labeled "MPLS-TP LC" which may indicate to the
reader the exit from the subnetwork, however it is unclear whether they
indicate this or communication paths.

- Section 6.5 MPLS-TP Label Behavior, 1st sentence - It would be good to
provide some specifics here.  This sentence references hundreds of pages
of documentation not all of which is relevant to label allocation and
behavior.

- Section 6.5.2 last paragraph before 6.5.3 states "When a request is made
to a label manager, a particular label value can be suggested. However
there is no guarantee that the suggested label value would be allocated."
How is a particular label suggested?  If done via management this function
is outside the scope of the recommendation.  If done via the control
plane, this is also outside the scope of the recommendation.  In either
case, this is an internal function and should be removed from the text.

- Section 7 Server/Client Associations  states "- MT/client adaptation,
where the client is not MPLS-TP. - MT/MT adaptation, for supporting
hierarchical MPLS-TP LSPs."  - See comment on section 1 regarding "MPLS-TP
LSPs".  It is not clear whether MPLS is included or excluded as a client
in the context of MPLS-TP LSPs.  Please clarify.

- Section 7.1.1 MT/ETH adaptation, 3rd paragraph, 1st bullet - The text
says "Insert the CW word..."  Insert between what?  It isn't clear what
the starting data is for these steps.

- Section 7.1.1 MT/ETH adaptation, 3rd paragraph, after 1st bullet - Add
"If required, the CW is inserted between <a> and <b>. The sequence number
processing may be performed."  Without this text it is inconsistent with
the 4th paragraph last bullet.  <a> and <b> should indicate the points of
insertion that will be clarified by the comment above.

- Section 7.2 MT/MT adaptation, 3rd paragraph, 3rd bullet - What protocol
is the CI_APS based?  Please provide a specific normative reference for
the definition and details of CI_APS.

- Section 7.3 Server/MT adaptation states: "Further definition of the
processes to adapt MPLS-TP to server layers is outside the scope of this
Recommendation and will be described in [b-ITU-T G.8121]."  Shouldn't this
say "is described in  [b-ITU-T G.8121]"?

- Section 8 MPLS-TP OAM Architecture - States "The MPLS-TP OAM mechanisms
and implementation are outside the scope of this Recommendation."  Change
this text to "The MPLS-TP OAM mechanisms are defined in the IETF RFCs and
are outside the scope of this Recommendation."

*Editorial Comments*

- Section 6.2.1.3 MPLS-TP Link  uses the access group term before it is
defined in 6.2.1.4. It is recommended to swap these sections in the
document order.

- Figure 6-8 - The arrow should point to MT LC vs. TM LC.

- Section 10.1 seems to be missing.  The text jumps from section 10 to
10.1.1.