Hi taps, I haven't updated the docs yet, but if you're interested I can give a brief report on a basic proof-of-concept for yang and (almost) multicast SSM running against my fork of python-asyncio-taps. If anyone has some time to review, I'd love to get feedback.
I adjusted the yang model to match the existing implementation, and avoided making any deep changes to the flow inside python-asyncio-taps. I haven't yet submitted the updated model to draft-jholland-taps-api-yang, but you can review the proposed model and a couple of functioning examples here: https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/PyTAPS/modules/ietf-taps-api.yang https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-client2.json https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-server2.json These replicate the functionality of testServer.py and testClient.py, when run with: python yangServer.py -f ./test-server2.json python yangClient.py -f ./test-client2.json It's not beautiful, it uses a C library to interface with libyang for model validation, because pyang was too painful. The multicast is slightly sketchier, but it issues an IGMP membership report when running: python yangServer.py -f ./test-mcastrx.json https://github.com/GrumpyOldTroll/python-asyncio-taps/blob/master/test-mcastrx.json It was a little awkward and surprising in that some values had to be added in order to override the implicit defaults. Side note: There's a disconnect about the "multiple endpoint identifiers" clause in the "Specifying Endpoints" section of taps-interface which I think the current implementation doesn't follow. I didn't try to fix it, but it looks hard to support without tightening up what the semantics here are, exactly: "Multiple endpoint identifiers can be specified for each Local Endpoint and Remote Endpoint. For example, a Local Endpoint could be configured with two interface names, or a Remote Endpoint could be specified via both IPv4 and IPv6 addresses. These multiple identifiers refer to the same transport endpoint." Should this be opened as an issue against taps-interface? Cheers, Jake On 2019-05-06, 06:56, "Brian Trammell (IETF)" <[email protected]> wrote: I'd suggest we do a scrub of issues in github.com/ietf-tapswg/issues tagged discuss for the arch and API drafts, as well, and try to make sure all issues are assigned by the end of the call. This is certainly agenda item 3 though. Cheers, Brian > On 6 May 2019, at 15:53, Aaron Falk <[email protected]> wrote: > > Reminder that we are having an interim meeting this Weds. > > • Do we have any additional topics to add to the agenda? > • For existing topics below, who should lead the discussion? > --aaron > > On 10 Apr 2019, at 8:10, IESG Secretary wrote: > > The Transport Services (taps) Working Group will hold > a virtual interim meeting on 2019-05-08 from 11:00 to 13:00 America/New_York. > > Agenda: > Topics: > * Framing > * Implementation draft - https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ > > Information about remote participation: > https://ietf.webex.com/join/taps | 316 448 940 > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
