Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
I think it worth the authors can discuss about this IPR in the WG before sending the draft to IESG. Tianran Sent from WeLink 发件人： heasley 收件人： li zhenqiang<li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>>;rtg-dir<rtg-...@ietf.org<mailto:rtg-...@ietf.org>>;gen-art<gen-...@ietf.org<mailto:gen-...@ietf.org>>;draft-ietf-opsawg-ipfix-bgp-community.all<draft-ietf-opsawg-ipfix-bgp-community@ietf.org<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>>;ietf<i...@ietf.org<mailto:i...@ietf.org>>;opsawg<opsawg@ietf.org<mailto:opsawg@ietf.org>> 主题： Re: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06 时间： 2018-04-17 23:49:16 Why is there IPR on this draft? Is this because of section 3? A section that is unnecessary and could be entirely removed without affecting the draft in any manner? Otherwise, I think it absolutely absurd that there is IPR on this document. ___ 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
Why is there IPR on this draft? Is this because of section 3? A section that is unnecessary and could be entirely removed without affecting the draft in any manner? Otherwise, I think it absolutely absurd that there is IPR on this document. ___ 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
Sun, Apr 15, 2018 at 12:32:49PM -0400, Joel M. Halpern: > (the authors would not have written it if no one wanted it.) eh, that might not be a valid argument :) > Also, one of the arguments for doing this in the router is that you can > get more timely and precise correlation. Except that for geolocation of > address blocks, upstream correlation seems to be quite sufficiently > stable and precise. NLRI may come and go. I fone has geo-information, > it is unlikely to change. This may have been answered, but in case not or un-clear; what I and I believe others refer to here as geo location, is different from what you and randy are talking about in the sense of the IETF's prefixes. I do not always care about that location. I am placing my own marks on routes - where I hear them; region, country, metro, relationship with the neighbor, etc. Though it is not the whole story, this is typically of more interest to me. If a neighbor AS does similarly and sends them to me, I could make use of them. However, as you observed, these are all choices local to the AS - the values, whether to send them, etc. There is definitely a maintenance cost associate with using this data and a question of accuracy. Other's comments about accuracy and burden of external enrichment are valid. Whether this particular additional resolution is much of a burden on routers, I suspect not, but I am not an implementer. Authors: please use a spell checker. Also seems a few of the reference links are broken. ___ 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
> iff i can select which community's or communities' values form the sampling > bucket(s), this seems reasonable. if i am community transparent, i probably > don't want a bucket for each community on my inbound set. Yes, this sounds better. It can be achieved by configuring the intermediate process as in RFC6183. This could be a more reasonable use case for the new IE. Tianran ___ 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
> As far as I can see, this document proposed a new aggregation > parameter for IPFIX. So that the operators can get the traffic > statistic from a new dimension. > > Because "Flow information based on IP address or IP prefix may provide > much too fine granularity for a large network. On the contrary, flow > information based on AS number may be too coarse." > > It sounds reasonable. iff i can select which community's or communities' values form the sampling bucket(s), this seems reasonable. if i am community transparent, i probably don't want a bucket for each community on my inbound set. randy ___ 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
Hi Joel, Thanks a lot for your review comments. Regarding your first problem, I don't think this draft introduces "significant new processing load on the router", as similar processing has already been done for the BGP AS number and BGP-nexthop based traffic collection. As described in the draft, the BGP-community based traffic collection is done by BGP lookup and correlating the BGP community with the flow data to be exported. Whether it is done in data plane or control plane is implementation specific and IMO does not belong to a IETF document. As for your second problem, as many operators have pointed out, it is a common case to use BGP communities to represent geo locations at various granularities. So we need to provide them the tools to meet their requirements. Standardizing the IEs for BGP community is a good start. Best regards, Jie > -Original Message- > From: Joel Halpern [mailto:j...@joelhalpern.com] > Sent: Friday, April 13, 2018 10:44 PM > 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
Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Hi Joel, > From what I can tell reading this, the value requires significantly more > precision than "region". As far as I can see, this document proposed a new aggregation parameter for IPFIX. So that the operators can get the traffic statistic from a new dimension. Because "Flow information based on IP address or IP prefix may provide much too fine granularity for a large network. On the contrary, flow information based on AS number may be too coarse." It sounds reasonable. Tianran > -Original Message- > From: Joel M. Halpern [mailto:j...@stevecrocker.com] > Sent: Monday, April 16, 2018 12:33 AM > To: heasley <h...@shrubbery.net>; li zhenqiang <li_zhenqi...@hotmail.com> > Cc: rtg-...@ietf.org; gen-...@ietf.org; > draft-ietf-opsawg-ipfix-bgp-community@ietf.org; i...@ietf.org; opsawg > <opsawg@ietf.org> > Subject: Re: Rtgdir early review of > draft-ietf-opsawg-ipfix-bgp-community-06 > > Thank you for that pointer. It is informative. > I looked at a number of the entries (trying to pick larger ISPs as more likely > to need more information.) What i see is some ISPs doing what Randy Bush > mentioned, marking regions. I see a few ISPs that explicitly mark country > (or in one case city). I see some that mix several pieces of information > including country in the same community, making it hard to perform what this > I-D calls for (not impossible, just harder). I do not see any indication > of wide-spread consistency. > > It appears that this is of use to a few ISPs. I have never argued that no > one wants this (the authors would not have written it if no one wanted it.) > > From what I can tell reading this, the value requires significantly more > precision than "region". > > Also, one of the arguments for doing this in the router is that you can get > more timely and precise correlation. Except that for geolocation of address > blocks, upstream correlation seems to be quite sufficiently stable and > precise. NLRI may come and go. I fone has geo-information, it is unlikely > to change. > > Yours, > Joel > > > On 4/15/18 12:09 PM, heasley wrote: > > Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang: > >> Why do you think this is unusual and not common? > > > > Possibly, with due respect, because he is not an operator? While ASes > > often do so internally, not all reveal it externally or not > > ubiquitously. Browse https://onestep.net/communities/ to find the geo > tag values of various ASes. > > ___ 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
> I fone has geo-information, it is unlikely to change. i guess you have never noticed when you are at ietf praha and your phone says you are in seoul or whatever. it takes non-trivial ops pain to get ietf attendees geoloc to work; and sometimes we can't. when you find yourself in a hole, first thing is to stop digging. ___ 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
> I do not see any indication of wide-spread consistency. the point is that there is widespread use. the page heas pointed out is what is documented by large ops, the tip of the iceberg. how about stop speaking for operators? randy ___ 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
Thank you for that pointer. It is informative. I looked at a number of the entries (trying to pick larger ISPs as more likely to need more information.) What i see is some ISPs doing what Randy Bush mentioned, marking regions. I see a few ISPs that explicitly mark country (or in one case city). I see some that mix several pieces of information including country in the same community, making it hard to perform what this I-D calls for (not impossible, just harder). I do not see any indication of wide-spread consistency. It appears that this is of use to a few ISPs. I have never argued that no one wants this (the authors would not have written it if no one wanted it.) From what I can tell reading this, the value requires significantly more precision than "region". Also, one of the arguments for doing this in the router is that you can get more timely and precise correlation. Except that for geolocation of address blocks, upstream correlation seems to be quite sufficiently stable and precise. NLRI may come and go. I fone has geo-information, it is unlikely to change. Yours, Joel On 4/15/18 12:09 PM, heasley wrote: Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang: Why do you think this is unusual and not common? Possibly, with due respect, because he is not an operator? While ASes often do so internally, not all reveal it externally or not ubiquitously. Browse https://onestep.net/communities/ to find the geo tag values of various ASes. ___ 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
Sun, Apr 15, 2018 at 02:52:43PM +, li zhenqiang: > Why do you think this is unusual and not common? Possibly, with due respect, because he is not an operator? While ASes often do so internally, not all reveal it externally or not ubiquitously. Browse https://onestep.net/communities/ to find the geo tag values of various ASes. ___ 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
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 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<mailto:j...@joelhalpern.com> Date: 2018-04-13 22:44 To: rtg-...@ietf.org<mailto:rtg-...@ietf.org> CC: draft-ietf-opsawg-ipfix-bgp-community@ietf.org<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org>; gen-...@ietf.org<mailto: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
Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
hi joel, > 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. actually, it is used. not in the "this prefix originted in new hampshire," sense, but for global isps, to tag the routing region of origin, e.g. se asia, europe, noam, ... randy ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] 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
