The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

All,

for the record - the [MPLSREQ] == draft-ietf-mpls-oam-requirements-05.txt

were wg last called (as version -02) Mar 7 2004. We had
a fair amount of comments, and the draft has been updated
and reviewed by the routing area directorate since then.

Now Adrian has a point in that we are discussing to add p2mp oam
requirements into the [MPLSREQ] draft, however we don't see this
as a show stopper for the wg last call of draft-ietf-mpls-oam-frmwk-01.txt.

If we find impactss we just have to take care of those later.

/Loa


Adrian Farrel wrote:

> 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
> 
> 

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson@acreo.se
                                            loa@pi.se

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