Subject: [mpls-tp] Comment on MPLS-TP OAM Framework

From: Maarten Vissers <[email-masked]>
Date: Fri, 02 Apr 2010 00:00:15 +0200

Below are some comment on the mpls-tp oam framework draft:

1) Section 3.3, first paragraph states:
  "MEG End Points (MEPs) are the source and sink points of an MEG. In 
   the context of an MPLS-TP LSP, only LERs can implement MEPs while in 
   the context of a path segment tunnel (PST) both LERs and LSRs can 
   implement MEPs that contribute to the overall monitoring 
   infrastructure for the transport path. Regarding MPLS-TP PW, only T-
   PEs can implement MEPs while for PSTs supporting a PW both T-PEs and 
   S-PEs can implement MEPs. In the context of MPLS-TP Section, any 
   MPLS-TP LSR can implement a MEP. "

MEPs and MIPs are to be described in the context of a 'transport path', not
in the context of an 'MPLS-TP LSP' or 'MPLS-TP PW'.

Every MEG in a 'transport path', is instantiated by means of the creation of
either a 'MS-PW' or a 'LSP'. If a MEG is created in a LSR, then this LSR
becomes an LER for this MEG (it pushes/pops label). The terms LER and LSR
have as such lost their original meaning and should not be used in the
context of MPLS-TP OAM framework.

2) Section 3.3, second paragraph states:
  "MEPs are responsible for activating and controlling all of the OAM 
   functionality for the MEG. "

This statement is not correct. Specifically the insertion of AIS and LCK OAM
is performed by a server MEP. Please add a description that the generation
of this latter OAM is not the responsibility of the MEG's MEP. Furthermore,
indicate that the MEG's MEP functions have to support insertion of OAM in
client MEGs (in the same transport path, or in one or more client transport
paths).

3) Section 3.3, paragraph 4 states:
  "Once an MEG is configured, the operator can configure which OAM 
   functions to use on the MEG but the MEPs are always enabled. A node 
   at the edge of an MEG always supports a MEP. "

Once a MEG is configured, the operator may have to configure the AIS
insertion capability in the server MEP functions located between the MEPs of
the configured MEG.

4) Section 3.3, paragraphs 6 and 7 state: "... LSP or PW ..."

Transport paths are supported by 'MS-PW', 'service LSP', 'edge to edge LSP'
and 'section LSP'. A 'PST LSP' is not a 'transport path'. Please correct the
currently ambiguous text.

5) Section 3.3, last but one paragraph states:
  "Note that a MEP can only exist at the beginning and end of a layer 
   i.e. an LSP or PW. "

The above is an incorrect statement. The layers in MPLS-TP are transport
service layer, transport path layer and section layer. LSP and PW do not
represent names of MPLS-TP layers. LSP and PW represent MEGs within a
'transport path' within those layers. Please correct the text as follows:

  "Note that a MEP can only exist at the beginning and end of a layer 
   i.e. a transport service layer transport path, transport path layer
   transport path, or section layer transport path. "

6) Section 3.4, first two paragraphs state:
  "A MEG Intermediate Point (MIP) is a point between the MEPs of an MEG. 

   A MIP is capable of reacting to some OAM packets and forwarding all 
   the other OAM packets while ensuring fate sharing with data plane 
   packets. However, a MIP does not initiate unsolicited OAM packets, 
   but may be addressed by OAM packets initiated by one of the MEPs of 
   the MEG. A MIP can generate OAM packets only in response to OAM 
   packets that are sent on the MEG it belongs to. "

The description that a MIP represents a point is not consistent with the
description that a MIP is capable to react to OAM packets. A 'point' can not
react, a 'function' located on a 'point' can react. Please use the term MIP
consistent in the framework. Decide if a MIP represents a 'point', or if a
MIP represents a 'function' on an intermediate point.

7) Section 3.4, second bullet item states:
   "o support per-interface MIP (i.e. two or more MIPs per node on both 
      sides of the forwarding engine) "

If a node supports per-interface MIP functions, then a node with a MEP
function on the egress port will only support one MIP function on the other
port. Please include this case in the text.

8) Section 3.4, last paragraph states:
  "Once an MEG is configured, the operator can enable/disable the MIPs 
   on the nodes within the MEG. All the intermediate nodes host MIP(s). 
   Local policy allows them to be enabled per function and per LSP. The 
   local policy is controlled by the management system, which may 
   delegate it to the control plane. "

It is not complete when stating "All the intermediate nodes host MIP(s).".
The end nodes may also host a MIP; i.e. when the MEP of the MEG is located
behind the forwarding engine. Please correct the text.

It is not complete when stating "to be enabled per function and per LSP".
The MS-PW also represents a MEG with intermediate nodes, and should be
included in the list. The text should be modified as follows: "to be enabled
per function and per MS-PW or LSP".

9) Section 3.5, second bullet list states:
 " o An MPLS-TP Section MEP for MPLS-TP LSPs, defined in section 4.2; 

   o An MPLS-TP LSP MEP for MPLS-TP PWs, defined in section 4.4; 

   o An MPLS-TP PST MEP used for LSP segment monitoring, as defined in 
      section 4.3, for MPLS-TP LSPs or higher-level LSP PSTs; 

   o An MPLS-TP PST MEP used for PW segment monitoring, as defined in 
      section 4.5, for MPLS-TP PWs or higher-level PW PSTs. "

The term 'LSP' refers to all types of 'LSP's, including service LSP,
edge-to-edge LSP, PST LSP and section LSP. Please replace 'LSP' in the above
bullet items by the intended type of 'LSP'. 

Please replace also 'PST' by 'PST LSP' and 'Section' by 'Section LSP'.

Please replace 'segment monitoring' by 'TCM'. A 'segment' is defined as a
G.805 link connection, not as a tandem connection.

'higher-level PW PSTs' do not exist. A 'transport service layer transport
path' supported by a 'MS-PW' has its TCM supported by a 'PST LSP'.

10) Section 3.7

The root MEP function must be able to send an OAM packet (e.g. loopback) to
a MIP function located between the root MEP function and the leaf MEP
functions. Please add this capability to the text.

11) section 4

Maintenance entity groups are defined per 'transport path' in each of the
three MPLS-TP layers. Therefore the following MEGs should be listed in this
section:

- section LSP MEG
- section PST LSP MEG
- transport path edge-to-edge LSP MEG
- transport path PST LSP MEG
- transport service MS-PW MEG
- transport service Service LSP MEG
- transport service PST LSP MEG.

Please correct the text and the figure 3. Figure 3 should use the MPLS-TP
LSP name types service LSP, edge-to-edge LSP, PST LSP and section LSP.
Figure 3 should show both a MS-PW and a service-LSP. Also a PW supporting a
VPLS should be shown.

12) Section 4, paragraph above figure 3 states:
  "Hierarchical LSPs are also supported in the form of path segment 
   tunnels. In this case, each LSP Tunnel in the hierarchy is a 
   different sub-layer network that can be monitored, independently from 
   higher and lower level LSP tunnels in the hierarchy, on an end-to-end 
   basis (from LER to LER) by a PSTME. It is possible to monitor a 
   portion of a hierarchical LSP by instantiating a hierarchical PSTME 
   between any LERs/LSRs along the hierarchical LSP. "

'LSP Tunnel' is not one of the MPLS-TP defined LSP types. Please replace it
by the appropriate MPLS-TP LSP type or types intended. An additional MEG
level for TCM is provided by means of the creation of a PST LSP. 

It seems better to replace the text in this paragraph and describe that the
MPLS-TP layer stack creates a hierarchy of PW and LSPs, and that nested MEGs
create a further hierarchy of LSPs. I.e.
- transport service layer transport path (MS-)PW/Service-LSP
  # zero or more PST LSPs
- transport path layer trnasport path edge-to-edge LSP
  # zero or more PST LSPs
- section layer transport path LSP
  # zero or more PST LSPs.

13) Section 4, paragraph below figure 3 refers to 'LSR's. As a LSR becomes a
LER as soon as a label is pushed/popped all PE nodes are LER nodes. How to
deal with this.

Regards,
Maarten

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 01 Apr 2010 23:03:55 +0100

Hi Maarten,

Many thanks for your time reviewing this draft.

I saw that you also gave some comments for inclusion in the ITU-T liaison.
In order to simplify the authors' job in handling the comments, can you 
clarify whether you sent the same comments to both groups?

Thanks,
Adrian
----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 01, 2010 11:00 PM
Subject: [mpls-tp] Comment on MPLS-TP OAM Framework

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

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 02 Apr 2010 00:11:03 +0200

Hi Adrian,

I had send those comments to the ITU-T list after Huub has send his summary
of received comment and indicated that further comment had to be send to
mpls-tp mailinglist. If Huub is able to add this comment still to the ITU-T
comment, then it can be dealt with via the itu-t liaison statement,
otherwise via direct submission to the mpls-tp list. Please coordinate with
Huub what would be most appropriate.

Note that I have not been able to review the draft at an earlier date due to
overload... I will continue reviewing the rest of the draft and will send
any further comment to the mpls-tp mailinglist. It will be after the
deadline however. 

Regards,
Maarten

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: vrijdag 2 april 2010 0:04
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Comment on MPLS-TP OAM Framework

Hi Maarten,

Thanks,
Adrian
----- Original Message -----
From: "Maarten Vissers" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 01, 2010 11:00 PM
Subject: [mpls-tp] Comment on MPLS-TP OAM Framework

> 13) Section 4, paragraph below figure 3 refers to 'LSR's. As a LSR becomes

> a