From nobody Sun Jan 6 18:23:15 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92B11292F1; Sun, 6 Jan 2019 18:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Aa1Q5ugUUIyv; Sun, 6 Jan 2019 18:23:11 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E8612872C; Sun, 6 Jan 2019 18:23:11 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E5C366CFA1152A7872E5; Mon, 7 Jan 2019 02:23:08 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 7 Jan 2019 02:23:08 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.185]) by SJCEML701-CHM.china.huawei.com ([169.254.3.117]) with mapi id 14.03.0415.000; Sun, 6 Jan 2019 18:23:03 -0800 From: Linda Dunbar To: "opsawg@ietf.org" , "Charles Eckel (eckelcu)" CC: "draft-sun-opsawg-sdwan-service-model@ietf.org" Thread-Topic: pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN Thread-Index: AdSmLTcugN3+1ZDVSOqR8fQYWNi4aQ== Date: Mon, 7 Jan 2019 02:23:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B22246C@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.73] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B22246Csjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [OPSAWG] pros & cons of draft-sun-opsawg-sdwan-service-model aligning with MEF SD-WAN or ONUG SD-WAN X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 02:23:14 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B22246Csjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I watched the video recording of IETF 103 OPSAwg session over the Christmas= break and want to add some comments (as I missed attending the session in = Bangkok due to conflicts). Both MEF and ONUG have SD-WAN related initiatives. As Charles Eckel stated = in the opsawg IETF 103 session that MEF is more from service provider's per= spective, whereas ONUG is more from single vendor's perspective. ONUG has Path Service model and Reachability service models, the purpose of= the Path Service model is to normalize the service specification, so that = it could be implemented through any vendor's controller (via API support). = Same for Reachability Service. The goal is to be able to configure servic= es within a vendor domain through a single API, with defined service behavi= ors. So the requirements from MEF and ONUG are for different entity, I am not su= re if we can create one service models for both MEF and ONUG. Reading through the draft-sun-opsawg-sdwan-service-model, I feel it is more= from service providers' perspective, i.e. more aligned with MEF. I agree with AD Ignas' saying that we need to define service model per ONUG= user community provided requirement. The problem is that the requirements from ONUG User community are very high= level (e.g. "aggregate paths from N service providers to access hybrid clo= uds"), which can't be directly translated to service model requirements. En= gineers, like IETF community, have to bear the burden to derive the detaile= d executable service model from the high level requirement from User Commun= ity. I think a more realistic method is to bring the IETF service modes to = MEF and ONUG to be validated. Best Regards, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F66B22246Csjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I watched the video recording of IETF 103 OPSAwg ses= sion over the Christmas break and want to add some comments (as I missed at= tending the session in Bangkok due to conflicts).

 

Both MEF and ONUG have SD-WAN related initiatives. A= s Charles Eckel stated in the opsawg IETF 103 session that MEF is more from= service provider’s perspective, whereas ONUG is more from single ven= dor’s perspective.

 

ONUG has Path Service model and Reachability service= models, the purpose of the Path Service model is to normalize the service = specification, so that it could be implemented through any vendor’s c= ontroller (via API support).  Same for Reachability Service.  The goal is to be able to configure services within a vendo= r domain through a single API, with defined service behaviors.

 

So the requirements from MEF and ONUG are for differ= ent entity, I am not sure if we can create one service models for both MEF = and ONUG.

 

Reading through the draft-sun-opsawg-sdwan-service-m= odel, I feel it is more from service providers’ perspective, i.e. mor= e aligned with MEF.

 

I agree with AD Ignas’ saying that we need to = define service model per ONUG user community provided requirement.

The problem is that the requirements from ONUG User = community are very high level (e.g. “aggregate paths from N service p= roviders to access hybrid clouds”), which can’t be directly tra= nslated to service model requirements. Engineers, like IETF community, have to bear the burden to derive the detailed executable = service model from the high level requirement from User Community. I think = a more realistic method is to bring the IETF service modes to MEF and ONUG = to be validated.   

 

Best Regards,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F66B22246Csjceml521mbschi_-- From nobody Tue Jan 15 07:28:44 2019 Return-Path: X-Original-To: opsawg@ietf.org Delivered-To: opsawg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3C130E6B; Tue, 15 Jan 2019 07:28:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.89.3 Auto-Submitted: auto-generated Precedence: bulk Cc: ibagdona@gmail.com, The IESG , opsawg-chairs@ietf.org, Tianran Zhou , draft-ietf-opsawg-ipfix-bgp-community@ietf.org, opsawg@ietf.org, zhoutianran@huawei.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <154756610857.12541.17403543697433880032.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2019 07:28:28 -0800 Archived-At: Subject: [OPSAWG] Protocol Action: 'Export BGP community information in IP Flow Information Export (IPFIX)' to Proposed Standard (draft-ietf-opsawg-ipfix-bgp-community-12.txt) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2019 15:28:29 -0000 The IESG has approved the following document: - 'Export BGP community information in IP Flow Information Export (IPFIX)' (draft-ietf-opsawg-ipfix-bgp-community-12.txt) as Proposed Standard This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ Technical Summary This document defines a set of IPFIX Information Elements used for exporting traffic accounting data based on BGP community information. It is targeted for one large use case of traffic accounting, and it has no intentions to define a universal all-purpose accounting mechanism. The document does not define and does not endorse any specific network design for this functionality, instead it focuses on protocol extensions only. Working Group Summary The document has been discussed for a while, receiving multiple detailed reviews and as a result changing over time quite significantly. There were disagreements in the community on the general applicability of the specified mechanism and as a result the scope of the document is reduces to cover specific use cases only. The resulting document had a broad consensus agreement within the WG. Document Quality There is an indication of a single implementation being available, and some limited deployment experience. The document has received several directorate reviews during the lifecycle, and also several individual in-depth reviews. Personnel Document Shepherd is Tianran Zhou. Responsible Area Director is Ignas Bagdonas. IANA Note The document adds new entries into existing IPFIX IE registries. The document does not create any new IANA registries. From nobody Tue Jan 15 19:41:29 2019 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43FB12F1A2; Tue, 15 Jan 2019 19:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 apfdbFjNWs0D; Tue, 15 Jan 2019 19:41:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5471612F18C; Tue, 15 Jan 2019 19:41:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 74108B81DE9; Tue, 15 Jan 2019 19:41:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, opsawg@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190116034114.74108B81DE9@rfc-editor.org> Date: Tue, 15 Jan 2019 19:41:14 -0800 (PST) Archived-At: Subject: [OPSAWG] =?utf-8?q?RFC_8512_on_A_YANG_Module_for_Network_Address?= =?utf-8?q?_Translation_=28NAT=29_and_Network_Prefix_Translation_=28NPT=29?= X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2019 03:41:20 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8512 Title: A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) Author: M. Boucadair, Ed., S. Sivakumar, C. Jacquenet, S. Vinapamula, Q. Wu Status: Standards Track Stream: IETF Date: January 2019 Mailbox: mohamed.boucadair@orange.com, ssenthil@cisco.com, christian.jacquenet@orange.com, sureshk@juniper.net, bill.wu@huawei.com Pages: 94 Characters: 173551 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-nat-yang-17.txt URL: https://www.rfc-editor.org/info/rfc8512 DOI: 10.17487/RFC8512 This document defines a YANG module for the Network Address Translation (NAT) function. Network Address Translation from IPv4 to IPv4 (NAT44), Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64), customer-side translator (CLAT), Stateless IP/ICMP Translation (SIIT), Explicit Address Mappings (EAM) for SIIT, IPv6-to-IPv6 Network Prefix Translation (NPTv6), and Destination NAT are covered in this document. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC