Re: [Rtg-yang-coord] yang models intended for the mpls wg

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Mon, 03 August 2015 14:29 UTC

Return-Path: <cpignata@cisco.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B340C1A0266; Mon, 3 Aug 2015 07:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 o85QEE8VYGU4; Mon, 3 Aug 2015 07:29:06 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC021A00C7; Mon, 3 Aug 2015 07:29:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26512; q=dns/txt; s=iport; t=1438612145; x=1439821745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dpjACKBUH5b2l3olVCNzqmFAovvEs7kW332v5ek9ZiQ=; b=DajmNLlA2gc64fj2UNaWx59q9ecIOBp9P70jeugaf/06mDJv8cpkIkJ5 rIItkct9xKlgFcP2usviltZ+AhVhpdjZNxZ3KaaBa1881WjyA5xDcrSO9 0AXADbDXqkP25yMxdTRZ/tF3orWiqNetPBJGkYrHV/ejMPo3zsaqgxJrW o=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BIAwANer9V/4cNJK1bGQEBAYJ+VGkGgx25LgmBVgMGGwELhXcCgSo4FAEBAQEBAQGBCoQjAQEBAQIBAQEBIEgDBAcFBwICAgEIEQQBAQEnAwICGwYGCxQJCAIEDgUOiAsDCggNtHCQKQ2FMQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBItLgk+BVgoHASUoBAcGgmMvgRQFkXeDAgGCOIFZaYVmgWuBR5BSg0uDZCaDfW8BgQQJFyOBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,602,1432598400"; d="asc'?scan'208,217";a="174993533"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-8.cisco.com with ESMTP; 03 Aug 2015 14:29:04 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t73ET4V9023007 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Aug 2015 14:29:04 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 3 Aug 2015 09:29:03 -0500
Received: from xhc-rcd-x02.cisco.com (173.37.183.76) by xch-rcd-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Mon, 3 Aug 2015 09:29:03 -0500
Received: from xmb-aln-x02.cisco.com ([169.254.5.3]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0248.002; Mon, 3 Aug 2015 09:29:03 -0500
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
Thread-Topic: [Rtg-yang-coord] yang models intended for the mpls wg
Thread-Index: AQHQxfSyflZZhSJIkkya6GeDKRYTr53q7/2AgAGAFoCAArQdgIAAnziAgAADb4CAAAR0gIAABLwAgAAMGQCACt0/AA==
Date: Mon, 03 Aug 2015 14:29:02 +0000
Message-ID: <7617B608-5F6E-4D68-901D-61B0692B0966@cisco.com>
References: <55B207DD.8060502@pi.nu> <5436B667-6766-4F3D-902E-C4929D4A0240@gmail.com> <55B37EB3.60508@gmail.com> <7347100B5761DC41A166AC17F22DF11221884D17@eusaamb103.ericsson.se> <55B648D9.7060403@gmail.com> <7347100B5761DC41A166AC17F22DF1122188504D@eusaamb103.ericsson.se> <55B64F77.9010308@gmail.com> <7347100B5761DC41A166AC17F22DF112218850B1@eusaamb103.ericsson.se> <55B65D96.9050608@gmail.com>
In-Reply-To: <55B65D96.9050608@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [173.36.7.14]
Content-Type: multipart/signed; boundary="Apple-Mail=_CA382E37-A133-4848-8572-43596A734D4A"; protocol="application/pgp-signature"; micalg="pgp-sha256"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-yang-coord/A2EjCkdX7D4olc05l7tL0Q3x02o>
Cc: "rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, "Ronald P. Bonica" <rbonica@juniper.net>, Gregory Mirsky <gregory.mirsky@ericsson.com>, "bfd-chairs@tools.ietf.org" <bfd-chairs@tools.ietf.org>, Mahesh Jethanandani <mjethanandani@gmail.com>, YANG Doctors <yang-doctors@ietf.org>, "<mpls-chairs@tools.ietf.org>" <mpls-chairs@tools.ietf.org>, Loa Andersson <loa@pi.nu>
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2015 14:29:10 -0000

Thanks Loa for starting a good discussion. Mahesh was asking the right questions, in terms of what are the right abstractions that ought to be modeled, and how to structure the intersection between technology specific (like MPLS), even more specific (like MPLS-TE, MPLS-TP), these abstractions (like Tunnels and OAM), and adjacent technologies.

What follows is the OAM lens for this discussion.

[Responding with a LIME co-chair hat on]

From an OAM perspective, we had a good discussion in LIME in Prague, and I’d like to somewhat summarize some of the decisions and next steps:
LIME is chartered [1] to provide technology and layer independent OAM Models (and OAM here includes ping, mpls lsp ping, bfd, etc)
Success in this context is having these generic model augmented with technology specific from bfd, mpls, etc. I.e., that this abstraction is actually used!

Based on these two points, we have two key deliverables in LIME — these are not our only deliverables, but these are the most relevant for this discussion:
YANG data model(s) for generic layer-independent and technology-independent configuration, reporting and presentation for OAM mechanisms.
Applicability document: The YANG model(s) specified in this working group must be usable and extensible by the existing OAM technologies. This usability and extensibility must be demonstrated, for example with IP Ping, traceroute, BFD, and LSP Ping. Note the technology-specific data model extensions should ideally be worked on in the respective working groups.
There are a few OAM technology-specific models appearing and being worked on, and one of the next steps that LIME will drive is getting all these together, along with the authors of our base model and the applicability document, to rationalize all these OAM efforts.

Specifically, there are these three technology-specific OAM Drafts:
https://tools.ietf.org/html/draft-zhang-mpls-tp-yang-oam-01.txt <https://tools.ietf.org/html/draft-zhang-mpls-tp-yang-oam-01.txt>
https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-01.txt <https://tools.ietf.org/html/draft-zheng-mpls-lsp-ping-yang-cfg-01.txt>
https://tools.ietf.org/html/draft-zheng-bfd-yang <https://tools.ietf.org/html/draft-zheng-bfd-yang>
And these two LIME docs:
Generic model: https://tools.ietf.org/html/draft-tissa-lime-yang-oam-model-05 <https://tools.ietf.org/html/draft-tissa-lime-yang-oam-model-05>
Applicability: https://tools.ietf.org/html/draft-zhuang-lime-yang-oam-model-applicability-00 <https://tools.ietf.org/html/draft-zhuang-lime-yang-oam-model-applicability-00>
We should get the set of authors of these together, perhaps in a structured virtual interim. We can drive these OAM alignment/structuring from LIME. Copying MPLS and BFD co-chairs.

Thanks,

— Carlos.
[1] https://datatracker.ietf.org/wg/lime/charter/ <https://datatracker.ietf.org/wg/lime/charter/>


> On Jul 27, 2015, at 6:34 PM, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
> 
> I do not consider ping to have localization capability. That's why I consider BFD to be the functional equivalent.
> 
> Review is certainly something that LIME will welcome, I'm sure.
> 
> Tom
> 
> On 27/07/2015 11:51 AM, Gregory Mirsky wrote:
>> Hi Tom,
>> I don't think that BFD is or will be used as on-demand OAM tool as it does not have localization capability. Ping or traceroute are more suitable, in my opinion. But if that is how LIME model maps existing OAM tools, then I'd encourage presenting and asking for review of the LIME model by WGs that designed this OAM mechanisms, e.g. MPLS Ping and BFD.
>> 
>> 	Regards,
>> 		Greg
>> 
>> -----Original Message-----
>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]
>> Sent: Monday, July 27, 2015 8:34 AM
>> To: Gregory Mirsky; Mahesh Jethanandani; Loa Andersson
>> Cc: rtg-yang-coord@ietf.org; YANG Doctors
>> Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg
>> 
>> I am not claiming that the capabilities of LSP ping are limited to those of tracert, or that the capabilities of BFD are limited to those of ping. I am saying that if I want to request these two functions (continuity check and hop-by-hop path characterization) at a generic level then the corresponding implementations at the MPLS technology-specific level would be invoked when the LIME RPCs were invoked at the boundaries of an MPLS segment.
>> 
>> The idea would be that once a fault was localized to that segment and to the MPLS layer as opposed to a supporting layer, the manager could invoke the technology-specific models as necessary to get details.
>> 
>> Tom
>> 
>> On 27/07/2015 11:18 AM, Gregory Mirsky wrote:
>>> Hi Tom,
>>> I think I cannot agree with any of your comparisons.
>>> LSP Ping provides both on-demand ping and traceroute functions.
>>> BFD, if you refer to RFC 5880, provides variety of functions, primarily as proactive continuity check (Asynchronous and on-demand modes, as well as ping by Echo mode). RFC 5884 BFD over MPLS LSP consider only Asynchronous mode.
>>> One can argue that ping may be used as proactive continuity check mechanism but that is not what it was originally designed and such application would, most likely, require use of another application, e.g. Measurement Agent per LMAP Reference model.
>>> 
>>> I think it would be really helpful to define relationships between objects of LIME model and models specified in MPLS, BFD and other groups that had developed OAM tools that broadly used in the industry.
>>> 
>>> 	Regards,
>>> 		Greg
>>> 
>>> -----Original Message-----
>>> From: Tom Taylor [mailto:tom.taylor.stds@gmail.com]
>>> Sent: Monday, July 27, 2015 8:06 AM
>>> To: Gregory Mirsky; Mahesh Jethanandani; Loa Andersson
>>> Cc: rtg-yang-coord@ietf.org; YANG Doctors
>>> Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg
>>> 
>>> LSP ping really corresponds to the generic tracert model, in that it provides hop-by-hop path characterization. I can see the LIME tracert RPC being invoked, and the MPLS nodes returning the parameters defined for that RPC to the extent that they correspond to what LSP ping reports.
>>> 
>>> BFD seems to correspond quite nicely to LIME ping in terms of the function performed.
>>> 
>>> Tom
>>> 
>>> On 27/07/2015 1:36 AM, Gregory Mirsky wrote:
>>>> Hi Tom,
>>>> what is relationship between MPLS LSP Ping and "generic ping" models? Or, between BFD and "generic continuity check"?
>>>> 
>>>> 	Regards,
>>>> 		Greg
>>>> 
>>>> -----Original Message-----
>>>> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On
>>>> Behalf Of Tom Taylor
>>>> Sent: Saturday, July 25, 2015 5:19 AM
>>>> To: Mahesh Jethanandani; Loa Andersson
>>>> Cc: rtg-yang-coord@ietf.org; YANG Doctors
>>>> Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg
>>>> 
>>>> The generic ping module is a LIME work item.
>>>> 
>>>> Tom Taylor
>>>> 
>>>> On 24/07/2015 9:24 AM, Mahesh Jethanandani wrote:
>>>>> [with yang doctor hat on]
>>>>> 
>>>>> Loa,
>>>>> 
>>>>> Has there been any discussion around how these models interact with each other or how the mpls WG would like to see the models structured.
>>>>> 
>>>>> For example, from this list of models (and I admit I have not looked at a complete list of mpls related yang models or each in detail), a couple of questions arise.
>>>>> 
>>>>> - Is there a plan for a generic mpls yang model?
>>>>> - plan for a more specific mpls-tp, mpls-te etc. yang model (they could be an extension of the more generic mpls model)?
>>>>> - plan for a generic ping module (may belong in NETMOD WG)?
>>>>> - plan for a mpls ping module (again an extension of the more generic ping module that interfaces with mpls module)?
>>>>> - plan for a ldp module that interfaces with the mpls module?
>>>>> - plan for a rsvp-te module that interfaces with mpls-te module?
>>>>> 
>>>>> Having some structure to the models would probably help these and other yang authors in their design.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Mahesh Jethanandani
>>>>> mjethanandani@gmail.com
>>>>> 
>>>>>> On Jul 24, 2015, at 11:39 AM, Loa Andersson <loa@pi.nu> wrote:
>>>>>> 
>>>>>> Folks,
>>>>>> 
>>>>>> There are four yang models intended for the MPLS working group, we
>>>>>> have not yet started the process of adoption as working group documents.
>>>>>> The four documents are:
>>>>>> 
>>>>>> 1. draft-zhang-mpls-tp-yang-oam (announced earlier) 2.
>>>>>> draft-zheng-mpls-lsp-ping-yang-cfg (announced now) 3.
>>>>>> draft-openconfig-mpls-consolidated-model (announced now) 4.
>>>>>> draft-raza-mpls-ldp-mldp-yang (announced now)
>>>>>> 
>>>>>> /Loa
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> 
>>>>>> Loa Andersson                        email: loa@mail01.huawei.com
>>>>>> Senior MPLS Expert                          loa@pi.nu
>>>>>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Rtg-yang-coord mailing list
>>>>>> Rtg-yang-coord@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>> 
>>>>> _______________________________________________
>>>>> Rtg-yang-coord mailing list
>>>>> Rtg-yang-coord@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> Rtg-yang-coord@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>> 
>>> 
>> 
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord