[GROW] grow - Requested session has been scheduled for IETF 101

["IETF Secretariat"]

Dear Peter Schoenmaker,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

grow Session 1 (1:00:00)
Monday, Afternoon Session III 1740-1840
Room Name: Blenheim size: 200
-



Request Information:


-
Working Group Name: Global Routing Operations
Area Name: Operations and Management Area
Session Requester: Peter Schoenmaker

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 60
Conflicts to Avoid: 
 First Priority: idr sidr rtgwg rtgarea opsec




People who must be present:
  Christopher Morrow
  Peter Schoenmaker
  Warren Kumari

Resources Requested:

Special Requests:
  
-

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[Thomas.Graf]

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

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

From: Jeffrey Haas
Date: 2018-02-22 01:52
To: Paolo Lucente
CC: Tianran Zhou; 
grow@ietf.org; 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 opsawg
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 secon

Re: [GROW] I-D Action: draft-ymbk-grow-wkc-behavior-00.txt

[Job Snijders]

Hi authors,

This is an excellent initiative.

Kind regards,

Job

On Tue, Feb 27, 2018 at 09:13:31AM -0800, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title   : Well-Known Community Policy Behavior
> Authors : Jay Borkenhagen
>   Randy Bush
>   Ron Bonica
>   Serpil Bayraktar
>   Filename: draft-ymbk-grow-wkc-behavior-00.txt
>   Pages   : 6
>   Date: 2018-02-27
> 
> Abstract:
>Well-Known BGP Communities are manipulated inconsistently by current
>implementations.  This results in difficulties for operators.  It is
>recommended that removal policies be applied consistently to Well-
>Known Communities.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ymbk-grow-wkc-behavior/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ymbk-grow-wkc-behavior-00
> https://datatracker.ietf.org/doc/html/draft-ymbk-grow-wkc-behavior-00
> 
> 
> 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/
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow

Re: [GROW] WG LC for draft-ietf-opsawg-ipfix-bgp-community

[li zhenqiang]

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
Date: 2018-02-22 01:52
To: Paolo Lucente
CC: Tianran Zhou; 
grow@ietf.org; 
draft-ietf-opsawg-ipfix-bgp-community@ietf.org;
 opsawg
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

[GROW] Peter stepping down as chair - volunteers?

[Warren Kumari]

Hi there GROWers,

Sadly, Peter has just let me know that, due to other time commitments,
he will be stepping down as one of the GROW chairs.
I'd like to take a moment to thank him for all of his hard work, and
also to ask for volunteers who would be willing to set up and serve.

GROW is always a low drama WG (thanks!) , and Chris is a very
accomplished chair, and so this would be a fine WG to gain experience
with if you've never chaired before.

Many / most of the GROW participants are also long time IETF
participants, and so are likely somewhat familiar with what chairing a
WG involves, but those who are not:
The Tao is always a good reference: https://www6.ietf.org/tao.html, as
is the WG chairs page: https://www.ietf.org/chairs/

I, and I'm sure Chris, will be happy to provide more info / details as well.

Please let me know if you're interested in being considered,
preferably by Friday.

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow