From nobody Tue May 16 09:19:40 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D27D812EB78 for ; Tue, 16 May 2017 09:19:38 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 FX-DPundQKEz for ; Tue, 16 May 2017 09:19:36 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (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 ADB0A12E055 for ; Tue, 16 May 2017 09:15:08 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4GGEkk2005723; Tue, 16 May 2017 09:15:04 -0700 Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 2adys1u09p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 16 May 2017 09:15:04 -0700 Received: from EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 16 May 2017 10:15:02 -0600 Received: from [172.27.212.154] (172.27.212.154) by EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 16 May 2017 18:14:58 +0200 References: To: "ipfix@ietf.org" , "bclaise@cisco.com" , Srikar B S , Juergen Schoenwaelder , Colin McDowall From: PJ Aitken X-Forwarded-Message-Id: Message-ID: Date: Tue, 16 May 2017 17:14:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.27.212.154] X-ClientProxiedBy: hq1wp-excas12.corp.brocade.com (10.70.38.22) To EMEAWP-EXMB12.corp.brocade.com (172.29.11.86) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-16_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705160126 Archived-At: Subject: [IPFIX] RFC 8038 NOW AVAILABLE X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 16:19:39 -0000 FYI, the MIB variable export RFC has finally been published. Congratulations to the authors, and thanks to everyone who contributed and helped with this draft. P. > From: rfc-editor@rfc-editor.org > Subject: RFC 8038 on Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol > Date: May 2, 2017 at 6:33:09 PM PDT > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org > > A new Request for Comments is now available in online RFC libraries. > > > RFC 8038 > > Title: Exporting MIB Variables Using the > IP Flow Information Export (IPFIX) Protocol > Author: P. Aitken, Ed., > B. Claise, > S. B S, > C. McDowall, > J. Schoenwaelder > Status: Standards Track > Stream: IETF > Date: May 2017 > Mailbox: paitken@brocade.com, > bclaise@cisco.com, > srikarbs@gmail.com, > cmcdowal@brocade.com, > j.schoenwaelder@jacobs-university.de > Pages: 85 > Characters: 188626 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipfix-mib-variable-export-10.txt > > URL: https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_info_rfc8038&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=-WBZuOvcfoy_AZnj8Cq0s2bymqNqZTzuYJe2BDuKDfY&e= > > DOI: 10.17487/RFC8038 > > This document specifies a way to complement IP Flow Information > Export (IPFIX) Data Records with Management Information Base (MIB) > objects, avoiding the need to define new IPFIX Information Elements > for existing MIB objects that are already fully specified. > > Two IPFIX Options Templates, as well as a method for creating IPFIX > Options Templates that are used to export the extra data required to > fully describe Simple Network Management Protocol (SNMP) MIB objects > in IPFIX, are specified herein. > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_standards&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=RFZU2K77IXlsgiUBwYsQt6DyuZWSf6G3Oq1xmNuY-gE&e= ) 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ietf-2Dannounce&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=c9I8mLNQzFZnrkJek-ohvY78DJGhXjruOkphPi1LXv0&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rfc-2Deditor.org_mailman_listinfo_rfc-2Ddist&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=gu9G1wCk1wdVKl_Y3Vigb7E4gTQKdwQoNI1C6aOGI28&e= > > For searching the RFC series, see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_search&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=4Jrdjy13IBOB7VotVGOMRfb4t9JO2r2Rdbc-UBGsEvQ&e= > For downloading RFCs, see https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_retrieve_bulk&d=DwIF-g&c=IL_XqQWOjubgfqINi2jTzg&r=l3qN-NVkUTPhhRxKVpFXRDjrG3WNcj_6aGqXB9E7JYU&m=n1SIVEfTEWaWTVidhCiOeti5waf1KKQfkKY-3lKlJcs&s=gI75yvTOd9NqiSRJtCPg0azWi9bZ1rQqBiiCRxx11Go&e= > > 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 From nobody Sun May 21 23:50:06 2017 Return-Path: X-Original-To: ipfix@ietfa.amsl.com Delivered-To: ipfix@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8521A1286B1; Sun, 21 May 2017 23:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.586 X-Spam-Level: * X-Spam-Status: No, score=1.586 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 IaFe-jw6KY3D; Sun, 21 May 2017 23:49:56 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255086.outbound.protection.outlook.com [40.92.255.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C11612706D; Sun, 21 May 2017 23:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tUrPdiCPMbbY1xMaklXLDntPCcMtM7mG63WZpOg9gA0=; b=KLE+34ho3+YpXlpaEqJUwzIog0XWU6C3BduMFwxUL0Jwsk2X2awqCvFxED4IHnY52WdJBh43RCVFpJnZlzTQn3S4BaDknZhunf0YllYUsY7xCtGQWK/44OG8aNvhx1znzrg3LRLkbLgEksDZRjZOOwo8ByPrlWSpdXP0OWyXWhOGmnjG2Ddy80ozmy73Lgh6KUwPJuzLXii6Nuh1spxqzXjpQR8SJ243IAYiz+dh/G+Zbm9SwPylBbn4UrMbuPoHGjZOZGSJ+GtGw6ewBXeBBeb1zLMzoo1ovvklKU5OWg7Z9E6fZAwYpd9jqDjSBwfnass4/uGzhsbhuS/Q385jVA== Received: from PU1APC01FT018.eop-APC01.prod.protection.outlook.com (10.152.252.55) by PU1APC01HT135.eop-APC01.prod.protection.outlook.com (10.152.252.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1075.5; Mon, 22 May 2017 06:49:52 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com (10.152.252.59) by PU1APC01FT018.mail.protection.outlook.com (10.152.253.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.5 via Frontend Transport; Mon, 22 May 2017 06:49:51 +0000 Received: from HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b]) by HK2PR0601MB1361.apcprd06.prod.outlook.com ([fe80::2115:a445:9d1f:b88b%14]) with mapi id 15.01.1101.019; Mon, 22 May 2017 06:49:51 +0000 From: li zhenqiang To: opsawg , idr , "ipfix@ietf.org" Thread-Topic: discussion about exporting BGP community information in IPFIX Thread-Index: AQHS0sec79+PG+QhZkiBAviflUwRGQ== Date: Mon, 22 May 2017 06:49:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:8047A2B209D0B41D3929C5AD5A78B02155A16A3143AA106D15A6D33A1732F3CE; UpperCasedChecksum:ACEA18884C07D3750BC5AF0C97E0D7AA38D04CEA0A983E399109AA3D7DDCE0D1; SizeAsReceived:8022; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; PU1APC01HT135; 5:Paud577amoEGtc0kWIic3JwYoaPvA/AUVsMUO6QuKAC9GD7EnblYSVpdWFRzOroHsKuhriPhq2kuDDKWh8DDKTF2VmLPqs0IlWz8WpZRxRcc/NvAi4K7/yxj77orKPKDAVv3eEkzWk0fFP9+7FNMrg==; 24:AqyULVUqDjRl+AX5hfCW+Lo0+3c6CD2Q9oQ/PFiE+CEylMyBxWQmfT5u5SBsPuyfLJ3E7qASFcuYQBclVL+gtU/aWydUbC1CBEwAi5M6tyo=; 7:3/J3P5RMKJlI8TbXwHNTlf7Nsw0dLA6YAQ6Joh4RYqS5vIKwfFIkR8Jdj6T+zLTdlJrRQU4phScTNMLX1TQc1syTXL1lEWVO3TnI6yL/JCyq92ulu1p3+06x8eL9LK1iC+AUfyNmm89I6m/CFgoBFjsglNZ0pymu7ZzhEAIGagJatx5uJVjuH+8bz97EMnF34v5BAI7hMXra9+hUl3kj2HuFO1l38OeJxMgBfqCvkYjNLFvjku/O8aJ2mNQBDX95QZOIVjfUsTSykQsIk4j/HYM2xN9ecqGQr72nPVryqE2s3bD7QfLN8LVzWuGJZis9 x-incomingheadercount: 40 x-eopattributedmessage: 0 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:PU1APC01HT135; H:HK2PR0601MB1361.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: db830bac-71df-40c2-3d58-08d4a0debcc3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045); SRVR:PU1APC01HT135; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:PU1APC01HT135; BCL:0; PCL:0; RULEID:; SRVR:PU1APC01HT135; x-forefront-prvs: 03152A99FF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2017 06:49:51.8992 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT135 Archived-At: Subject: [IPFIX] discussion about exporting BGP community information in IPFIX X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 06:49:57 -0000 --_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello experts from OPSAWG, IDR and IPFIX, This mail is to follow up the discussion in the mail lists and face to face= meetings. Since traffic aggregation in BGP community granularity is useful for severa= l applications such as backbone network traffic engineering, https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/ introduces new in= formation elements(IEs) in IPFIX to export the BGP community information of= a specific traffic flow. At present, this draft only defines the IEs for s= tandard community specified in RFC1997. To solve the following two signific= ant questions raised in the previous meetings and mails, I solicit more com= ments and solution alternatives. Question 1: Does one IPFIX message have enough space to fit all the commun= ities related to a specific flow? BGP community, including standard, extended, large and community container,= is a path attribute of BGP distributed in an update message. Since the ma= ximum length of one BGP message is 4096 bytes as per RFC4271 and 64K bytes= for one IPFIX message as per RFC7011, the answer for this question SHOULD = be yes. Howerer, some experts say the specification for BGP message lenth i= n RFC4271 is out of date. Its length is not limited to 4096 bytes. But I d= o not know the new specification. Solution alternatives for this question a= re also welcomed. Question 2: Do we need to cover other kinds of BGP communities, such as ext= ended, large and community container? Based on previous discussion, large community defined in RFC8092 will be co= vered in the next version, since it has the same application purpose as sta= ndard community. Till now, we do not reach consensus about extended communi= ty defined in RFC4360 and community container defined in https://datatracke= r.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/. We usually do not use = the statistical information based on extended community or community contai= ner to do traffic engineering tasks. If you think it is useful to export th= ese two kinds of BGP community informaiton in IPFIX, please show your opini= ons and application use cases. Thank you all very much and best regards, ________________________________ li_zhenqiang@hotmail.com --_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_ Content-Type: text/html; charset="us-ascii" Content-ID: <402CE4E4BB0F8647ACB5BF2E574ABEDD@apcprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hello experts from OPSAWG, IDR and IPFIX,

This mail is to follow up the discussion in the mail lists and face to= face meetings.

Since traffic aggregation in BGP community = ;granularity is useful for several applications&nb= sp;such as backbone network traffic engineering,&n= bsp;https://datatracker.ietf.org/doc/draft-ietf-op= sawg-ipfix-bgp-community/ introduces = ;new information elements(IEs) in IPFIX to export the&= nbsp;BGP community information of a specific = traffic flow. At present, this draft only defines the IEs for standard= community specified in RFC1997. To solve the following two significant que= stions raised in the previous meetings and mails, I solicit more comments and solution alternatives.

Question 1: Does one IPFIX message&n= bsp; have enough space to fit all the&nb= sp;communities related to a specific flow? 
BGP community, including standard, extended, la= rge and community container, is a path  = attribute of BGP distributed in an update&nbs= p;message. Since the maximum length of one BGP message is 40= 96  bytes as per RFC4271 and 64K bytes for=  one IPFIX message as per RFC7011, the answer= for this question SHOULD be yes. Howerer, some experts say the specificati= on for BGP message lenth in RFC4271  is out of date. Its len= gth is not limited to 4096 bytes. But I do not know the new specification. Solution alternatives for this question are al= so welcomed.

Question 2: Do we ne= ed to cover other kinds of BGP communiti= es, such as extended, large and community container?
Based on previous discussion, large community defined in= RFC8092 will be covered in the next version, since it has the same applica= tion purpose as standard community. Till now, we do not reach consensus about extended community defined in RF= C4360 and community container defined in <= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communit= ies/" style=3D"font-size: 10.5pt; line-height: 1.5; background-color: windo= w;">https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/. We usually do not use the statistical information based on extended commun= ity or community container to do traffic engineering tasks. If you think it= is useful to export these two kinds of BGP community informaiton in IPFIX,= please show your opinions and application use cases. 

Thank you all very much and best regards,

li_zhenqiang@hotmail.com
--_000_HK2PR0601MB13617E5EA5828A10E5B3D1A6FCF80HK2PR0601MB1361_--