Minutes IETF119: grow: Wed 05:00
minutes-119-grow-202403200500-00

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)

• Demo time - don't crash the internet!

• Notes about having automated systems manage this data

  • auto-peering up/down
  • PublicExchange supported today
  • PNI 'tomorrow'

• Notes about automated notifications and such to avoid a bunch of
  hooman problems

  • Auth with peeringdb OAUTH
    • are there better options?

• Authors need help on security/etc considerations, pls send txt!

• Does this draft belong in Grow?
  • Side Meeting 3/21 1400-1500(BrisbaneTime) in M9
    Questions:
    wkumari - fits in section2 says 'John' (scudder?)
    benmaddison - 'how does this change workflows in Provider's
    systems/etc?'
  • Tom - Not always works? can use backend logic/etc to
    limit/permit/require-ponies/etc
    benmaddison - had you thought about what to permit/deny/etc
    easily?
  • Jenny - yup! we thought of that, can do some work in the text
    for this? Talk about extensions at tomorrow? :)
    david lamparte - Should spell out more of how this should work,
    please - where does the software live?
  • Tom - third endpoint outside the router... 'probably not nginx
    on router'
    rudiger - Peering from $FORMEREMPLOYER would not have gone
    through this process, but 'what are the expectations on
    turnup/down for this system?' 'What t-shooting can you do? how?
    etc'
  • Jenny - Yup! this sounds like a need for an SLO/SLA about the
    expectations/etc and you CAN fallback to emails.
    benmaddison - Sounds like there's a bit more of 'state machine'
    required for this protocol/proposal
  • Tom - Yup! we'll need to have some more guts here, more
    consensus more details about ordering of
    operations/expectations.
    rudiger - Engineering of the protocol/service happens now -
    Propsal sounds like adding some more state in the
    process/proposal/protocol
    wkumari - even so, we can get more content into the ticket
    system and move the process forward.
    david lamparte - 'yes how about we accept in the routing
    protocol - a copy/paste from the api!'
    job - Sounds like WGAdoption call is in order - see list.

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!