Minutes IETF97: sidr
minutes-97-sidr-02

admin work done

joel - sidrops overview
  two chairs - keyur patel/morowc
  remaining docs headed to sidrops from sidr.
    already in wg, so just migrating over from the existing wg.
  documents should get worked in sidrops
  more work will come when that's done
  Call to join list:
    sidrops@ietf.org

  charter display
  - important point to joel -> ops means not just ISP folks
    also CA and RiR/NIR/LIR folks, and relying party software folks.
    Finally the research/measurement folks as well.

  Questions?
    Charter questions from Dan about 'what about isp folks?'
      - joel -> we definitely included them perhaps implicitly?
    tim ripe ncc - charter 'work'/items - What if we need to add new work?
    Joel - Current WG will get closed out 'soon'. New items will get pulled
      into the wg as approrpiate No real impediment to moving docs into sidrops.
    Sandy - Movement of docs into the new queue, do those need to get renamed?
    Joel - nope. Fairly sure not.. but will verify.
 
Declan ma - Slurm update
  Motivation discussion(s) - Selective overrides and protections from adverse
    actions.

  The overview of the update - reorganize the layout, rewrite usecases
    update security concernts.

  Reorg - updated slurm mechanisms and rpki/rp slurm integration. 

  usecase revisions include proviate INR and referring to the adverse-actions
    draft as well.

  A display of the RP stack and SLURM's placement in that stack.

  Security considerations cover also - assertions about non-private INRs
    errors in the slurm file && authenticity/integrity of the slurm file.

  There were some considerations to take in to account with other RP software
    authors. Providers of software are free to define their own config file,
    and not required to use ABNF for that format, the ABNF is solely to 
    describe the content, not the format of the result.
  Keeping ABNF in the document provides well known defintions, examples
  in the appendix for json/xml can provide worked examples.

  RPSTIR has supporting SLURM in the near future, fyi.

  Thanx to the previous authors, and existing RP authors for consultations.

  Questions - 
    Tim @ ripencc - move this to sidrops, more work will likely be required
      so lets do that there.

    tim @ ripencc - comments about previous versions of this effort, and about
      how to handle 'ignore filters' (what SLURM provides). Push for a single
      file format for slurm. The ABNF format is well defined, but library
      support is 'rough'. Of the other options xml is available, json as well
      the best options <missed>. (fixed: YAML)
      Lastly, future work here should move toward an API, not just a file.
      Suggest as well that in sidrops we should include other RP authors as well

    Rudiger - Agree that one format is better, Preferring ABNF instead of others
      seems XML can include the schema and grammar (abnf) are 'equivalent',
      though not exactly the same. There is software to support some of these
      formats as well.

    RelaxNG grammar looks a lot like ABNF, and exposes syntax/structure for
      semantics as well.

Tim - Tree Validation slides
  This document is listed for SIDROPS, The goals and process of the document
  are the goal here today.

  This is a document to cover (informational document) how the RIPE
    implementation operates.

  Why to take this to the WG? because this is transparency and review request
    from the WG folks about how the software operates.

  These concerns were included in the document, without changing the text
    of what the document actually does.

  The document discusses TODAY's software, tomorrow's may change, How does that
    work? Should we do that long term? Option proposed here is to:
      move the doc to WGLC
      Future updates should be included with release of the software
      After enough, take those back to sidrops and -bis/etc.
     Alternately - just publish with software, no document in the WG...
       less transparency, less review, perhaps less good for the community?
   Questions?

   Rudiger - DT - works to publish document, and perhaps later user-forum 
     to get feedback/etc as well. Not every revision necessarily needs to
     go through the RFC process.
   John - jnpr - There's a comment about how unique the request is, however
     it seems that review is good here.

   Sandy - review seems good, we could also move things over to the wiki
     instead?

   Randy - Perhaps there are lots of people making overviews of existing
     protocols... so this seems normal, yes?

   Tim ripe - Comments about how the particular draft covers the validation
     process only, not the software overall work... and wiki work may be less
     controlled and thus a bit more hard to manage, prefer to not do this route.

   joel - ad - A question to the ML should wait until more folks show up there.
     If you want to manage just as a draft that's also .. fine, though no
     consensus happens, which may not be the goal.
     Asking for consensus may not have the same view as today's WG... that
     may not fit your needs/requirements.

 
 Oliver - MIST - BIRD/Quagga interop and BGPSEC-IO!
   BGPSEC-IO makes large scale traffic easily to use in test labs.
     scripting can be done as well as output being usefully formatted.
     'Ixia for bgpsec'
    Neat work for crypto testing as well... you can provide just bgpsec
      path attributes which can then get crypto testing done.

  A set of testing platform and output on a laptop/etc which shows the test
    harness and shows quagga/etc output.

  (lots of images, less words to work around)
  showing a progression of testing bgp paths and bgpsec, then the impacts to
  paths and routes as bgpsec takes effect. (origin validation failures
  show up as path selections despite the shorter path(s))

  New scenario, with a craftier AS100 ... moar evile!
    Paths show that still the proper path keeps the win, path and origin
      validation. COOL!

 Randy/Tim - Testing stuff discussion - 
   No pink square for Randy - 
   Blaming the chairs for the requested talk, despite..... anyway!

   Tests which may be possible:
     CA interop
     Caches make the same results?
     Do caches fetch from eachother properly?
     Are routers making the same validation results?
     Do routers validate at all?

   For CA testing:
     Do the CA's interoperate - (randy)
       see complex pict in slide (5)
       (point being that global ISPs may have resources from more than 1 CA,
        does the validation/etc set actually work??)
   For Validators/Caches -  (tim)
     Do these make consistent results?
     With multiple redundant fetching processes?
       A possible architecture is that a frontend cache polls the world,
       that cache is used to feed the network distributed caches...
       does this work properly?
     Randy points that RPKI-RTR has pulled crypto out, so routers are much more
     dependent upon the infra being corect here... relying upon external parties
     can lend to bad answers as people play games.

   Router testing - (randy)
     Semantics with continual regression testing... make sure that old bugs 
     do not zombie on us. Same here.

     A large 7513 image with ins/outs/digestion and perhaps gas.
     Assuming that the RPKI implementaiton is tested and the cache is
     and the rpki-rtr protocol/etc... only thing changing here should
     be the RTR, not the other outlying parts.

   How to test these constantly and reliably.

     Question - sandy - how to bring up a new ISP without previous knowledge.
     Randy - Should 'just work' since 'unknown' means 'i have no rpki-rtr data'
     Oliver - testing routers could be done with 'bright' - which permits
       connecitng a router to test systems, which sends roas, traffic and
       monitors results to see if the ins/outs are what are expected.
       (sounds like using routers instead of bird as in his example/presos)
     Tim - having a solid framework to test would provide benefits.

     NOT UNH person - Could you perhaps approach UNH for this work?
     Carlos - sees benefit, but seems that a more detailed list of
     requirements could make the decision process here simpler.
       Finding outsourcing opportunities is simpler when there's clear
       requirements.
     
     Test CA instances exist at some places (DT/Lacnic/etc) can there be
     commitment to provide test infrastructure from the current versions/etc
     and use that for future deployments and upgrades/changes.

     Rudiger - Perhaps having the test instances deployed and available
     would make this possible too?

     Mark@arin - there is an OE&T environment, which has full sets of tooling
     and such, those should be possible to be used as well.

     Oliver - Are there caches available? with 6810-bis ports? (rrdp)
       randy - yes

     Tim - there's a test environment, it's mostly up... but some requirements
     about 'how to play' are still to be worked out. Suggested to talk later
     about this.

     Tom - apnic - there's a testbed available, it's public, let's do this!

     Dan Shaw -afrnic - there's no public testbed, but we can make available
     to the public folks ondemand.

     Taiji -  jpnic - There's a testbed testing 3 things, one of which is
       counts of public roa, 
     YuFu - cnnic - there's a test bed here as well.