Re: [trill] cc in "draft-ietf-trill-oam-framework-00"

"Samer Salam (ssalam)" <> Fri, 07 December 2012 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B818521F85E3 for <>; Fri, 7 Dec 2012 08:33:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ewnj5H52H0ck for <>; Fri, 7 Dec 2012 08:33:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DD70E21F860B for <>; Fri, 7 Dec 2012 08:33:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10062; q=dns/txt; s=iport; t=1354898000; x=1356107600; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=iWJcnwTB17TSo7GmNXHgXhC7rKzt3R5siDLFtFuLkKk=; b=K+JTh8CQ3r/fQWBYWY0ylsl+gg9FIexqs4NEvnF2sLH5drfEMNF4zzVJ QPcaDFEn5/BMRMSjbCa2n6fo84fMo2/6PUMIZqK32UlqDi3EN3t6MrbnY +2WaqwB9K2Uz7qBRg8imFW0RZAzf4Sr1+6ZNSBfBJ64vDnQSXOUaZOF5Q k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="5400,1158,6918"; a="150528579"
Received: from ([]) by with ESMTP; 07 Dec 2012 16:33:16 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qB7GXGUF013790 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Dec 2012 16:33:16 GMT
Received: from ([fe80::5404:b599:9f57:834b]) by ([]) with mapi id 14.02.0318.001; Fri, 7 Dec 2012 10:33:16 -0600
From: "Samer Salam (ssalam)" <>
To: "" <>, "Tissa Senevirathne (tsenevir)" <>, "" <>, "" <>
Thread-Topic: cc in "draft-ietf-trill-oam-framework-00"
Thread-Index: AQHNzRpEavPGDd8Go0uh6VvMEcqUSZgNdVyA
Date: Fri, 7 Dec 2012 16:33:15 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8F25FF8EA49D164EBE5F1B5AD33F3BC90D81801Axmbalnx13ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [trill] cc in "draft-ietf-trill-oam-framework-00"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Dec 2012 16:33:24 -0000

Hi Xuehui,

From: "<>" <<>>
Date: Tuesday, November 27, 2012 7:41 PM
To: "Samer Salam (ssalam)" <<>>, "Tissa Senevirathne (tsenevir)" <<>>, "<>" <<>>, "<>" <<>>
Cc: "<>" <<>>
Subject: cc in "draft-ietf-trill-oam-framework-00"

Hi, all trill-oam-framework authors

I have some troubles on understanding cc function described in section 4.1.1 in draft-ietf-trill-oam-framework-00, wish you can help me for more clear understanding.

1. 4.1.1<> Fault Detection (Continuity Check)
The proactive fault detection function must detect the following
  types of defects:

  - Loss of continuity (LoC) to one or more remote MEPs
  - Unexpected connectivity between isolated VLANs (mismerge)
  - Unexpected connectivity to one or more remote MEPs
  - Period mis-configuration"

In my mind, maybe the sencond and third types of  defects should be defects detected by CV ?

The reason for having these functions part of CC as opposed to CV is primarily to allow for continuous checking of these defects, as they may be introduced at any point of time in the life-span of a live network, due to nodes being commissioned/ de-commissioned or VLANs being added/deleted. As long as these types of issues are being monitored by CC, the operator will be assured that there is pro-active detection, as opposed to only knowing of the issues when a user complains.

2.<> Forward Defect Indication

a simple network comprising of four RBridges connected in tandem: RB1, RB2, RB3 and RB4. Both RB1 and RB4 are hosting TRILL OAM MEPs, whereas RB2 and RB3 have MIPs. If the link between RB2 and RB3 fails, then RB2 can send a forward defect indication towards RB1 while RB3 sends a forward defect indication towards RB4......"

my question is how to detect the link faliure between RB2 and RB3 , through TRILL oam? such as one hop TRILL BFD?

The link failure may be detected through a number of mechanisms:

  *   By observing the line-protocol state going down on the link.
  *   Through some link OAM mechanism such as 802.3 clause 57
  *   Through TRILL BFD as you indicated

3.Does CC should be supported on sections? if it is, how the ingress and egress nickname be set? the same as CV on sections( see the last paragraph in section in trill-oam-framework)?

Per draft-ietf-trill-oam-req-04 section 4.3, this is a SHOULD requirement. One way to support this, as you mention, is to follow the same nickname scheme as CV on sections.


please correct me if I have some misunderstanding :)

Best Regards,