Re: [trill] 802.1ag based messaging for TRILL OAM

Sunny Rajagopalan <> Thu, 05 July 2012 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4665321F846A for <>; Thu, 5 Jul 2012 12:07:46 -0700 (PDT)
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 04+bWymKPgeH for <>; Thu, 5 Jul 2012 12:07:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 44AC821F8690 for <>; Thu, 5 Jul 2012 12:07:43 -0700 (PDT)
Received: from /spool/local by with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <> from <>; Thu, 5 Jul 2012 13:07:54 -0600
Received: from ( by ( with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 5 Jul 2012 13:06:59 -0600
Received: from ( []) by (Postfix) with ESMTP id 495FB19D8050; Thu, 5 Jul 2012 19:06:57 +0000 (WET)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id q65J6f6G131300; Thu, 5 Jul 2012 13:06:44 -0600
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q65J6a1e004089; Thu, 5 Jul 2012 13:06:36 -0600
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q65J6arr004083; Thu, 5 Jul 2012 13:06:36 -0600
In-Reply-To: <>
References: <>
To: "Tissa Senevirathne (tsenevir)" <>
MIME-Version: 1.0
X-KeepSent: CFF45C3C:7A7AA64D-87257A32:006609C5; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010
Message-ID: <>
From: Sunny Rajagopalan <>
Date: Thu, 05 Jul 2012 12:06:38 -0700
X-MIMETrack: Serialize by Router on D03NM127/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 07/05/2012 13:06:36, Serialize complete at 07/05/2012 13:06:36
Content-Type: multipart/alternative; boundary="=_alternative 0068FAE988257A32_="
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12070519-6148-0000-0000-00000763A77A
Cc:, "" <>
Subject: Re: [trill] 802.1ag based messaging for TRILL OAM
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: Thu, 05 Jul 2012 19:07:46 -0000

Hi Tissa & all
The proposed 802.1ag-based frame format seems to be at odds with some of 
the stated objectives in the OAM requirements doc. 
The requirements doc says that the solution needs to be able to discover 
the various components of an ecmp for traceroute, loopback/ping etc. 
However, 802.1ag was developed for an environment that wasn't ecmp 
capable, so the frame format doesn't lend itself naturally for performing 
ecmp discovery. In particular, consider this:

a) The proposed method for OAM packet identification, which for IP is by 
matching on a src IP (plus rbridge in the case of unicast IP), will make 
the OAM packet take a different route than that taken by the flow you're 
trying to debug. Note that this was not an issue for an 802.1ag based CE 
environment because as long as you get the vlan right, data packets and 
OAM packets will follow the same (only available) path.

b) Further in the doc, (section 5:Loopback Message) seems to imply that 
the selection of the ecmp path would be signalled from the ingress 
somehow. Let's say that your network looks like this:
A-B-C-D, where B is connected to C by 3 paths and C is connected to D, 
also by 3 paths. Let's say you want to send a loopback message from A to 
D. How does A signal that B needs to pick the "first link in the ecmp" and 
C needs to pick the "third link"? The writeup seems to imply this 
information is somehow embedded in the loopback OAM TLVs. If it is, are 
the authors proposing that existing TRILL hardware change to be able to 
parse these TLVs?

Or is the intent is for the TLVs to be parsed and acted upon by software 
on intermediate switches? If yes, it would limit the usefulness of these 
OAM tools. These OAM tools (traceroute/ping etc) need to allow us to 
verify the state of programmed hardware, not the software state in 
intermediate switches. 

Essentially, we need to either drop the ECMP discovery requirement in the 
requirements doc or come up with a messaging format that satisfies it 
using the normal hardware forwarding path. A framework that relies on 
software forwarding only verifies that the network can deal with OAM 
packets correctly. It says nothing about the fate of non-OAM packets which 
go through hardware without getting trapped to the software stack.

Sunny Rajagopalan

From:   "Tissa Senevirathne (tsenevir)" <>
To:     "" <>
Date:   06/25/2012 08:53 PM
Subject:        [trill] 802.1ag based messaging for TRILL OAM
Sent by:

Dear All
We have published draft-tissa-trill-8021ag, which presents use of 802.1ag 
messaging as a common framework between different technologies. We also 
have discussed the related TRILL OAM model.
This is the -00 version and would like to welcome your comments
trill mailing list