Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
Hi Zhenqiang and the coauthors, First of all I have to congratulate to this draft. I share the opinion that BGP communities are a very powerful information element. Correlated to the forwarding plane it gives a more detailed and granular view of the network usage then AS numbers or paths. Looking from a MPLS VPN network provider perspective, which currently doing flow aggregation at the collector with BGP VPNv4/6 peerings to MPLS PE routers and encode inventory data into BGP communities, I have to agree with Paolo's opinion that this draft might not go far enough. Looking just at the forwarding plane. We welcome the support of BGP standard and extended communities. To be useable for us, we would also need BGP route-distinguishers (IPFIX entity 90) and prefix/prefix length to be covered to be applicable in a MPLS VPN network. I agree with Jeffrey that the correlation from BGP local RIB to the RIB on the router is more accurate (lag, BGP local RIB vs. RIB), compared to the correlation between BGP local rib and IPFIX on a collector. Looking at the big picture, IPFIX is just covering the forwarding plane. It is just a part of the puzzle to extract metrics from a router. The forwarding plane alone isn't enough to understand why the forwarding behavior changed in a network. BMP is covering well the routing control-plane, especially if BGP local RIB and adjacent RIB out will be covered. Streaming telemetry with yang config model covering the physical topology. From our point of view, where we want forwarding, control-plane and physical topology covered, I disagree that the BGP/BMP peering could be replaced by this draft. It will remain to cover the historical aspects of the BGP control-plane. It could be replaced if we only would care about the forwarding plane (for accounting as an example) though. Kind regards Thomas Graf Network Engineer Tribe IT Clouds Telefon +41-58-223 84 01 Mobile +41-79-728 80 12 thomas.g...@swisscom.com<mailto:thomas.g...@swisscom.com> Swisscom (Schweiz) AG IT, Network & Infrastructure Tribe IT Clouds Binzring 17 8045 Zürich www.swisscom.com Postadresse: Binzring 17 8045 Zürich From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of li zhenqiang Sent: Tuesday, February 27, 2018 5:06 PM To: Jeffrey Haas ; Paolo Lucente Cc: grow ; Zhoutianran ; draft-ietf-opsawg-ipfix-bgp-community@ietf.org; opsawg Subject: Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community Hi Jeffrey Haas and Paolo Lucente, Thank you very much for your comments and opinions. Sorry for the late response due to Chinese new year holiday. For the first concern of Paolo, at present I have no need to know the full as path related to a traffic flow. What I want to collect is the communities related to a traffic flow, which represent the the geographical and topological related information in finer granularity than the ASes. When the working group called adoption of this doc, IPFIX doctor, PJ Aitken's opinion answered your second concern. He said " Per section 6 of RFC7012, new IPFIX Information Elements can be added by direct application to IANA; there's no need for a draft or RFC. However, the introduction and examples may be valuable, especially for BGP experts who are less familiar with IPFIX. I've no objection to adopting the draft." And I totally agree with Mr. Jeffrey Haas, running BGP is not trivial for all the IPFIX collectors. BGP is heavy and it runs well in the exporters, i.e. routers. If the collector can get the needed BGP information, it can do statistics and analysis directly. Best Regards, Zhenqiang Li from China Mobile Research Institute li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com> From: Jeffrey Haas<mailto:jh...@pfrc.org> Date: 2018-02-22 01:52 To: Paolo Lucente<mailto:pa...@ntt.net> CC: Tianran Zhou<mailto:zhoutian...@huawei.com>; grow@ietf.org<mailto:grow@ietf.org>; draft-ietf-opsawg-ipfix-bgp-community@ietf.org<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>; opsawg<mailto:ops...@ietf.org> Subject: Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community Paolo, I don't speak for the authors here, just my opinion. On Wed, Feb 21, 2018 at 05:37:59PM +0100, Paolo Lucente wrote: > One concern is that this looks a very isolated effort, ie. why communities > and not as-path? I remember the story of this draft, it comes from field > needs and that is in short the answer to the cherry-picking. Partly, the usual information that people want from flow for AS information (origin or peer AS) is already available. The full path, no. One certainly could make the argument that the full path could be sent. Since flow analyzers mos
Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
Hi Jeffrey Haas and Paolo Lucente, Thank you very much for your comments and opinions. Sorry for the late response due to Chinese new year holiday. For the first concern of Paolo, at present I have no need to know the full as path related to a traffic flow. What I want to collect is the communities related to a traffic flow, which represent the the geographical and topological related information in finer granularity than the ASes. When the working group called adoption of this doc, IPFIX doctor, PJ Aitken's opinion answered your second concern. He said " Per section 6 of RFC7012, new IPFIX Information Elements can be added by direct application to IANA; there's no need for a draft or RFC. However, the introduction and examples may be valuable, especially for BGP experts who are less familiar with IPFIX. I've no objection to adopting the draft." And I totally agree with Mr. Jeffrey Haas, running BGP is not trivial for all the IPFIX collectors. BGP is heavy and it runs well in the exporters, i.e. routers. If the collector can get the needed BGP information, it can do statistics and analysis directly. Best Regards, Zhenqiang Li from China Mobile Research Institute li_zhenqi...@hotmail.com From: Jeffrey Haas<mailto:jh...@pfrc.org> Date: 2018-02-22 01:52 To: Paolo Lucente<mailto:pa...@ntt.net> CC: Tianran Zhou<mailto:zhoutian...@huawei.com>; grow@ietf.org<mailto:grow@ietf.org>; draft-ietf-opsawg-ipfix-bgp-community@ietf.org<mailto:draft-ietf-opsawg-ipfix-bgp-community@ietf.org>; opsawg<mailto:ops...@ietf.org> Subject: Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community Paolo, I don't speak for the authors here, just my opinion. On Wed, Feb 21, 2018 at 05:37:59PM +0100, Paolo Lucente wrote: > One concern is that this looks a very isolated effort, ie. why communities > and not as-path? I remember the story of this draft, it comes from field > needs and that is in short the answer to the cherry-picking. Partly, the usual information that people want from flow for AS information (origin or peer AS) is already available. The full path, no. One certainly could make the argument that the full path could be sent. Since flow analyzers mostly want the active route's properties, having the communities to go along with it is helpful. > The second concern, the one going the opposite direction than the previous > one, is that in future it could be tempting for somebody to repeat the > story of this draft and add support for as-paths and/or other BGP > attributes in IPFIX: here i see a mix-up among the original intent to > report on data plane information with the reporting on control-plane (BGP) > information: in other words, is (potentially) encapsulating (all) BGP > attributes for every sampled packet/flow a valid idea? For example, is not > BGP/BMP peering at the IPFIX collector itself much more efficient instead > of moving control-plane info over and over again? At this propo, the > motivation that roughly 20 years ago it was decided to make source and > destination ASNs part of NetFlow v5 (and few years later BGP next-hop was > added as part of NetFlow v9) is a bit weak, IMO; maybe there is more to > it, and i’d be happy to hear about it. Analyzers still find it handy to have source and destination AS. This in some cases avoids lag issues due to propagation of sniffed BGP (via iBGP peering or BMP) for the sampling router. Additionally, a lot of useful data can be gathered without having BGP at all at the analyzer. I do understand the concern, but personally find it unlikely that this is the feared "slippery slope". [1] -- Jeff [1] https://en.wikipedia.org/wiki/Slippery_slope ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
Paolo, I don't speak for the authors here, just my opinion. On Wed, Feb 21, 2018 at 05:37:59PM +0100, Paolo Lucente wrote: > One concern is that this looks a very isolated effort, ie. why communities > and not as-path? I remember the story of this draft, it comes from field > needs and that is in short the answer to the cherry-picking. Partly, the usual information that people want from flow for AS information (origin or peer AS) is already available. The full path, no. One certainly could make the argument that the full path could be sent. Since flow analyzers mostly want the active route's properties, having the communities to go along with it is helpful. > The second concern, the one going the opposite direction than the previous > one, is that in future it could be tempting for somebody to repeat the > story of this draft and add support for as-paths and/or other BGP > attributes in IPFIX: here i see a mix-up among the original intent to > report on data plane information with the reporting on control-plane (BGP) > information: in other words, is (potentially) encapsulating (all) BGP > attributes for every sampled packet/flow a valid idea? For example, is not > BGP/BMP peering at the IPFIX collector itself much more efficient instead > of moving control-plane info over and over again? At this propo, the > motivation that roughly 20 years ago it was decided to make source and > destination ASNs part of NetFlow v5 (and few years later BGP next-hop was > added as part of NetFlow v9) is a bit weak, IMO; maybe there is more to > it, and i’d be happy to hear about it. Analyzers still find it handy to have source and destination AS. This in some cases avoids lag issues due to propagation of sniffed BGP (via iBGP peering or BMP) for the sampling router. Additionally, a lot of useful data can be gathered without having BGP at all at the analyzer. I do understand the concern, but personally find it unlikely that this is the feared "slippery slope". [1] -- Jeff [1] https://en.wikipedia.org/wiki/Slippery_slope ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community
Hi, With the hat of the developer of a open-source / free IPFIX collector (*, **), I would like to express two opposite concerns with regards to this draft - loosely related to the very details of the draft itself. One concern is that this looks a very isolated effort, ie. why communities and not as-path? I remember the story of this draft, it comes from field needs and that is in short the answer to the cherry-picking. The second concern, the one going the opposite direction than the previous one, is that in future it could be tempting for somebody to repeat the story of this draft and add support for as-paths and/or other BGP attributes in IPFIX: here i see a mix-up among the original intent to report on data plane information with the reporting on control-plane (BGP) information: in other words, is (potentially) encapsulating (all) BGP attributes for every sampled packet/flow a valid idea? For example, is not BGP/BMP peering at the IPFIX collector itself much more efficient instead of moving control-plane info over and over again? At this propo, the motivation that roughly 20 years ago it was decided to make source and destination ASNs part of NetFlow v5 (and few years later BGP next-hop was added as part of NetFlow v9) is a bit weak, IMO; maybe there is more to it, and i’d be happy to hear about it. On the details of the draft itself instead, i reckon the effort to support Extended and Large communities (comment from Ignas Bagdonas last year); i also followed the discussion with PJ Aitken about segmentation/fragmentation of potentially long communities list and i seem to reckon there is no good (simple, straightforward) solution to address that. Paolo (*) http://www.pmacct.net/ (**) https://github.com/pmacct/pmacct > On 23 Jan 2018, at 02:10, Tianran Zhou wrote: > > Dear GROW WG, > > The OPSAWG started a 2 week WG LC for a BGP related draft: > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 > > It would be really helpful and appreciated if you can read it. > Could you please provide comments (if any) and copy to ops...@ietf.org? > > Cheers, > Tianran, as OPSAWG co-chair > > > -Original Message- > From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou > Sent: Thursday, January 18, 2018 11:07 AM > To: ops...@ietf.org > Cc: opsawg-cha...@ietf.org > Subject: [OPSAWG] WG LC for draft-ietf-opsawg-ipfix-bgp-community > > Hi WG, > > The authors of draft-ietf-opsawg-ipfix-bgp-community have posted the latest > drafts to the mailing list, and believe that the document is ready for LC. > > This starts a 2 week WG LC on > https://tools.ietf.org/html/draft-ietf-opsawg-ipfix-bgp-community-04 > > Please read the above draft and send any issues, comments, or corrections to > this mailing list. > All supports and concerns are welcome and helpful for the authors. > > We are also looking for a document shepherd, best with operator background, > to help the following procedures. > > The WG LC will close on Feb 1, 2018. > Authors please indicate whether you are aware of any IPR for the draft. > > Thanks, > Tianran, as OPSAWG co-chair > > ___ > OPSAWG mailing list > ops...@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
