Re: [mpls] YANG for MPLS-TP?

Greg Mirsky <gregimirsky@gmail.com> Wed, 31 January 2018 01:32 UTC

Return-Path: <gregimirsky@gmail.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 614801201F2; Tue, 30 Jan 2018 17:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level:
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oUmDTzofb1C8; Tue, 30 Jan 2018 17:32:18 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 5AE7512EC9C; Tue, 30 Jan 2018 17:32:16 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id g72so18216075lfg.5; Tue, 30 Jan 2018 17:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bdYZyanUGZiCaypO1Erac2fWwRaHxQHAb3MSh2V/sq4=; b=SIMrvvL0BqpZ4u3njMl9SiMwuvugAPLvEs98oolyU6XYYJmt9WMQkAiOSys9CFEg3d KE1nJeDtXtE/z1ApcM7SuLD8tB6YlAfH3OEDUtkj0LnPVCOPA3qWnhOlS7Iii0Fa4m8K uwI4bIJnozOw5tMpjgq8crqMsCm5D8HShLVy6N1tEp3xMAzA1qAYRJ0JUU8hXuo/J91r inKPI5V7zeiXaaVSslD249ZXoM2S0yIoJvxM/3CSZxKBzpGNpcCs7j9odmz61K2G4Evk iB8CqQ2YK7k/8In8DI0HfRIVl06qYj7L3i0pCcT52p5mFAF1ARBgqxMLWQdOGxb+lwiX i5ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bdYZyanUGZiCaypO1Erac2fWwRaHxQHAb3MSh2V/sq4=; b=tcPT3OLzIvkpqycKHK1RDmefqBlCOnspXqb0fmTsfYdYqGOMv2CjUls0UpLDC0lu5A AJ1JWqXPLoxuIiWexTCgsSGu4gD++oKWx8c/MlfkpOqT6sgRFdYc+bPWKEUfb/zYPVFx u59e/AUxwlZ9643FH0yIxRERfb2r36+Tz1vNgnPKB8/b5bttXv0deI8ilo2CqExnEeN1 saemuKlIvC4czjaCF54Ct0ZpasKQiq5BW6rWwdN/4Z4bhrnkOrfdJxPaIAgBqztsaSbC 8THddlSDlFy3BNieDyBrqVj1pLCTb54L59NNG/PNr+Y57/EdgN+F8aAzy1p7siqC+tgm qwlA==
X-Gm-Message-State: AKwxytd75BaekXeeqbO37Q3BZWQsRZ7YlbQXsnINO6oZqCMpMHXAGa82 WI+GSvK3hjweRfR0nLZ0EMAPElophK+liH8770s=
X-Google-Smtp-Source: AH8x226IPOIqFOU38g9x02rtwpS5Yqt6F6x+xzdRlIrlDBmlamaq0rzqmLWrIdXaYsKEBVrhCobS8pQXE8PjJ5JT7IY=
X-Received: by 10.25.217.210 with SMTP id s79mr17804047lfi.73.1517362334009; Tue, 30 Jan 2018 17:32:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.46.83.91 with HTTP; Tue, 30 Jan 2018 17:32:10 -0800 (PST)
In-Reply-To: <HE1PR0301MB226639582EEEE9D50D74E7889D540@HE1PR0301MB2266.eurprd03.prod.outlook.com>
References: <HE1PR0301MB226639582EEEE9D50D74E7889D540@HE1PR0301MB2266.eurprd03.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 30 Jan 2018 17:32:10 -0800
Message-ID: <CA+RyBmVr23G6rkOC05TXZnvh-+2YuVCOg5Vx_EiVWCtM+x3-pA@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Loa Andersson <loa@pi.nu>
Cc: "draft-ietf-mpls-static-yang@ietf.org" <draft-ietf-mpls-static-yang@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>
Content-Type: multipart/mixed; boundary="94eb2c063c34eb473b0564087236"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/I_uECZugtY1x8j5wKnnGkdZ70Sk>
Subject: Re: [mpls] YANG for MPLS-TP?
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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, 31 Jan 2018 01:32:24 -0000

Hi Sasha,
although we had MPLS WG invited to the discussion, I'm calling on Loa (hi,
Loa!) to look into it.
Your the most detailed questions prompted me to investigate and ask my
colleagues. Indeed, ITU-T SG-15 is working on G.8152  Protocol-neutral
management information model for the MPLS-TP network element. SG-15 uses
UML to define informational model so that, as I understand, YANG data model
can be produced automatically (almost). I haven't inspected the document in
all the details but got feeling that MPLS-TP Identifiers and MPLS-TP OAM,
ITU-style, have been addressed. Taking on IETF-style MPLS-TP OAM YANG model
seems to me both logical and useful. Should we, or someone else interested,
take on MPLS-TP Linear and Ring protection RFCs - depends on whether SG-15
using G.8131 sufficiently cover RFC 6378.
I'm very much interested to have comments from MPLS WG whether work on
aspects of MPLS-TP data model, including  draft-zhang-mpls-tp-yang-oam ,is
of interest and has WG support.

Regards,
Greg

On Tue, Jun 14, 2016 at 3:22 AM, Alexander Vainshtein <
Alexander.Vainshtein@ecitele.com> wrote:

> Hi all,
>
> I wonder what are the WG plans (if any) regarding YANG data models for
> MPLS-TP.
>
>
>
> While it is obviously true that static MPLS and MPLS-TP are different
> (neither is the subset of the other), MPLS-TP is today the most important
> application of static MPLS.
>
>
>
> However, after looking up  draft-ietf-mpls-static-yang
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-static-yang/?include_text=1>
> I did not find there any mention of MPLS-TP-specific issues.
>
>
>
> One example that comes to mind is co-routed bi-directional and associated
> bi-directional MPLS-TP LSPs. Other issues include:
>
> 1.       MPLS-TP Identifiers (i.e. YANG model for RFC 6370
> <https://tools.ietf.org/html/rfc6370>). From my POV such a data model is
> a pre-requisite for all MPLS-TP-related work
>
> 2.       MPLS-TP protection mechanisms
>
> 3.       MPLS-TP OAM mechanisms. There is an individual draft
> <https://datatracker.ietf.org/doc/draft-zhang-mpls-tp-yang-oam/?include_text=1>
> that tries to address these issues, but it looks to me like very much
> incomplete. E.g.:
>
> o   It does not even mention RFC 6428
> <https://tools.ietf.org/html/rfc6428>
>
> o   While RFC 6427 <https://tools.ietf.org/html/rfc6427> appears in the
> list of Normative references in this draft, there are no actual references
> to this document.
>
>
>
> Any inputs in this regard would be highly appreciated.
>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell:      +972-549266302 <+972%2054-926-6302>
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>