#### ReHash Agenda {#rehash-agenda} Chairs slides #### Paolo Lucente {#paolo-lucente} * draft-ietf-grow-bmp-tlv * Paolo Lucente presented slides * discussion on bumping version number * Job Snijders -- cost associated with bumping version number, authors need to consider trade offs and impact on other implementations. * Paolo Lucente -- pmacct implementing v4, FRR already implementing version 4, and co-author draft implementing version 4, others not quite there * Job Snijders - take a survey on mailing list in favor of version 4 * no comment specific on bumping version, take discussion to mailing list * Robert Raszuk -- add-path flag specific to address-family & peer, not just peer * draft-lucente-grow-bmp-tlv-ebit * Paolo Lucente presented slides * Paolo Lucente - draft is done * David Lamparter -- already imlement metric specific stats type. cannot remove from iana registry because old code. iana -- "reserved previously used for experiment" * Job Snijders - version 2 says "document makes no changes to iana registry" * Job Snijders - need to update version 2 to reflect what do do about iana #### Camilo Cardona {#camilo-cardona} * draft-ietf-grow-bmp-yang-01 * Camilo Cardona presented slides * Job Snijders -- upto authors on how to handle issues. some use github/pull request, others use mailing list requests. * should update group about status of changes * no questions * draft-cppy-grow-bmp-path-marking-tlv-12 * Camilo Cardona presented slides * Job Snijders -- send email to start process to adopt * Job Snijders -- why is reason code only 2 octets. many datapoints to check. ebgp transit provider 10-20 exit points result in reject for route policy. 64 points seems limited. * Camilo Cardona -- 65k reason codes, status codes only 64. * Job Snijders -- lets make sure we have ample room to give operators flexibility. * Ben Maddison -- usecase aproximate instrumentation of route policy, expecially in test. make reason/status code wide enough. add hierarchy. may not have vendors that can make it work. * Camilo Cardona -- route-policy draft (need specific reference) add complexity of header key, 2 are complimentary. this is cheaper way of covering it, would prefer to keep this one simple. * Ben Maddison -- 2 drafts are same thing. not worth having both drafts. * Camilo Cardona -- proposes one option remove reasons code, and keep status here, and then use other draft complex way. * Ben Maddison -- camilo's idea could work. just status code without reason not useful. camilo usecase just need status. battling with complexity of adding scope. ben - have intergration tests that try to cover routing policy. routing policy is super complex, and wants to perform coverage test of route policy. * Paolo Lucente - path tracing draft no longer active, very complex, implemented it in collector. now have REL draft presented at 115, and cover many of the usecases. looking for input on REL. Please provide input! * david -- distinction between trace and heirarchical status/reason, trace too expensive, but status/reason useful. * Ben Maddison looking for error chain rather than trace * Job Snijders -- want to correlate exit point of routing policy * Job Snijders -- mail sent to list ask to adopt * Rüdiger Volk -- coding trace through route-policy, implementors may not be able to code. wants drop reason code on RIB-in, suggestion "allow in config language drop statement support integer", not no complex coding * Jeff Haas -- when you want to output data 2 choice: spit out immediately or hold in state. stack trace is difficult, proceedureal state machine, gdb style stack trace, have to maintain stack, item 3 how to represent in fashion that is useful. do you want internet route's worth of stack trace eating memory. things are doing able but expensive. just note thing is rejected, have a catalog of reasons, netconf operation, test route, instead of state * Ben Maddison -- tests run not on production network. test environment like production. likes Rüdiger Volk idea, and extend this to many action statements. jeff haas large integer required, have to hold onto code until installed. * Jeff Haas -- I suspect if you thought about how many bits it would take to actually represent the state that you're looking for, good find that your scaler is actually a very very big bit string. * Rüdiger Volk - at some point vendors implemented instrumentation for policy implementation turn on statistics "like give policy visited and how much time" maybe useful if still around * Job Snijders -- continue on mailing list #### Pierre Francois {#pierre-francois} * draft-francois-grow-bmp-loc-peer-00 * Pierre Francois presented draft * Jeff Haas -- vbit redefined. make this feature difficult as existing implementations already expect. Loc-RIB view sent initially (peer up state) optional TLV RIB name. expectation of name of table. peer up message include system-id. add additional TLV for peer up, station up keep track. can keep it in each route montioring message, or just have it at peer up message. That's more for the case where IPv4 you were correct. For the case where it is IPv6 , the v-bit is otherwise move for something else, you would be changing the parser path for this. I believe. * thomas -- if not part of RMM just shifting data downwards * Pierre Francois -- cannot keep it per a peer with add-path, so becomes quite complex * Camilo Cardona -- make sure yang model supports it * Job Snijders -- RFC9069 -- not strong language to confirm the field is all zeros. per peer header ipv6 16B of zeros, and ipv4 4B of zeros * Job Snijders -- how did this situation come to be? oversight? some implementation struggled to get information. * Pierre Francois -- own implementation more difficult to make zero than set to peer address * Paolo Lucente -- rfc9069 author, what francois said above vendors struggling so just make it zero field * Jeff Haas -- 7854 first is vbit second is fbit. are you making a new field? * Pierre Francois -- just use field right after * Job Snijders -- doesn't seem new bits need to be added * Jeff Haas -- rfc7854 per peer header address can be very long in size dependant on vbit. rfc9069 same bit position different name space. must be changes in impelemtation loc-rib peer, or rib-in peer * Job Snijders -- some implementors may ignore v-bit. not vbit for loc-rib peer, reusing field loc-rib/rib-in * Job Snijders -- take an unused bit to prevent issue * Jeff Haas -- rfc9069 behavoir should be new version number * Job Snijders -- may need TLV * Jeff Haas -- TLV is fine, but not longer "free change". If collector already knows who it talking to, knows RIB, optional TLV for system address/router-id. collector has enough information to decorate db * Paolo Lucente -- preference to BMP stateless BMP TLV. make BMP as stateless as possible. reduced complexity, stateless. first fbit stay, 2nd unused (0). does see problem with using existing bits * Job Snijders -- issues not insurmountable. * Pierre Francois -- needs update to rfc9069 (job says yes) * Job Snijders -- show of hands, interested in continuing this work -- 10 or so support work * Job Snijders -- take feedback, make decision which direction (TLV or bit), upload update, then consider working group item