[CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)

["George Swallow (swallow)" <[e-mail]>]

Authors -

Some comments just on the FM parts for now.

Section 3.1.3. Configuration of Fault Management Signals

The first three paragraphs of this section have nothing to do with Fault OAM except the last phrase of the first paragraph, "and Fault Management Signal handling."

The text in the first paragraph needs to be moved above the PM and Fault sections. The second and third paragraphs belong in the PM section.

The forth paragraph needs some work, but I defer on suggesting rewording until we decide the issues below.

Section 3.5.  MPLS OAM FMS sub-TLV

1.  The way the section is written, it appears to be concerned with what signals are produced by endpoints (as opposed to how endpoints will react to received FM OAM).  In that case, I don't see the point in having an "D" flag.  LDI is a flag carried on the AIS message.  If a implementation supports the LDI flag it will set it appropriately.  If it doesn't it will never set it.  What configuration is needed?

2.  Why do we need independent configuration of the L and A flags.  Under what circumstances would an operator want one and not the other?  Remember that options cost real $$$ to develop (small) and test (not so small since you have to do all combinations and often test against multiple releases including interoperability with other vendors).

3.  I believe operators will want to set FM timers on a node-wide basis (or perhaps a card-wide basis).  Generally I see no point in one end of a TP LSP telling the other how this timer should be set.  Further there is no need for consistency in the two directions.  If it were up to me I would drop it.

I suppose that is some rare circumstances if the End Service is MPLS-TP a customer (client of the SP) might want something special. So if folks want to retain it, then I suggest another flag that says timer field valid. The default setting of the flag would be 0, I.e. no timer.

4.  The draft correctly states that it is not intended to configure mid-point behavior of the server MEP.  But I do believe it is worthwhile to have an FM subscription flag in the object for server layer MEPs to examine and determine if the LSP would like any AIS/LKR messages that the server layer produces sent on this LSP.  This should be a SHOULD.  Ie.  At each hop of an LSP, nodes SHOULD examine the FM subscription flag.  If the flag is set then the server MEPs at this node SHOULD insert FM messages as appropriate in this LSP.  If the flag is not set these MEPs SHOULD NOT insert FM messages.

…George