Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2019-05-08

["Holland, Jake" <[e-mail]>]

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)" <[e-mail]> 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 <[e-mail]> 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
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/taps
    
    _______________________________________________
    Taps mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/taps