IETF Logo Mail Archive

Re: [mpls-tp] Demultiplexing to BFD sessions

David Allan I <david.i.allan@ericsson.com> Wed, 30 June 2010 19:31 UTC

Return-Path: <david.i.allan@ericsson.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99193A691F; Wed, 30 Jun 2010 12:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.314
X-Spam-Level:
X-Spam-Status: No, score=-4.314 tagged_above=-999 required=5 tests=[AWL=2.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSC6xFDj3v5d; Wed, 30 Jun 2010 12:31:12 -0700 (PDT)
Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 154483A68F3; Wed, 30 Jun 2010 12:31:10 -0700 (PDT)
Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o5UJcm4M004279; Wed, 30 Jun 2010 14:38:48 -0500
Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.39]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 30 Jun 2010 15:30:58 -0400
From: David Allan I <david.i.allan@ericsson.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 30 Jun 2010 15:30:55 -0400
Thread-Topic: [mpls-tp] Demultiplexing to BFD sessions
Thread-Index: AcsYiUKecJZVSD//Rq6UcEWOlxFvfwAACOowAABPPtA=
Message-ID: <60C093A41B5E45409A19D42CF7786DFD51815EF4DD@EUSAACMS0703.eamcs.ericsson.se>
References: <AANLkTikZurkVBrPNBjL-v7zdZ9dTLUBDuBnNDPsCrnJf@mail.gmail.com> <OF7E03B6CE.B5C7073D-ON48257750.000D15FC-48257750.000D4123@zte.com.cn> <716209EC190CA740BA799AC4ACCBFB5D180C3C7126@IXCAEXCH07.ixiacom.com> <AANLkTikdY-qChtT8-po0L6eCjW6qWQ2LzqMhG1eysmvP@mail.gmail.com> <2C2F1EBA8050E74EA81502D5740B4BD6940E808F75@SJEXCHCCR02.corp.ad.broadcom.com> <60C093A41B5E45409A19D42CF7786DFD518156D6E3@EUSAACMS0703.eamcs.ericsson.se> <AANLkTinSalhepoG_AuvNLbVWHTgkF01etfLzRXWxpr5c@mail.gmail.com> <60C093A41B5E45409A19D42CF7786DFD518156D754@EUSAACMS0703.eamcs.ericsson.se> <AANLkTinzsvrfAbBrkLObJmXd4fNvk8CyOKokNE16UGpT@mail.gmail.com> <60C093A41B5E45409A19D42CF7786DFD51815EF047@EUSAACMS0703.eamcs.ericsson.se> <AANLkTil3WKCCWjKm_O05NGFa1uXDQKi8eTuYTe3y9822@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD51815EF4DDEUSAACMS0703e_"
MIME-Version: 1.0
Cc: "mpls-tp-bounces@ietf.org" <mpls-tp-bounces@ietf.org>, Mukund Mani <mukund.mani@gmail.com>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2010 19:31:28 -0000

Resend after snipping, the thread has gotten too long...
Hi Greg:

IMO implementation does matter. Why would I postulate a standard that required me to do the same basic function two ways...?

A piece of general purpose MPLS silicon would then need to do both, state indexing by discriminator, and state indexing from the ILM. Which IMO is more gates, more heat, more to go wrong, longer verification cycle. yadda yadda yadda....

cheers
D

________________________________
From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Wednesday, June 30, 2010 3:19 PM
To: David Allan I
Cc: Shahram Davari; Mukund Mani; Apratim Mukherjee; xiao.min2@zte.com.cn; mpls-tp@ietf.org; mpls-tp-bounces@ietf.org
Subject: Re: [mpls-tp] Demultiplexing to BFD sessions

Dear Dave,
thank you for the insight. Though I was under impression we're not talking about implementations here ;)

In my view, the check whether MEP ID matches your Discriminator is redundant (well, the implementation has a bug otherwise). The real continuity check is whether context of a transport channel (label stack) and demultiplexor (MEP ID or Your Discriminator) match. Since the Unique MEP ID is required, the discriminator, or at least its role in CV can be optional.

Regards,
Greg

2010/6/30 David Allan I <david.i.allan@ericsson.com<mailto:david.i.allan@ericsson.com>>
Hi Greg:

I've made this point before, the discriminator is simply a receiver administered "helper" for indexing state.

Compare the two simplistic pseudo code examples below...how a recevier checks for a valid MEP ID and received label....

if (bfd_message.mep_ID != recevier_bfd_state[bfd_message.your disciminator].expected_mep_ID]) error...
if (received_label != recevier_bfd_state[bfd_message.your discriminator].expected_label) error...

vs.

for (i=0;i<max_discriminators;i++) {
    if (bfd_message.mep_ID == recevier_bfd_state[i].expected_mep_ID) break;
}
If (i== max_discriminators) error....
if (received_label != receiver_bfd_state[i].expected_label) error...

The these examples are the general case solution that works for all modes of operation of MPLS (including PHP). We can redesign it to index state based on received label but why have two distinct implementations? I thought the goal here was re-use where possible...

I hope this makes it clear...

D

v2.8.7 | Report a Bug | By Email