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

Elisa Bellagamba <> Wed, 29 August 2012 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6B7421F85A7 for <>; Wed, 29 Aug 2012 03:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EXSVCjEehPBY for <>; Wed, 29 Aug 2012 03:13:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 30D7121F8581 for <>; Wed, 29 Aug 2012 03:13:51 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-a4-503deb5c8135
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 22.F1.11467.C5BED305; Wed, 29 Aug 2012 12:13:48 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Wed, 29 Aug 2012 12:13:48 +0200
From: Elisa Bellagamba <>
To: "" <>
Date: Wed, 29 Aug 2012 12:13:47 +0200
Thread-Topic: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)
Thread-Index: AQHNZb6Whbfk59sgCEWkiDX95wuk0Zc7U7YggDV9xwA=
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_666A6B6D38439F49A7FB8E0FE839CA0635793C1BCAESESSCMS0365e_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3VjfmtW2AwdzbBhZP5txgsTiw4Ruj xb+5c5gtLk2Yymxxe0oTowOrx4fjJ9k8pvzeyOqxZMlPJo9Z09vYAliiuGxSUnMyy1KL9O0S uDKmLzvDXvAkomLtszPMDYyTfboYOTkkBEwkFp89xghhi0lcuLeeDcQWEjjFKHFhk3UXIxeQ PZdRYvfboyxdjBwcbAJmEusWlYPUiAioSpy5eZERpIZZ4D6jxNcNT5hBEixAiW9H+lhAbGGB DImbuzvZIRoyJb4f288EYVtJvHr5HyzOKxAusfHfLjaQ+UJA9rL+WpAwp0CExMENC1hBbEag 276fWgPWyiwgLnHryXwmiJsFJJbsOc8MYYtKvHz8D6peVOJO+3pGiPp8iSfvpjJBrBKUODnz CcsERtFZSEbNQlI2C0kZRFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRfxSicm5iZk15u qJdalJlcXJyfp1ecuokRGJsHt/zW3cF46pzIIUZpDhYlcV6upP3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhj5z5vcUG7Lmtv+mePs1CTRsCS/BZo9E4wVWbWDesO+n2mX80z/eDTd6+Fe S2+Bjak3rsuev6pdrPKg7c7OlvL5pS5fGmRfdtuU/9jUWpR7/ZSfTOPvF/tv5JyYmt3nJ8O9 6WE8g430pbSG5NxfU9YbvGA0zulcfOloc1GGQ9nhT9uXT+dr/qHEUpyRaKjFXFScCABO2oTC mwIAAA==
Cc: "" <>
Subject: Re: [CCAMP] Comments on Fault OAM Configuration (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Aug 2012 10:13:53 -0000


please find George's comment resolved here

Best Regards,
Elisa and Pontus

From: [] On Behalf Of George Swallow (swallow)
Sent: Thursday, July 19, 2012 4:57 PM
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.