[mpls] MSRP discussion

Huub van Helvoort <huubatwork@gmail.com> Mon, 20 April 2015 20:19 UTC

Return-Path: <huubatwork@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49261B305B for <mpls@ietfa.amsl.com>; Mon, 20 Apr 2015 13:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 oCuWWtxc5Lkn for <mpls@ietfa.amsl.com>; Mon, 20 Apr 2015 13:19:34 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 D3BEC1B3054 for <mpls@ietf.org>; Mon, 20 Apr 2015 13:19:33 -0700 (PDT)
Received: by wiun10 with SMTP id n10so105503310wiu.1 for <mpls@ietf.org>; Mon, 20 Apr 2015 13:19:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vqVC2aHjDfynQ1Hly4RC0k5ipx1SM54cZBZVojIvT7I=; b=pz1IdFbtuY9uUCnAsZu35Xry9Ds+/GaeWduZGl4aYKIV39msq0E35YkpFk8fb9Wsio RZ3SCKSgttVR1bzNI3nXE8frjg/QZ+L7KKV8YPV57PblJd9KXwKyYHo1Jz/0OfHNgjF+ wqK4Ozobvq3CggIm/tX1j12GWSJYtCC72S49kvqjo/Il6OLhQJ1Glmcl/ND8RlQB/1dH UZVsvdT2nOzRB2GMZ9RkmX9jbMQlzNHcCtngDmISDSFtREgROfcsvYbWxGf9w7GzLvvo EHzzykr78rj69F8an4mDLCHXmQUwviK/F4WSsGJhtf0tCCPiNOdT9vwxdsiQVOBmlCns lBpA==
X-Received: by 10.194.177.132 with SMTP id cq4mr32841772wjc.99.1429561171739; Mon, 20 Apr 2015 13:19:31 -0700 (PDT)
Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id es5sm28706981wjc.30.2015.04.20.13.19.30 for <mpls@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 13:19:30 -0700 (PDT)
Message-ID: <55355F51.1010306@gmail.com>
Date: Mon, 20 Apr 2015 22:19:29 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: mpls@ietf.org
References: <D1545CF7.CB51%tsaad@cisco.com>
In-Reply-To: <D1545CF7.CB51%tsaad@cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/989Wwu07iYecznIxiTZ-1dunguw>
Subject: [mpls] MSRP discussion
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: huubatwork@gmail.com
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: <http://www.ietf.org/mail-archive/web/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: Mon, 20 Apr 2015 20:19:35 -0000

All,

In:

> Below are the *_preliminary_* minutes taken during IETF92 MPLS sessions.

I noticed the following discussion:

> Liang Geng’s (China Mobile) presentation on MSRP:

> - Eric Osborne said that this draft needs some discussion as to why the
> existing RFC(s) are inadequate.
> - Loa asked if this observation applies to both this draft and Kireeti’s
> draft.
> - Eric said that – in his opinion – Kireeti’s draft already provides
> enough info to distinguish its applicability.

Section 2.3 of draft-cheng-mpls-tp-shared-ring-protection
describes the Configuration Complexity.

I will try to provide some more details:

Suppose a ring with N nodes.
---------------------------
Applying RFC6974 means that from every ring-node a linear
protection configuration has to be provisioned with every other
node in the ring, i.e. with (N-1) other nodes.
This means that in every node there will be (N-1) instances of
the PSC protocol.
In order to detect faults and to transport the PSC OAM each
instance shall have a MEP on the working path and a MEP on the
protection path. (A MEP == co-located so_MEP and sk_MEP).
This means that every ring-node should have the capability to
support (N-1) * 2 MEPs.

Applying draft-cheng-mpls-tp-shared-ring-protection means that
in every ring-node there will be a single instance of the MSRP
protocol.
In order to detect faults and to transport the MSRP OAM each
instance (e.g. in node N) shall have a MEP on the working path
and a MEP on the protection path to node (N-1) and also to
node (N+1).
This means that every ring-node should have the capability to
support 2 * 2 MEPs.

Suppose a ring with N nodes, and one node has to be added:
---------------------------------------------------------
Applying RFC6974 means that every existing ring-node has to
be updated: a new PSC protocol instance created, and 2 MEPs
instantiated.
In the new node N PSC instances have to be created and
N * 2 MEPs instanciated.

Applying draft-cheng-mpls-tp-shared-ring-protection means that
in every existing ring-node the ring-map has to be extended.
In the new node a single MSRP instance has to be created and
4 MEPs instantiated.
Note that the 4 MEPs have to be instantiated anyway to be able
to monitor the links with the adjacent ring-nodes, so in fact
only the MSRP OAM has to be enabled.

Regards, Huub.


-- 
*****************************************************************
               请记住,你是独一无二的,就像其他每一个人一样