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 10FE912D85A; Wed, 20 Jul 2016 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 z3bVwCp2XSaA; Wed, 20 Jul 2016 07:49:28 -0700 (PDT) Received: from mx0b-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 99B4212D7D4; Wed, 20 Jul 2016 07:49:28 -0700 (PDT) Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by m0000700.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u6KEmDVN024373; Wed, 20 Jul 2016 07:49:17 -0700 Received: from brmwp-exmb12.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 2493fb8h7a-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 20 Jul 2016 07:49:17 -0700 Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB12.corp.brocade.com (172.16.59.130) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 20 Jul 2016 08:49:16 -0600 Received: from [10.252.48.4] (10.252.48.4) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 20 Jul 2016 16:49:11 +0200 From: PJ Aitken To: Benoit Claise , Ariel Gu , , , References: <002501d1e1c2$8fb45440$af1cfcc0$@chinamobile.com> <321dd0a3-986a-6df2-ca29-d414929f36bc@cisco.com> Message-ID: <2be28848-168f-d52b-3832-d24725c3bf54@brocade.com> Date: Wed, 20 Jul 2016 15:49:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <321dd0a3-986a-6df2-ca29-d414929f36bc@cisco.com> Content-Type: multipart/alternative; boundary="------------84B4FD6F1AE96AB2BABB0262" X-Originating-IP: [10.252.48.4] X-ClientProxiedBy: hq1wp-excas12.corp.brocade.com (10.70.38.22) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200159 Archived-At: Cc: "ie-doctors@ietf.org" , lizhenqiang , Brian Trammell Subject: Re: [IPFIX] Search comments and feedbacks about the draft of IPFIX IE extension when considering BGP community X-BeenThere: ipfix@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IPFIX WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 14:49:33 -0000 --------------84B4FD6F1AE96AB2BABB0262 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit When a draft specifies one of the list types, should it also specify the type of the list elements and the expected semantics? Else we could have non-interoperable implementations exporting the same "IANA standard" information element, where one is a "basicList of X" while another is a "basicList of Y". ie, although the IE is the same, the basicList Field ID and semantics are different. See RFC 6313, Figure 1.) eg, the BGP community draft referenced below creates a new bgpSourceCommunityList. I suppose this may be a list of bgpSourceAsNumber, but that's not specified in the draft - so it could equally be a list of sourceIPv4Address or any other IE. Alternatively, devices could simply export IE #291 (basicList), with the bgpSourceCommunityList and bgpDestinationCommunityList disambiguated by the basicList Field ID contained in the basicList header. However that would be horrendous for collectors... P. On 20/07/16 08:12, Benoit Claise wrote: > Dear all, > > We know that the IANA considerations > > mentions "expert review" for the IPFIX registry > . > This BGP community is actually a special IPFIX Information Element as > this is the first one based on RFC 6313 > (basicList, > subTemplateList, subTemplateMultiList) > So it deserves special attention, review, and potential documentation > as its own RFC. > > Regards, Benoit > >> Hi, dear all. >> >> Nice meeting you in the mail-list of IPFIX. This IETF in Berlin right >> now, we submit a draft and present it about the IPFIX IE extension >> when considering BGP community. I’m looking for comments and >> feedbacks about our idea in new IE added in exporting the flow >> information correlated with BGP community. As dear chair told me that >> the mail-list is still alive, I follow the suggestion of putting my >> draft here and searching for advice and suggestions in the right place. >> >> Before that, I made a short summary of my draft which may be helpful >> in quick looking at the draft. When we consider traffic steering in >> our backbone network, we feel that the flow information based on BGP >> community is quite suitable. That’s the reason why we write the >> draft. And we now recommend two IEs which may be assigned by IANA: >> bgpSourceCommunityList and bgpDestinationCommunityList. >> >> If you are facing up with this situations as us, then we can discuss >> about the IEs especially the details. >> >> The information of my draft: >> https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-00.txt >> >> >> I’m looking forward for your comments. >> >> Best regards and have a nice trip in Berlin. >> >> ----------------------------------------------------------- >> >> Rong Gu >> China Mobile Research Institute >> No.32 Xuanwumen West Street, Xicheng District >> Beijing, China, 100053 >> Mobile: +86 13811520541 >> Phone: +86 10 15801696688 Ext. 36211 >> Email: gurong@chinamobile.com >> > > > > _______________________________________________ > IPFIX mailing list > IPFIX@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=ZslthyAR_pCMk0ceVDm68IQNaZBed3zfEKAlZ4zaux4&s=mL0br6tuMk78xRPYaHEPxZ5usdrXvvMI1C_g105zdws&e= --------------84B4FD6F1AE96AB2BABB0262 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit When a draft specifies one of the list types, should it also specify the type of the list elements and the expected semantics?

Else we could have non-interoperable implementations exporting the same "IANA standard" information element, where one is a "basicList of X" while another is a "basicList of Y".
ie, although the IE is the same, the basicList Field ID and semantics are different. See RFC 6313, Figure 1.)

eg, the BGP community draft referenced below creates a new bgpSourceCommunityList. I suppose this may be a list of bgpSourceAsNumber, but that's not specified in the draft - so it could equally be a list of sourceIPv4Address or any other IE.

Alternatively, devices could simply export IE #291 (basicList), with the bgpSourceCommunityList and bgpDestinationCommunityList disambiguated by the basicList Field ID contained in the basicList header. However that would be horrendous for collectors...

P.


On 20/07/16 08:12, Benoit Claise wrote:
Dear all,

We know that the IANA considerations mentions "expert review" for the IPFIX registry.
This BGP community is actually a special IPFIX Information Element as this is the first one based on RFC 6313  (basicList, subTemplateList, subTemplateMultiList)
So it deserves special attention, review, and potential documentation as its own RFC.

Regards, Benoit
 

Hi, dear all.

Nice meeting you in the mail-list of IPFIX. This IETF in Berlin right now, we submit a draft and present it about the IPFIX IE extension when considering BGP community. I’m looking for comments and feedbacks about our idea in new IE added in exporting the flow information correlated with BGP community. As dear chair told me that the mail-list is still alive, I follow the suggestion of putting my draft here and searching for advice and suggestions in the right place.

 

Before that, I made a short summary of my draft which may be helpful in quick looking at the draft. When we consider traffic steering in our backbone network, we feel that the flow information based on BGP community is quite suitable. That’s the reason why we write the draft. And we now recommend two IEs which may be assigned by IANA: bgpSourceCommunityList and bgpDestinationCommunityList.

 

If you are facing up with this situations as us, then we can discuss about the IEs especially the details.

 

The information of my draft: https://www.ietf.org/internet-drafts/draft-li-opsawg-ipfix-bgp-community-00.txt

 

I’m looking forward for your comments.

Best regards and have a nice trip in Berlin.

-----------------------------------------------------------

Rong Gu
China Mobile Research Institute
No.32 Xuanwumen West Street, Xicheng District
Beijing, China, 100053
Mobile: +86 13811520541
Phone: +86 10 15801696688 Ext. 36211
Email: gurong@chinamobile.com

 

 




_______________________________________________
IPFIX mailing list
IPFIX@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipfix&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=Xx9729xYDYoCgBDdcp1FKt5PyYd1TCoXNKhyPY8CFp8&m=ZslthyAR_pCMk0ceVDm68IQNaZBed3zfEKAlZ4zaux4&s=mL0br6tuMk78xRPYaHEPxZ5usdrXvvMI1C_g105zdws&e=

--------------84B4FD6F1AE96AB2BABB0262--