Agenda Data
4) Jenny Ramseyer
* draft-ramseyer-grow-peering-api - 15 min
Jenny/Tom talking about a peering-api (joint work with others of course)
Notes about having automated systems manage this data
Notes about automated notifications and such to avoid a bunch of
hooman problems
Authors need help on security/etc considerations, pls send txt!
5) Paolo Lucente
* draft-ietf-grow-bmp-tlv
* draft-ietf-grow-bmp-rel
* draft-ietf-grow-bmp-tlv-ebit - 15 min
* draft-younsi-grow-local-path-id
* draft-francois-grow-bmp-loc-peer - 10 min
Questions:
benmaddison - feedback - Erroneous update logging ought to go in the
event logging
tomasgraf - good work, visiblity into routes and policy is great!
BMP Loc-RibPeer Address Presentation - comically short said the laughs
in the room
BMP Local Path-ID - work progresses
(comments/revisions/implementations)
Questions?
tomstrickx - Force implementation to choose on memory or cpu heavy
work?
* paolo - choose to go with 1 to avoid vendors not implementing.
6) Tobias Fiebig
* draft-ietf-grow-bgpopsecupd - 20 min
"Note that policy makers do not think about this like YOU do"
Questions:
benmaddison - re-read and 'thanks for this work + i did not hate it so
much'
Some suggestions inbound from ben to authors.
Break up the 'how to computer' vs 'how to security computers'
This is a generally hard to maintain document ;( in the ietf.
jeffhaas - Long term docs we've talked about, but so far we've not
finished that conversation well :(
can we do this on github, for instance, with rolling updates?
wkumari - living documents discussion means we must make some
commitment to re-do the work regularly.
this almost certainly means 'do not nit-pick' quite as much
* tobias - yes, that may be good, but also...
tomstrickx - without maintaining this properly we'll have some bad
outcomes ;( indecision on this topic ;(
jared - updates to the document SHOULD be good, to update what's
wrong/bad/etc here. Push then on
the chairs/ads/etc to get liason/etc done better.
wkumari - unless we can deprecate 194, then what? we'll need to do that
or at least consider that.
* tobias - likes some update idea.
rudiger - The audience of the original doc was almost certainly NOT
policy folks :( but actually
practicioners/operators, oops. If we want policy makers, that's going
to be rough.
benmaddison - definitions are hard - see 'peer' in documentation.
Customer/non-customer may be helpful in the doc?
* tobias - that SORT of is in the document, but.. not always.
wkumari - BCP is a 'grouping label' - 194 COULD be part of a 'set' with
other RFCs.
* tobias - bcp state MAY include restrictions on how often changes may
occur.
7) Jinming Li / Yisong Liu
* draft-liu-grow-bmp-stats-reports
* draft-liu-grow-bmp-rm-aggregated - 15 min
(NOTE: presentation conversion from PPT -> PDF is still np hard -
in-meeting was not correct, go to the
materials version)
Questions for Stats-Report:
jeffhaas - counter adoption was FCFS on the registry. The WG/chairs
should decide if the documents
proposing new counters we should make the assigmments in a snappier
manner.
thomasgraf - monitoring some of these counters are 'hard to monitor' -
Ideally we would count and log overages (because of paolo's
work/document(s))
for 'license customer overage' - why not use enterprise tlv's for this?
(also says jeffhaas)
rudiger - stat counters look like a thing that belongs in a YANG model?
(and snmp?) Is rudiger incorrect?
jeffhaas - for bgp YANG discussions - 'shouldnt all of this be covered
by existing counters?'
for all NEW things, can they get into YANG? yuppers!
benmaddison - we probably want not a huge number of new counters, but a
manner to get YANG model data
from BGP into BMP. Using IDR as a check/balance on that seems good
because those implementers
should be able to say whether they are crazy-pants or not.
Questions for RM-Aggregated:
jeffhaas - implementation's storage conversation inbound - state
managing and bmp state .. maintaining this
in 1+ space could be costly. Notes about path attribute sharing across
paths/prefixes USED to be
higher, around 5 or so on average, that's reduced a bunch over time
though, so the aggregation
proposed here may not be as saving of resources as hoped.
* jinming - If a peer sends prefixes, and those are shared among more
than 1 peer you may get aggregation
benmaddison - doable, but maybe not desireable in practice. Moving work
from the monitoring-station to
the router is moving costs in the wrong direction. Further reducing
fidelity before the monitoring
station is going to cost you insight and t-shooting capabilities :(
this may not be useful 'for me'
maybe others as well?
maria - this is going to be very rough for implementations :( looking
for 'similar prefixes' is not terrific,
this is much more costly than just fifo'ing the the updates. This won't
get into Bird.
paolo - 'what problem are you solving?' - has any of this been
measured? the savings/costs/etc?
'what is the applicability of this proposal?' - where (which rib?) does
this get used/applied?
'The doc is about route monitoring, not covering any of the other
messages?'
'This will be impactful, in the wrong part of the problem :(' - saving
bits on the wire for this
seems very short-sighted.
'Why not do this with TLV instead?'
8) Jeffrey Haas
* draft-hmntsharma-bmp-tcp-ao - 5 min
Questions:
jared - 'Is there a reason why we would NOT want to do this?'
jeffhaas - yes.
scudder - 'Hey, we should have done this before, the iesg back then
would have been happier'
jeffhaas - we will be sending an adoption request!