Re: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-bgp-community-07.txt

[li zhenqiang]

Hello all,

The new version is updated according to the review results from gen-art and 
routing directorate, the follow-up discussion of the review result, and 
valueable comments from Paul Aitken. Thank you all very much.

Since that, more than three weeks, no more comments are raised. So, the WG 
please consider to move it forward. Thanks

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: internet-drafts
Date: 2018-05-12 22:24
To: i-d-annou...@ietf.org
CC: opsawg
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-ipfix-bgp-community-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group 
WG of the IETF.

Title   : Export BGP community information in IP Flow 
Information Export (IPFIX)
Authors : Zhenqiang Li
  Rong Gu
  Jie Dong
Filename: draft-ietf-opsawg-ipfix-bgp-community-07.txt
Pages   : 20
Date: 2018-05-12

Abstract:
   By introducing new Information Elements (IEs), this draft extends the
   existing BGP related IEs to enable IPFIX [RFC7011] to export the BGP
   community information, including the information of BGP standard
   community [RFC1997], BGP extended community [RFC4360], and BGP large
   community [RFC8092].  Network traffic information can then be
   accumulated and analysed at the BGP community granularity, which
   represents the traffic of different kinds of customers, services, or
   geographical regions according to the network operator's BGP
   community planning.  Network traffic information at the BGP community
   granularity is useful for network traffic analysis and engineering.

   To clarify, no new BGP community attribute is defined in this
   document and this document has no purpose to replace BGP Monitoring
   Protocol (BMP) defined in RFC7854.  The IEs introduced in this
   document are used by IPFIX together with other IEs to facilitate the
   IPFIX collector analyzing the network traffic at the BGP community
   granularity without running the heavy BGP protocol.  When needed, the
   mediator or collector can use the IEs introduced in this document to
   report the BGP community related traffic flow information it gets
   either from exporters or through local correlation to other IPFIX
   devices.


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-07
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-ipfix-bgp-community-07

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


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[li zhenqiang]

Dear Joel Halpern,

Thank you very much for your review. Please see my preliminary reply below.

For your first concern, the idea is when the routers obtain the information for 
the already defined BGP related IEs, such as bgpSourceAsNumber, 
bgpDestinationAsNumber, and bgpNextHopIPv4Address, etc, the information for the 
IEs defined in this doc can be obtained at the same time since all the BGP 
related information of a flow is obtained from the matching BGP routing entry 
when the router receives the first packet of the flow. We explain this point in 
the forth paragraph of the Introduction part. Our co-author Jie Dong, who is 
from product vendor Huawei, will explain this in more detail later.

I do NOT think the routers have to change their architectures to report the BGP 
related information for the traffic flow. Supposing the routers have to do 
this, they have already done so when implementing the already defined BGP 
related IEs bgpSourceAsNumber, bgpDestinationAsNumber, and 
bgpNextHopIPv4Address, etc. The first BGP related information element is not 
defined by our draft.

We admit that the correlation could be done at the collectors. But we insist 
that the right place to do the BGP related correlation is the exporters in the 
routers, because the correlation for the BGP related information is very heavy 
for the collectors. To do so, the collectors have to run BGP or BMP which is 
already running in the routers and to do BGP table longest prefix matching 
lookup to find the correct table entry. We explain this point in the 4th and 
5th paragraphs of the Introduction part.

For your second concern, you admit using BGP community attribute to represent 
the geographical regions and different kinds of customers is a legal practice, 
so said in RFC4383 and RFC8195.  Why do you think this is unusual and not 
common? China Mobile uses the standard BGP community to represent the different 
provinces and different kinds of customers in our field network. Swisscom and 
AT&T also said this doc was useful for their network operation in the mail list 
and face to face meeting. Anyway, I will ask for more comments from the 
operators.

For your coclusion, I'm very confused. From where do you say that the draft 
admits that this is not needed? If we think what we want is not needed, why we 
submit this doc. If some words in the doc mislead you, I apologize and will 
polish them.

Thank you again for your review.

Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

From: Joel Halpern
Date: 2018-04-13 22:44
To: rtg-...@ietf.org
CC: 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 i...@ietf.org; opsawg@ietf.org; 
gen-...@ietf.org
Subject: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Reviewer: Joel Halpern
Review result: Not Ready

This is both a gen-art re-review and a routing directorate requested review.

The revisions from draft-04 to -06 show some improvement.  However, I still
have serious problems with this work.

The primary problem is that this seems to violate the designed work
distribution in the IPFIX architecture.  The draft itself notes that the
correlation requested could be done in the collector.  Which is where
correlation is designed to be done.  Instead, it puts a significant new
processing load on the router that is delivering the IPFIX information.  For
example, if one delivers IPFIX from the router data plane, one either has to
modify the router architecture to include additional complex computed
information in the data plane architecture (a bad place to add complexity) or
one has to give up and move all the information through the control plane.  And
even the control plane likely has to add complexity to its RIB logic, as it has
to move additional information from BGP to the common structures.

The secondary problem is that this additional work is justified for the router
by the claim that the unusual usage of applying community tags for geographical
location of customers is a common practice.  It is a legal practice.  And I
presume it is done somewhere or the authors would not be asking for it.   But
it is not common.

In short, since even the draft admits that this is not needed, I recommend
against publishing this document as an RFC.

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg