Re: [trill] MD-levels and TRILL

[Donald Eastlake <[e-mail]>]

Hi Anoop,

On Tue, Nov 6, 2012 at 6:09 PM, Anoop Ghanwani <[e-mail]> wrote:
>
> There are a couple of challenges that I see with trying to
> define the use of MD-levels with TRILL.

I agree that there is still design work to be done.

> MD-levels in the IEEE world were used to creates multiple
> levels at which CFM can be run.  For example, if I buy a service from a
> provider and start running CFM, only my boxes (my network and
> the edges of the provider network) will see and respond to those
> CFM messages.  Maybe this type of service model doesn't
> make sense for TRILL because, if the provider implements
> the transport using RBridges, then the customer and provider
> will have to make sure they assign their nicknames from the
> same space.  But let's leave that issue aside for now...

Generally I would expect provider facilities to be transparent to
customer TRILL OAM.

I can see reasons for 3, possibly 4, different levels within the
customer TRILL level. First of all, there is multi-level IS-IS which
would yield two levels, traditionally called level 1 and level 2. Then
there are ideas like that in draft-wu-trill-lsp-ext-tree-distr-opt
which could produce sub-areas within a level 1 area which we might
call level 0. Then there are idea like that in
draft-ietf-l2vpn-trill-evpn which could lead to a level above level 2,
which you could call level 3. Of course, if you were using the
MD-leels, you could map these into different numbers in the range 0 to
7.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

> The first challenge is that TRILL depends on the Hop Count
> for some of the OAM messages to decide whether they are
> processed by an RBridge.  This means that it is not possible
> to send these messages in a way that is transparent to
> set of RBridges.  So pretty much all OAM messages must
> be processed by all RBridges along a path regardless of
> level.  So I'm not sure what the concept of MD-level would
> buy us.  At best it may be used for filtering and that too in
> the control plane, but I personally don't see much value there.
>
> The second challenge is related to accessing the MD-level
> within the frame to know whether or not to process it.
> Because the MD-level would follow the 128-byte entropy,
> I am not sure that existing silicon, and maybe even emerging
> silicon, will be able to access those bits, so that level of
> filtering may have to be done in software.  I think this should
> be clearly called out in the draft.
>
> Anoop