From nobody Mon Aug 3 07:29:11 2015 Return-Path: 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)" To: Tom Taylor Thread-Topic: [Rtg-yang-coord] yang models intended for the mpls wg Thread-Index: AQHQxfSyflZZhSJIkkya6GeDKRYTr53q7/2AgAGAFoCAArQdgIAAnziAgAADb4CAAAR0gIAABLwAgAAMGQCACt0/AA== Date: Mon, 3 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: Cc: "rtg-yang-coord@ietf.org" , "Ronald P. Bonica" , Gregory Mirsky , "bfd-chairs@tools.ietf.org" , Mahesh Jethanandani , YANG Doctors , "" , Loa Andersson 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 14:29:10 -0000 --Apple-Mail=_CA382E37-A133-4848-8572-43596A734D4A Content-Type: multipart/alternative; boundary="Apple-Mail=_F3E43B5C-10C9-4CBB-AF3C-42256F7B3647" --Apple-Mail=_F3E43B5C-10C9-4CBB-AF3C-42256F7B3647 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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] =46rom an OAM perspective, we had a good discussion in LIME in Prague, = and I=E2=80=99d 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 =E2=80=94 = 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-zheng-mpls-lsp-ping-yang-cfg-01.txt = 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 = Applicability: = 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, =E2=80=94 Carlos. [1] https://datatracker.ietf.org/wg/lime/charter/ = > On Jul 27, 2015, at 6:34 PM, Tom Taylor = wrote: >=20 > I do not consider ping to have localization capability. That's why I = consider BFD to be the functional equivalent. >=20 > Review is certainly something that LIME will welcome, I'm sure. >=20 > Tom >=20 > 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. >>=20 >> Regards, >> Greg >>=20 >> -----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 >>=20 >> 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. >>=20 >> 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. >>=20 >> Tom >>=20 >> 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. >>>=20 >>> 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. >>>=20 >>> Regards, >>> Greg >>>=20 >>> -----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 >>>=20 >>> 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. >>>=20 >>> BFD seems to correspond quite nicely to LIME ping in terms of the = function performed. >>>=20 >>> Tom >>>=20 >>> 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"? >>>>=20 >>>> Regards, >>>> Greg >>>>=20 >>>> -----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 >>>>=20 >>>> The generic ping module is a LIME work item. >>>>=20 >>>> Tom Taylor >>>>=20 >>>> On 24/07/2015 9:24 AM, Mahesh Jethanandani wrote: >>>>> [with yang doctor hat on] >>>>>=20 >>>>> Loa, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> - 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? >>>>>=20 >>>>> Having some structure to the models would probably help these and = other yang authors in their design. >>>>>=20 >>>>> Thanks. >>>>>=20 >>>>> Mahesh Jethanandani >>>>> mjethanandani@gmail.com >>>>>=20 >>>>>> On Jul 24, 2015, at 11:39 AM, Loa Andersson wrote: >>>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> /Loa >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>>=20 >>>>>> Loa Andersson email: loa@mail01.huawei.com >>>>>> Senior MPLS Expert loa@pi.nu >>>>>> Huawei Technologies (consultant) phone: +46 739 81 21 64 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Rtg-yang-coord mailing list >>>>>> Rtg-yang-coord@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>=20 >>>>> _______________________________________________ >>>>> Rtg-yang-coord mailing list >>>>> Rtg-yang-coord@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Rtg-yang-coord mailing list >>>> Rtg-yang-coord@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord --Apple-Mail=_F3E43B5C-10C9-4CBB-AF3C-42256F7B3647 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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]

=46rom an OAM perspective, we had a good discussion in LIME = in Prague, and I=E2=80=99d 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 =E2=80=94 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:
<= /div>
And these two LIME docs:
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,

=E2=80=94 Carlos.
[1] 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 =             &n= bsp;          email: = loa@mail01.huawei.com
Senior MPLS Expert =             &n= bsp;           &nbs= p;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

= --Apple-Mail=_F3E43B5C-10C9-4CBB-AF3C-42256F7B3647-- --Apple-Mail=_CA382E37-A133-4848-8572-43596A734D4A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVv3qqAAoJEIXgpQGOZny9074P/0YJGpT8sB55PJu9UJkM6oky 4wmgXVojoIDJ0uW15MIez2M3psFSq8R2iFYmp+gGGiN7ypioAH3932oVYsWmseLX lpKSsFn/TeZVVnsAnYmM1ZuZIHQjCzuJzDanY7rfIl/oYgK/aW+CDvG0M4vf5Xom cHHjjujO8qT01TDRiQNVshpk++qqkcgRDumFDWatFmtEhUN0EMqPhzLlftV73y7d hRtAwS/Q5zGb4397MhPouOI3u/TfDGJF2/Qljge7grJEiV/9Qtq7b2n4suYc4142 hyLVXzNd5fPyOpWAmZdY7Ia1ghllu9av6RS3t5R9sDDAT9J1uoQHabMKicnwsd2S HHCSgERqv8VYVKQGRA19uxoNc4Yss4NVjUWgq01qylv2uDYJk1Kh2zp4tUAjQrfr lUW5UvUZdTO05IUs1gUgv2JbUL7+lC9fMs++qcd0v25zDlaMIypU6TlwOpqa+4sA LyUk58tvYJQ8Z99YYvftFM7PNDQPbaPwJjp9/nr40U0GU5AaJkebz15MUxrLO2FI a+Y1ygagAr8TrgLo1dFTk/302ahELfFE6actbfKWhbH5kMqmOXEXzts0sRioDt+I xnUguQNwDjhpX5koTng42V+GXFnZVPF1Zgm8BG9FbPKd0pKm7CFdh66lf8zaD6Yf j3aX+bWRmjszHP8VoNwu =xdrd -----END PGP SIGNATURE----- --Apple-Mail=_CA382E37-A133-4848-8572-43596A734D4A-- From nobody Mon Aug 3 15:18:36 2015 Return-Path: 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 1F7F91A00E3; Mon, 3 Aug 2015 15:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 0li8N0DwSbYd; Mon, 3 Aug 2015 15:18:33 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 8DDC31B31CD; Mon, 3 Aug 2015 15:18:32 -0700 (PDT) Received: by pdco4 with SMTP id o4so13479781pdc.3; Mon, 03 Aug 2015 15:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Qr+VBTdZ0vW7tasLg/mBPge/K4Gv7t+eQzSFJuJ+q/w=; b=hOseZ/JvCKY3UttWbKMyIDwiGLkBffwHqSn5GTt1cBIfdnUYBD7oI02wi+eGx0cF9x oVC9K6DdiWEuSPO7ZO5kX5QxtOVM5xRVcZXCjVsTGUBW9v9Guun/Fav5je4svyD+IWQw l8SrT70eylgxTfknhJkp5M7fH67pFQFTFm6NfUL6tFfAM2YnGdNdLQNZJHT4ai8oMbqe 7Q/hD228qOceuPObZwz9hQFuwsetQf2wBARCO1iM6bhjmCznNGktlUuKV5rSBVzNrWnb i/AapEDJuCb7w2eTVuSAacibU/AO8EQ3UWKs6SuXEkWXs97AGwo4hMi8tuOT1y30YU2U 1jTQ== X-Received: by 10.70.129.162 with SMTP id nx2mr516368pdb.167.1438640312250; Mon, 03 Aug 2015 15:18:32 -0700 (PDT) Received: from ?IPv6:2001:420:c0c8:1005::2ba? ([2001:420:c0c8:1005::2ba]) by smtp.gmail.com with ESMTPSA id wp5sm18665941pab.22.2015.08.03.15.18.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Aug 2015 15:18:31 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_ABF6D2BE-AA59-46B8-8C61-1FF39A581BD3" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <7617B608-5F6E-4D68-901D-61B0692B0966@cisco.com> Date: Mon, 3 Aug 2015 15:18:29 -0700 Message-Id: <99E9F585-D99D-41E3-90A9-4E1BFE8E55A8@gmail.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> <7617B608-5F6E-4D68-901D-61B0692B0966@cisco.com> To: "Carlos Pignataro (cpignata)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "rtg-yang-coord@ietf.org" , "Ronald P. Bonica" , Gregory Mirsky , "bfd-chairs@tools.ietf.org" , Tom Taylor , YANG Doctors , "" , Loa Andersson 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 22:18:35 -0000 --Apple-Mail=_ABF6D2BE-AA59-46B8-8C61-1FF39A581BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Carlos, One more OAM model that I would like to add to this list is the MEF = model on CFM. Specifically MEF 38 = . = The model was written 3 years ago and does not align with most of the = models written today. As editor of the YANG project in MEF, I am asking folks if they would be = interested in updating MEF 38 to align it with the current models. Thanks. > On Aug 3, 2015, at 7:29 AM, Carlos Pignataro (cpignata) = wrote: >=20 > 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. >=20 > 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-zheng-mpls-lsp-ping-yang-cfg-01.txt = > 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 = > Applicability: = https://tools.ietf.org/html/draft-zhuang-lime-yang-oam-model-applicability= -00 = =20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_ABF6D2BE-AA59-46B8-8C61-1FF39A581BD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Carlos,

One= more OAM model that I would like to add to this list is the MEF model = on CFM. Specifically MEF 38. The model was written 3 years ago and does not = align with most of the models written today.

As editor of the YANG project in MEF, I = am asking folks if they would be interested in updating MEF 38 to align = it with the current models.

Thanks.


On Aug 3, 2015, at 7:29 AM, Carlos Pignataro (cpignata) = <cpignata@cisco.com> wrote:

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:
<= /div>
And = these two LIME docs:

Mahesh Jethanandani
mjethanandani@gmail.com





= --Apple-Mail=_ABF6D2BE-AA59-46B8-8C61-1FF39A581BD3-- From nobody Fri Aug 21 02:50:45 2015 Return-Path: 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 DE7BC1A1B5D for ; Fri, 21 Aug 2015 02:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pR76ju_jljkT for ; Fri, 21 Aug 2015 02:50:42 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 134771A1B4A for ; Fri, 21 Aug 2015 02:50:42 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id C393C1CC012C; Fri, 21 Aug 2015 11:50:40 +0200 (CEST) From: Ladislav Lhotka To: rtg-yang-coord@ietf.org User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Fri, 21 Aug 2015 11:50:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: jason.sterne@alcatel-lucent.com Subject: [Rtg-yang-coord] [Sterne, Jason (Jason)] routing model - why static routes are ordered-by user ? 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\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 09:50:44 -0000 Hi, Jason asked me (see below) why the list of static routes in ietf-routing is "ordered-by user". I think this was based on the theory that some systems use the order of static routes as the least-priority criterion in route selection. I thought Linux was such a system but now I can't find any evidence that it is really the case. So, if nobody objects, we will remove the "ordered-by user" statement from the list of static routes. This means that the order of static routes in configuration doesn't matter and routers are free to re-arrange them. Thanks, Lada -------------------- Start of forwarded message -------------------- From: "Sterne, Jason (Jason)" To: Ladislav Lhotka Subject: routing model - why static routes are ordered-by user ? Date: Mon, 20 Jul 2015 16:33:13 +0000 Hi Lada, I can post this to the list if you'd prefer (especially if this had some debate and history and isn't just something you put that nobody has commented on) but I'm just curious why the static route list is ordered-by user? Regards, Jason -------------------- End of forwarded message -------------------- -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C