Re: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt

[li zhenqiang <[e-mail]>]

Hello WG Chairs and all,

I have uploaded a new version with a new section 3 called BGP Community based Traffic Collection, which is a detailed use case to show one of the application scenarios for the introduced IEs. For the encoding example when the IEs are used in the IPFIX protocol, please refer Appendix A. The section 3 in the latest version is used to address the following question 1 and 3.

For question 2, we don't think defining a common container for all the communities (standard, extended, large) have significant advantages. As shown in Appendix A, we have to use different IE in the templete record to tell the exporter which kind of BGP community we are interested in, for example the large community corresponding to the source IP of a specific flow and the standard community corresponding to the destination IP of a specific flow.  What we may use a common container is the element of the basic list in the data set. In this way, the container have to be big enough to accormadate at least the large community, which is 12 octets. When this container is used to export the standard or extended community, we have to pad the oversized bytes. This kind of encoding is feasible but a little bit inefficient. At the same time, considering that the savings on IEs are not obvious, we don't accept this scheme.

You can access the new version by the following link.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp-community-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-bgp-community-04

Any other comments and suggestions are welcomed. Thank you very much.

Best Regards,
zhenqiang Li
________________________________
[e-mail]

From: li zhenqiang<mailto:[e-mail]>
Date: 2017-10-30 17:03
To: Zhoutianran<mailto:[e-mail]>; opsawg<mailto:[e-mail]>; opsawg-chairs<mailto:[e-mail]>
Subject: Re: [OPSAWG] WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt
Hello Tianran and the co-chairs,

Thank you very much for your review and suggestions. I will address all your comments in the next vesion. But I am afraid I can not catch the submittion deadline for the coming meeting. So, the updated version will be uploaded after the Singapore meeting.

Best Regards,
Zhenqiang Li
________________________________
[e-mail]

From: Tianran Zhou<mailto:[e-mail]>
Date: 2017-10-30 16:19
To: li zhenqiang<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; opsawg-chairs<mailto:[e-mail]>
Subject: RE: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt
Hi Zhenqiang and the coauthors,

Based on your latest post, the co-chairs would like to suggest the following improvements before issuing the LC.

1. It’s still not clear why the proposed IEs are necessary and useful, although you have some simple words in the introduction. It’s better to add a separate use case section to expand the two references [Community-TE] and [RFC4384], and to address your operation experience on using them.
This will also help to motivate the audience to understand and use this IE extension.

2. Given that both standard and large communities will stay in deployment and they both accomplish equivalent function, and large can carry all the value spaces of standard ones, one option is to define a container for large with a predefined field for mapping in a standard community value. This is a technique issue that need to be discussed. If you insist your way, please add some texts in the draft to clarify why two were chosen.  Perhaps you have operational experience that explains why the multiple containers help.

3. You have added an operational considerations section as was requested in Prague.  Perhaps a bit more text on the "why" concerning the approach is also required to help inform those who might deploy this.

Thanks,
Ignas, Joe, Tianran


From: li zhenqiang [mailto:[e-mail]]
Sent: Friday, October 20, 2017 3:57 PM
To: [e-mail]; opsawg-chairs
Subject: WGLC request for draft-ietf-opsawg-ipfix-bgp-community-03.txt

Dear WG Chairs and all,

I updated the following draft according to the comments received from the list and the Praha meeting. The purpose to introduce new IEs in IPFIX is explained more clearly in the introducation part and emphesized in the abstract part. We changed one section title from  Message Length Considerations to  Operational Considerations, and explained, at present for the field network, one IPFIX message has enough space to fit all the community information related to a specific traffic flow .

Since no more technical issues remain to be solved, as requested in the Praha meeting, we think this doc is ready to do WGLC. Thank you very much.


Name: draft-ietf-opsawg-ipfix-bgp-community
Revision: 03
Title: Export BGP community information in IP Flow Information Export (IPFIX)
Document date: 2017-10-17
Group: opsawg
Pages: 17
URL: https://www.ietf.org/internet-drafts/draft-ietf-opsawg-ipfix-bgp-community-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/
Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-03
Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp-community-03
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-ipfix-bgp-community-03

Abstract:
   This draft updates RFC7012 IPFIX information model by introducing
   several information elements to enable IPFIX to export the BGP
   community information, including BGP standard community defined in
   RFC1997, BGP extended community defined in RFC4360, and BGP large
   community defined in RFC8092.  Network traffic flow information can
   then be accumulated and analysed at the granularity specified by the
   BGP communities, which is suitable for and needed by some traffic
   optimization applications located in IPFIX collector, SDN controller
   or PCE (Path Computation Element).

________________________________
[e-mail]<mailto:[e-mail]>