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

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

Elisa -

Though we've moved in the right direction, I don't consider my I said I would have more detailed comments this week.  Here they are:

OLD:

   Signal Flags should be processed at intermediate nodes as they
   MAY not only affect end-points only.  They are used to enable the
   following signals at end points:

NEW:

   FMS Signal Flags are used to enable the FMS signals at end point MEPs and the
   Server MEPs of the links over which the LSP is forwarded.  In this document only the S flag
   pertains to Server MEPs.

   The following flags are defined:

OLD:

      - S: Indicate to a server MEP that its should transmit AIS and LKR signals on
           the client LSP as well as one the server LSP. Default value is 0 (disabled).

NEW:

      - S: Indicate to a server MEP that its should transmit AIS and LKR signals on
           the client LSP. Default value is 0 (disabled).

OLD:

      Refresh Timer: indicates the refresh timer of fault indication messages. If the edge LSR receiving the Path message can not support such value, it can reply back with a higher interval. The refresh timer interval is given in steps of 0.5 seconds, giving a timer interval range of between 0.5 seconds (1) to circa 1 hour (8191).

NEW:

      Refresh Timer: indicates the refresh timer of fault indication messages.
If the edge LSR receiving the Path message can not support such value, it can reply back with a higher interval.

    [The rest of the text contradicts the Fault Management RFC.  Either delete it or align it.  My preference is to delete.]

Comment:

There should be some text to say that when both working and protect paths are signaled, both LSPs SHOULD be signaled with identical settings of the E flag, T flag and the refresh timer.  [Note I say SHOULD here only because it is beyond the control of GMPLS procedures to control this.]

…George

From: Elisa Bellagamba <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, August 29, 2012 6:13 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Pontus Sköldström <[e-mail]<mailto:[e-mail]>>, Attila Takacs <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, George Swallow <[e-mail]<mailto:[e-mail]>>
Subject: RE: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)


Hello,

please find George's comment resolved here http://diffchecker.com/v44hA973.

Best Regards,
Elisa and Pontus


________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of George Swallow (swallow)
Sent: Thursday, July 19, 2012 4:57 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)

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