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

From: "Aaron Falk" <[email-masked]>
Date: Mon, 06 May 2019 09:53:38 -0400

Reminder that we are having an interim meeting this Weds.

1. Do we have any additional topics to add to the agenda?
2. 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

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 6 May 2019 15:56:21 +0200

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-masked]> wrote:
> 
> 	• Do we have any additional topics to add to the agenda?
> 	• For existing topics below, who should lead the discussion?
> --aaron
> 
> 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/
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 06 May 2019 16:26:47 -0700

> a virtual interim meeting on 2019-05-08 from 11:00 to 13:00 America/New_York.

I've created a Pull Request to add framing to the Interface document. Please take a look so we can discuss!

https://github.com/ietf-tapswg/api-drafts/pull/323

Thanks,
Tommy

---

From: "Holland, Jake" <[email-masked]>
Date: Tue, 7 May 2019 01:00:55 +0000

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-masked]> wrote:

    Cheers,
    
    Brian

---

From: Max Franke <[email-masked]>
Date: Tue, 07 May 2019 07:34:16 +0200

Hi Jake,

thanks a lot for the work on yang in PyTAPS!

Side note:

We have indeed not implemented support for multiple identifiers as there is no racing yet, but as I understand it you would simply repeatedly call endpoint.with_address() with the different identifiers.

Best regards

Max

---

From: Michael Welzl <[email-masked]>
Date: Tue, 7 May 2019 09:41:14 +0200

hey,

cool update!  regarding your question, should this be a github issue against taps-interface?  i’d say yes!

cheers
michael

Sent from my iPhone

> On 7 May 2019, at 03:00, Holland, Jake <[email-masked]> wrote:
> 
> Hi taps,
>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 7 May 2019 10:46:32 +0200

Hi Jake,

thanks on your work on PyTAPS and the YANG model!
I love the idea of having a implementation-agnostic way to specify endpoints and transport properties.

I have not reviewed the work on PyTAPS yet, but have some comments on the updated YANG model.
It is far better than the first version, especially with regards to the endpoint definition.

With regards to the properties, I think the modelling of transport properties still does
not work as the transport properties in the draft. The transport properties in the YANG
model model only a subset of the selection properties.

For the actual preferences, I’d rather expected something like:

container transport-properties {

  leaf reliability {
    description "Reliable Transport";
    type preference-level;
  }
  leaf per-message-reliability {
    description "Per-message Reliable Transport";
    type preference-level;
  }
  leaf preserve-order {
    description "Per-message Reliable Transport";
    type preference-level;
  }
  leaf zero-rtt-establishment {
    description "Use 0-RTT session establishment with an idempotent Message";
    type preference-level;
  }

  list iftype {
    leaf type {
        when "derived-from-or-self(../type,
            'taps:local-interface-selection')";
        type identityref {
          base "ianaift:iana-interface-type";
        }
    }
    leaf preference {
        type preference-level;
    }
    description "interface type constraint for local interface selection";
    reference "RFC 7224 Section 2";
}

But maybe we should discuss details off-line…

> On 7. May 2019, at 03:00, Holland, Jake <[email-masked]> wrote:
> 
> Hi taps,
> 

AVE!
   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

---

From: "Holland, Jake" <[email-masked]>
Date: Mon, 13 May 2019 14:25:03 +0000

Whoops, I just noticed I didn’t send this last Tuesday!

I would have let it drop as out-of-date, but I still wanted to say thanks to Philipp for the review and suggestion.

Hi Philipp,

Thanks for taking a look, and for the suggestion.

I agree that seems nicer, so I updated the model and the input .json files to match, and adjusted the import logic so it runs again.  I also cleaned up the transport-properties in that repo to match (I think) with the latest text from section 5.2 of taps-interface.

- Jake

From: "Philipp S. Tiesel" <[email-masked]>
Date: 2019-05-07 at 01:46
To: Jake Holland <[email-masked]>
Cc: "Brian Trammell (IETF)" <[email-masked]>, Aaron Falk <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: YANG model for TAPS (was: Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2019-05-08)

Hi Jake,

  leaf reliability {

  list iftype {
    leaf type {