Re: [IPFIX] [Ie-doctors] Search comments and feedbacks about the draft of IPFIX IE extension when considering BGP community

"lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com> Fri, 29 July 2016 09:56 UTC

Return-Path: <lizhenqiang@chinamobile.com>
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 4FDB612DA5E; Fri, 29 Jul 2016 02:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, T_KAM_HTML_FONT_INVALID=0.01] 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 XZ0hdFSg_XW8; Fri, 29 Jul 2016 02:56:20 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id B9E4012DA4D; Fri, 29 Jul 2016 02:56:18 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app11-12011 (RichMail) with SMTP id 2eeb579b28417fe-5e520; Fri, 29 Jul 2016 17:56:17 +0800 (CST)
X-RM-TRANSID: 2eeb579b28417fe-5e520
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[10.2.52.242]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee1579b283f7b4-247ac; Fri, 29 Jul 2016 17:56:17 +0800 (CST)
X-RM-TRANSID: 2ee1579b283f7b4-247ac
Date: Fri, 29 Jul 2016 17:56:31 +0800
From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
To: "PJ Aitken" <paitken@brocade.com>, "Benoit Claise" <bclaise@cisco.com>, gurong <gurong@chinamobile.com>, "ipfix@ietf.org" <ipfix@ietf.org>, "n.brownlee@auckland.ac.nz" <n.brownlee@auckland.ac.nz>, "quittek@neclab.eu" <quittek@neclab.eu>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
References: <002501d1e1c2$8fb45440$af1cfcc0$@chinamobile.com>, <321dd0a3-986a-6df2-ca29-d414929f36bc@cisco.com>, <2be28848-168f-d52b-3832-d24725c3bf54@brocade.com>, <2016072916103275909729@chinamobile.com>, <df6514b7-fbce-372a-b075-50c311d7090d@brocade.com>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 164[cn]
Mime-Version: 1.0
Message-ID: <2016072917563062392563@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart752015310530_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipfix/cz7T_3Kz-7KNtflp6LL3-MAImzY>
Cc: "ie-doctors@ietf.org" <ie-doctors@ietf.org>, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [IPFIX] [Ie-doctors] 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 <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipfix/>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2016 09:56:23 -0000

Hi P. Aitken,

Yes, you are right. We need two IE IDs for each basicList. But 291 is already there, it is for the IPFIX template IE ID, not 458 or 459.
458 or 459 is for the type of each list element. It goes in the Field ID of the basicList.

bgpSourceCommunityList (458) = basic list(291) of bgp community infromation (defined in RFC1997)  corresponding with source IP address
bgpDestinationCommunityList (459) = basic list(291) of bgp community infromation (defined in RFC1997)  corresponding with destination IP address

Here, basic list meas zero or more bgp communities will be contained in the data set.

Best Regards,


lizhenqiang@chinamobile.com
 
From: Paul Aitken
Date: 2016-07-29 16:30
To: lizhenqiang@chinamobile.com; PJ Aitken; Benoit Claise; gurong; ipfix@ietf.org; n.brownlee@auckland.ac.nz; quittek@neclab.eu; Dongjie (Jimmy)
CC: ie-doctors@ietf.org; Brian Trammell
Subject: Re: [Ie-doctors] [IPFIX] Search comments and feedbacks about the draft of IPFIX IE extension when considering BGP community
Li, two Information Element IDs are required for each basicList:


The first Information Element is the basicList itself. This element ID goes in the IPFIX template "Information Element id" field as usual, per figures G and L of RFC 7011. Effectively this is the outer "container" element.

IDs 458 and 459 define basicList Information Elements, so these are the first (outer, container) elements.


The second Information Element describes the type of each list element. This goes in the basicList Field ID per Figure 1 of RFC 6313. Effectively this is the inner "contained" element.

It's these second (inner, contained) elements which are missing.


Practically, we could have:

    bgpSourceCommunityList (458) = list of bgpSourceAsNumber (16)

or

    bgpSourceCommunityList (458) = list of sourceIPv4Address (8)

or in fact any other Information Element could be used as the "list of ..." element.


In order to ensure this Information Element is interoperable, the missing element ID should be clearly stated in the draft.

P.


On 29/07/2016 09:10, lizhenqiang@chinamobile.com wrote:
Hello P. Aitken and all,

If the suggested IE numbers are assigned by IANA, 458 not 291 SHOULD be encoded in the Field ID field in the basicList for bgpSourceCommunityList, and 459 SHOULD be encoded for bgpDestinationCommunityList.

basicList is an IE type defined in RFC6313. We can use this type to define new IEs if type basicList is applicable.

Sorry for delayed response.

Best Regards,


lizhenqiang@chinamobile.com
 
From: PJ Aitken
Date: 2016-07-20 22:49
To: Benoit Claise; Ariel Gu; ipfix@ietf.org; n.brownlee@auckland.ac.nz; quittek@neclab.eu
CC: lizhenqiang; Brian Trammell; ie-doctors@ietf.org
Subject: Re: [IPFIX] Search comments and feedbacks about the draft of IPFIX IE extension when considering BGP community
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= 



_______________________________________________
ie-doctors mailing list
ie-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/ie-doctors