Subject: [mpls-tp] AD review of draft-ietf-mpls-tp-oam-framework

From: Adrian Farrel <[email-masked]>
Date: Thu, 01 Apr 2010 00:16:20 +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!

There are some places where the English could use a little polish.
Although the RFC Editor will catch these, if you were to read the
document and fix a few nits as you went along this would help the
Editor to focus on the more substantive issues.

Most of my (quite long) list of comments that follow are nits, and
should be easily fixed. A few are a little more substantive, but
should also be quite quick to fix with very minor text changes.

I'm happy to discuss any issues and you should treat my comments
as normal last call comments.

Thanks,
Adrian

Please run idnits (http://tools.ietf.org/tools/idnits/) on the next 
revision and take care to clean up all errors and warnings. 
---
Remove the citation from the Abstract. (Just delete " [12]")
---
Don't need to expand "PW" twice in the Abstract.
---
Abstract
s/fulfills/fulfill/
---
Abstract
s/Telecommunications/Telecommunication/  x2
---
Acronyms need to be expanded on first use in the main body of text
even if they were expanded in the Abstract.
---
Section 1
You have "co-routed and bidirectional p2p transport paths"
You need to align with the terminology of RFC 5654. That gives...
"co-routed and associated bidirectional p2p transport paths"
---
Section 1
s/Telecommunications/Telecommunication/  x2
---
Section 2
I don't see the purpose of using RFC 2119 language in this document.
It is a framework with no requirements and no process specification.
I think that if you want to indicate an imperative, lower case "must"
is fine.
Do you have a specific reason for upper case, or can we convert all
instances in the document?
---
Section 2.1
Please remove unused acronyms
I see FDI
---
Section 2.1
LSR is Label Switching Router
---
Section 2.1
LPSTME, PME, PPSTME, and SME are expanded differently in section 4
---
Section 2 Please check consistency of definitions is mapped in the
Rosetta draft.
---
Section 2.1 and onwards
Why do you use the term "PSN"
This work is surely limited to MPLS networks.
It is possible that you might want to make passing reference to generic
PSNs, but in general you should limit your discussion to MPLS networks.
---
Section 2.2
"are intended to be in line"
Are they or are they not? :-)
If they are not, then fix them.
If they are, then say so less tentatively
---
Section 2.2
Data plane loopback
I find the definition confusing.
Can this only apply at
- any node of a co-routed bidirectional LSP
- a coincident node of an associated bidirectional LSP
- no node of a unidirecitonal LSP
Explicitly, what does "loopback" mean. I think you mean to say take all
data plane traffic including OAM that would normally pass through this
interface and send it in the reverse direction on the same LSP using the
correct label for the reverse direction of the LSP.
You also need to say what expectations there are for the TTL. Should the
TTL of the looped-back packet be preserved, decremented, or replaced.

If these definitions are found elsewhere, it is OK to reference them.
Possibly 6.3.2 could be enhanced to address these issues?
---
Section 2.2
I think there is something slightly wrong about the definition of ME, 
MEG, and MEP. MEPs are defined as:
   MEPs reside at the boundaries of an ME
Not sure if this is meant to mean:
- the boundaries of an ME are MEPs
or
- all MEPs are boundaries of MEs
If the former, please add the clarification.
If the latter, then we need to iron the definition of MEG because it
would imply that all MEs in a MEG have the same boundaries.
By the way, there is some slight of hand by which "end point" is 
explained as "boundary".
---
Section 2.2
OAM flow
s/MEP/MEP source/
---
Section 2.2
Path: See Transport Path
I presume you mean to reference an external definition?
---
Section 2.2
Signal Fail
Suggest you reference draft-ietf-mpls-tp-nm-req for the definition of
"failure"
---
General search and replace...
s/point to point/point-to-point/
s/point to multipoint/point-to-multipoint/
s/A LSP/An LSP/
s/An MEG/A MEG/
---
Section 3.1
   MPLS-TP OAM operates in the context of Maintenance Entities (MEs) 
   that are a relationship between two points of a point to point 
   transport path or a root and a leaf of a point to multipoint 
   transport path

This seems to be a mismatch.
But in later text, the MEPs for a p2p path are indicated as the end
points.
---
Section 3.1
   In between these two points zero or more intermediate points, 
   called Maintenance Entity Group Intermediate Points (MIPs), MAY exist 
   and can be shared by more than one ME in a MEG.
Fine, but MEG is not introduced until several paragraphs later.
---
Section 3.2
   TCM for a given portion of a transport path is implemented by first 
   creating a path segment tunnel

"Portion" is a nice word. Do we mean "segment or concatenated segment"?

Unclear what "first" means.
Before monitoring can be done, or before the e2e path is set up?
If the former, please clarify; if the latter, I disagree since an LSP
can be redirected into a PST using make-before-break or local re-
routing.
Cf. 3.6
---
Section 3.2
   TCM for a given portion of a transport path is implemented by first 
   creating a path segment tunnel that has a 1:1 association with 
   portion of the transport path that is to be uniquely monitored.
The implication here is that you cannot run two paths down the same PST
and, by monitoring the PST, monitor two "parallel" portions of the same
LSP. If this is intended, perhaps some explanation would help the 
readers.
---
Section 3.2
   there is direct correlation between all FM and PM information 
   gathered for the PST AND the monitored portion of the E2E transport 
   path. The PST is monitored using normal LSP monitoring. 
Expand acronyms FM and PM, and give references.
Lower case AND
Expand acronym E2E
---
Section 3.3
   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.
This distinction between LER and LSR may be confusing.
You would be better to refer to end points and transit nodes of the
MPLS-TP LSP being monitored. The end points of a PST are arguably LERs
(for the PST) since they show the ability to impose labels.
Besides, LER is not such a widely used term showing up mainly in the
MIB module RFCs.
---
Section 3.3
   OAM packets never "leaks" outside of a 
   MEG in a fault free implementation.
s/leaks/leak/
It is slightly more than the implementation that must be fault-free.
For example, if there is a broken forwarder or a misfiber, then the
OAM will leak.
Maybe...
...in a fault-free implementation with a fault-free data path
---
Section 3.3
s/msg/a message/
---
3.4
   A node at the edge of an MEG can also support per-interface MEPs and 
   per-interface MIPs on either side of the forwarding engine. 
I missed this in the discussions with Yoshinori.
It seems that the concept of per-interface MEPs is not consistent with
the definition of a MEP. It would seem that the MEP must be conicident
with the start of the monitored LSP/PW. It may be really helpful to
show where that sits wrt to the label imposition.
In the case of P2MP, for example, label imposition will happen before
packet replication.
Perhaps you want to say that per-interface MIPs may exist on the LSR
that hosts the MEP.
---
Section 4
   A MS-PW PST Maintenance Entity
All the others are Groups, this one isn't?
---
Section 5.1
   It is desirable to not generate spurious alarms during initialization 
   or tear down
I suspect it is desirable to never generate spurious alarms!
Maybe you need to say that...
During path setup and tear down, situations arise where CCV checks would
give rise to alarms as the path is not fully instantiated. In order to
avoid these spurious alarms...
---
Sections 5.1 and 5.1.1.1
In 5.1 we have
   When used to perform only pro-active Continuity Check 
   function, the CC-V OAM packet MAY not include any globally unique 
   Source MEP identifier.
and in 5.1.1.1
   o Entry criteria:  if no pro-active CC-V OAM packets from the peer 
      MEP (i.e. with the correct globally unique Source MEP identifier) 
      are received within the interval equal to 3.5 times the receiving 
      MEP's configured CC-V reception period. 
This appears to be a contradiction. Ditto the exit criterion.
---
Section 5.3
I had some trouble parsing this section :-(

   The Alarm Reporting function, as required in section 2.2.8 of [12], 
   relies upon an Alarm Indication Signal (AIS) message used to suppress 
   alarms following detection of defect conditions at the server 
   (sub-)layer. 

Should "used" be deleted?
That is, alarm reporting does not require AIS, but AIS is used to 
suppress alarms. So, "..relies upon an AIS message to suppress alarms.."

   o A server MEP that detects a signal fail conditions in the server 
      (sub-)layer, will notify the MPLS-TP client (sub-)layer adaptation 
      function, which can generate packets with AIS information in a 
      direction opposite to its peers MEPs to allow the suppression of 
      secondary alarms at the MEP in the client (sub-)layer. 

Now this looks like tricksy word-use.
The server MEP is in the server layer, right?
The AIS is in the client layer, yes?
The adaptation function is in the client or the server layer? Possibly 
not important.
The adaptation function is not a MEP in the client layer, so it cannot
generate client layer OAM.
Does this mean that the AIS is in the server layer?
And the direction is opposite to what?

I am left wondering whether AIS (which may be a useful and required 
function) completely breaks the definition of MIP. That could be fine!
There doesn't seem to be any specific reason not to allow MIPs to 
"spontaneously" generate informative OAM messages.

Note that the same discussion applies to LKR in section 5.4.
---
5.6
I struggle to see how Client Failure Indication is abbreviated as CSF!
---
Seem to be missing a section on OAM loopback. I think this would be in
section 6 not in section 5. Perhaps 6.4 is close, but not the same, I
think.
---
6.1
   This functionality may 
   not be available for associated bidirectional transport paths, as the 
   MIP may not have a return path to the source MEP for the on-demand CV 
   transaction. 
Add unidirectional transport paths to the "may not be available" clause.
---
Section 7
The Security section needs some beef!

You don't have to answer the problems here, but you need to call them
out. For example:

What happens if someone can insert an OAM packet into a flow?
Answer, they can make it appear that there is a misconnection, and that
interrupts legitimate traffic.

There must be a bunch of similar issues that you need to list with 
bullets.

You also need to say that individual OAM solutions documents must
include security provisions.

I wonder if you should discuss the issues about using security within 
OAM packets. Will this impact line-speed OAM? What security
relationships would be implied? For example between a MEP and all of
the MIPs and MEPs in the ME.

---
Section 9
   T-MPLS Ad Hoc Group
I think it is now called Ad Hoc Team on MPLS-TP.
---
10.2
I think [12] is normative.
---

PS. Really good job with the ASCII art!