The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Loa,
Thanks for this.

Two overall questions:

1.
Given that...
    This memo outlines in broader terms how data plane OAM functionality
    can assist in meeting the operations and management (OAM)
    requirements outlined in [MPLSREQS]
is it appropriate to last call this draft before [MPLSREQS] is complete?

2.
The draft restricts itself to RFC3031 in section 1.
This may be intended to give a context to MPLS rather than to limit the
scope (although the title of the section does imply a limited scope).
Given the recent decision to include P2MP MPLS-TE OAM requirements within
[MPLSREQS], shouldn't this draft be broadened to also included P2MP within
the framework?
On an initial reading, there doesn't seem to be much that is needed to
extend this, but some discussion of partially defective LSPs is needed in
the context of P2MP.


A few comments on the draft...

Abstract
I think it would be good if the Abstract could refer to MPLS.

Section 1
I think it would be helpful if there was a definition of "OAM" and "data
plane OAM" and if these were contrasted with "operations and management
procedures". These may be common terms in the Ops Area, but in order to
bring MPLS into line, it is probably worth clarifying or providing
pointers.

Section 3.1.1, Physical layer faults:
There seems to be an admixture in the text that confuses "physical layer",
"link layer" and "lower layer". I suspect that from an MPLS perspective we
are only interested in lower layer faults and wish simply to observe that
these may be detected by lower layer protocols or reported by the physical
layer. Then, as you say, we also need to observe that in some cases the
lower layers may not be able to detect such faults and we may need to
operate a higher layer mechanism.

Section 3.1.1
    MPLS LSP misbranching:
Why do you call this "misbranching"? Is there any branching involved?
Would "misconnection" or "forwarding error" be better terms?
In fact, isn't this what is later described as "data plane integrity"?

Section 3.1.1
    Discontinuities in the MPLS Encapsulation
The way this section is worded it does not appear to describe a fault (per
the original definition of fault). It actually states how data may be
successfully delievered.
I suspect that the text needs to point out two ways in which this may be a
fault:
- the data is delivered but does not use the LSP for the full extent of
its path (thus frustrating the operator's intent and potentially impacting
QoS or causing mis-delivery)
- the data cannot be delivered at all.

Section 3.1.1, TTL Mishandling
         Some Penultimate hop LSRs may consistently process TTL expiry
         and propagation at penultimate hop LSRs. In these cases, it is
         possible for tools that rely on consistent processing to fail.
Does this mean "inconsistently"?

Section 3.1.1, Misordering
We should point out that probe traffic is a highly unreliable mechanism to
detect misordering since the problem is not necessarily predictable or
reliably repeatable.

Section 3.3 Availability
The definition of availability is fine. But what is meant by the
following?
    MPLS has several forwarding modes (depending on the control plane
    used). As such more than one model may be defined.
Does this say that there may be more than one definition of availability?
Or more than one way of computing it?

Section 7 Intra-provider
The first paragraph seems to suggest that data plane OAM does not have any
potential detremental effect on security. But the third paragraph lists
some of the issues. I suggest that the first paragraph should be
re-written as:
    Data plane OAM messaging addresses some existing security
    issues, for example through rigorous defect handling operator's
    can offer their customers a greater degree of integrity protection
    that their traffic will not be misdelivered (for example by being
    able to detect leaking LSP traffic from a VPN).

Section 7 Inter-provider
This is the first mention of inter-provider. It would really be worth
adding a section earlier to discuss inter-domain issues (inter-area,
inter-AS and inter-provider). Is OAM terminated and regenerated at
borders?

Section 7
I am not sure that it is safe to assume that MPLS does not extend to
"untrusted hosts". Some routers may be more prone to hacking than others.
Thus, OAM messaging may require authentication, etc.


Editorial

References to "MIBs"
In general, all references to MIBs should really be references to "MIB
modules".
For example, in section 3.1.1 "MPLS MIB performance tables" should read
"MPLS MIB module performance tables".

Please say "cross-connect" not "cross connect"

Section 3.1.1, MPLS LSP misbranching:
           into a an NHLFE for which there is no corresponding ILM at
s/a an/an/

Section 3.1.1, MPLS LSP misbranching:
           corresponding ILM at the next downstream LSR, but which was
           is associated with a different LSP. This may be detected by
s/was is/is/

Section 3.1.1, MPLS LSP misbranching:
s/the inconsistency between the path and the control plane/the
inconsistency between the data path and the control plane state/

Section 3.1.2
s/hand ling/handling/

Section 3.1.2
 s/(i.e.: fibre cut)/(e.g., fibre cut)/

Section 5
s/in MPLS network/in MPLS networks/

13.1  Normative References
This section appears to be empty.


Adrian


_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls