[mpls] Why draft-turaga-mpls-test-labels-00 ?

Shahram Davari <shahram.davari@broadcom.com> Wed, 06 April 2016 15:21 UTC

Return-Path: <shahram.davari@broadcom.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACD12D618 for <mpls@ietfa.amsl.com>; Wed, 6 Apr 2016 08:21:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLHhCW-4e-Hh for <mpls@ietfa.amsl.com>; Wed, 6 Apr 2016 08:21:56 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4717112D838 for <mpls@ietf.org>; Wed, 6 Apr 2016 08:18:05 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id t10so60655588ywa.0 for <mpls@ietf.org>; Wed, 06 Apr 2016 08:18:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to; bh=ubWiCP+SqR4Xaf+0FDg9fh6ruu/+Q8qKvp7hQKSd3xE=; b=QTnGr71wP07xj4t44Vvko0IecAIxZSZh2W1keKYn2vinKYq9JkHBLhmVpFKbVrPGIb 2TkELoS8PdvOGk/yeZnZ3muaLtf9Wnzbjnc6KtxBqxSbPWD2yCWnloDRy5efPOoEeFhG 553dp6uFpnAYlrAgbQf9mzZ5/gohrNUv6qVZM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=ubWiCP+SqR4Xaf+0FDg9fh6ruu/+Q8qKvp7hQKSd3xE=; b=STCii01rk+D+1+1eNIxIQre7Y2GP5PdBOqAdlajWrICvdZT4DlKbkQliS4cfuE+uHJ ytPhS7tBueGOZtBh5JJBQx7ZkKBcEDgVRarDwGqgvvCV/PJLxnVX67b1tJCRiCx1ught 2RhlMeNqYi2m7wiyPE4HJLdD0RR0nav0KYvn+ibXw7FQM9xp8x5Cmp/cXkSjnV4QB8/j cdLxkdMz4TGwpliqHBYjX7V9kKOnElGzIJ0WfTT5egwisH8m0AqzlkNxbLQHiPD5z6Wj kaboe3z7JejBzc0ffXZQH4MJPKMkYFppFdLoIXL0OX5iiiBe08/RtFb0k7HCMlJW0aMP Q61g==
X-Gm-Message-State: AD7BkJITNTv6zervJFDE+fbKbxeI3WDb5MdjClGheUY2/uuUrF0VuQAYdmHD3nVb2bZNIVKbeQpL27FydIijPJvQ
X-Received: by 10.129.94.194 with SMTP id s185mr11691117ywb.93.1459955884316; Wed, 06 Apr 2016 08:18:04 -0700 (PDT)
From: Shahram Davari <shahram.davari@broadcom.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdGQFuNkf/yMV093SV+3R9XQ02JvMg==
Date: Wed, 06 Apr 2016 08:18:02 -0700
Message-ID: <7b798c1472931d52a65218b896fa67de@mail.gmail.com>
To: mpls@ietf.org
Content-Type: multipart/alternative; boundary="001a1147086ee00760052fd277ee"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/cB3240UxWaW7ufZeDB3wUkkUH9o>
X-Mailman-Approved-At: Wed, 06 Apr 2016 13:02:49 -0700
Subject: [mpls] Why draft-turaga-mpls-test-labels-00 ?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Apr 2016 15:28:35 -0000

Hi,



I just want to repeat my comments in today’s meeting. There are existing
solutions to the problem stated in this draft.



Specifically one can use RFC6374 (MPLS LM) using Section OAM . The MPLS LM
uses HW counters and the MPLS LM packets are sent

Very infrequently by CPU (every minute or more). Any degradation of the
connection between two adjacent routers can  be easily detected,

With infrequent CPU processing time.



So I don’t support this  draft and think we should not invent new solutions
when reasonable existing solutions exist.



Thx

Shahram