Hi taps folks, TL;DR: I think the spec should have a YANG model and I want to use it to get multicast support in an implementation.
I recently started digging into the taps API with the intent of adding multicast support, but it looks like it's basically already there, as far as it goes[*]. But I ended up with a higher-level comment, so I thought I'd raise it to the wg and ask what you all think. I found the whole "abstract interface" approach a little too loosey-goosey, so I thought I'd try to suggest a way to tighten it up. My goal with this is to make it much more clear (to the point of being mechanically checkable) precisely what a compliant API provides. I'm not attached to the structure I'm proposing or to any of the particulars in the straw-man I've posted, but if it's not tightened up with something at a similar level of concreteness, I'm concerned that different implementations will be not only incompatible in random underspecified corner cases (like BSD sockets today when you try to make cross-platform C code), but also are likely to end up with very many important differences that would make the whole taps effort more or less moot. In a world where we end up with a doc at the level of abstraction I'm currently seeing in draft-taps-interface, it seems to me that if 2 different API implementations were written in the same language, it'll be prohibitively difficult for an app to migrate from using one to using the other, just because so many aspects of it are left open to the implementors. In that context, I thought a YANG model would be useful here to provide a cross-platform way to specify what exact properties and objects exist, an exact format in which the values can be specified, and what exact semantics they have, while still allowing for a sane extension path and language-specific implementation details. I'm thinking some language a bit like the first bullet in Section 4.2 of taps-interface: A compliant implementation SHOULD provide a language-appropriate way to configure a PreConnection using YANG instance data for this model, and SHOULD provide an API that outputs the YANG instance data for an established Connection. An implementation MAY also provide appropriate APIs for directly editing the objects without using YANG. It's RECOMMENDED where possible to use names that mechanically translate to the names in the YANG data model, using capitalization and punctuation conventions as expected for the language of the implementation. And then of course a YANG model: https://datatracker.ietf.org/doc/draft-jholland-taps-api-yang/ (draft-jholland-taps-api-yang) If this seems useful, it will need lots of refining. I'll be surprised if any part of it survives exactly as written. It's a quick and dirty attempt to concretize a few of the things I saw listed in draft-ietf-taps-interface, as a starting point to fill out if it seems useful. But the model parses, and the example data instances in the draft parse against the model (all with libyang). One of the main reasons I'm doing this is because it seems to me what's specified in taps-interface-02 today is missing some key features, like an enumeration of the properties in the Local/RemoteEndpoint examples in section 5.1. And I don't see that listed as an open issue in github, which surprised me a bit. I think oversights like this will become immediately and painfully obvious when there's a reference implementation that includes a YANG parser and an explicit data model, as opposed to the combing of the document and a sort of eyeballed comparison to NEAT that I tried this week to reach that conclusion (which I found challenging even though I thought both the document and the library were mostly pretty well written). The whole thing at this point just smells to me much more abstract than it really has to be or than it's really useful to be, which bothers me because the idea of replacing BSD sockets with something usable seems like such a great idea. I'd like this to be something I can actually use in a way that makes my life easier someday soon. But I think I'm at the point where I need a sanity check to see if I'm just missing something, or if this seems like a useful direction. Thoughts? Suggestions? Worth discussing in Prague? (If so, can I get a slot?) Cheers, Jake *: I concluded that there's no reason multicast couldn't be supported today, if there were an implementation that could reasonably claim to be compliant, by just adapting some of the examples in draft-ietf-taps-interface-02 and understanding the semantic meaning of multicast address spaces inside the API. For example, I couldn't find any reason this can't be expected to set up an SSM channel subscription without any further ado, given a sane implementation that supports it: RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier.WithIPv4Address(192.0.2.21) LocalSpecifier := NewLocalEndpoint() LocalSpecifier.WithPort(30000) LocalSpecifier.WithIPv4Address(232.252.0.2) NewPreconnection(RemoteSpecifier, LocalSpecifier).Listen(...) Maybe there's some value in specifying a "JoinSSM()" to override defaults in the PreConnection, just to make sure you're specifically asking for multicast. I think that would be fine for native multicast, but like I said, a much smaller point than the looseness of the API. Where it gets a bit more complicated is trying to handle multiple options for discovering a usable unicast tunnel for multicast traffic, as described in Section 2.4.1 of draft-ietf-mboned-driad-amt-discovery-01. I'd like to have a decent place to tack on an extension to this API that can transparently, within the connection API, discover the best available AMT relay and start using it when native joining is unavailable (and also to provide normative controls for configuring it when there's administrative configuration to be added). But that's a 2nd order question for me at this point, because in the current TAPS API I don't see any obviously good spot to put selection controls for that kind of tunnel discovery selection, or really a good way to explain what it's supposed to do, if I tried to add controls to something that's there. Solving that is my main motivation for being here. (Well, and that the BSD socket API for multicast is kind of a disaster today.) Anyway, if taps finds the whole YANG suggestion useful, I'll probably suggest some new extensions about this, and maybe a few other points, especially maybe around trying to put in a structure that can support some kind of sane explicit layering. But I'm not sure I can articulate those suggestions in a way I'm sure is meaningful without first getting a more clear specification nailed down about what's actually in the taps spec. Because right now I'm mostly just confused about what an API implementation would really look like, and how you could tell whether it matches the taps-interface spec. From: Aaron Falk <aaron.f...@gmail.com> Date: 2019-03-04 at 10:53 To: taps WG <taps@ietf.org> Cc: Zaheduzzaman Sarker <zaheduzzaman.sar...@ericsson.com> Subject: [Taps] call for agenda items at TAPS IETF-104 Hi All- What should we use our time to discuss? Let’s focus on things that would benefit from f2f discussion, consensus building, or just argument. :) • TAPS docs: are there open topics that need group attention? Seems like we settled most of the remainder at the interim. • TAPS security: this seems nearly done. Anything to discuss? • Implementations: a good topic for information sharing but less important than anything needing agreement • Mobility: https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D17&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=HUsBVBF_GhNiOk3gqY_m5qZMD-sPmBJ93GE5wd3D5_s&e= and https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_review-2Dietf-2Ddmm-2Dondemand-2Dmobility-2D15-2Dtsvart-2Dlc-2Dwesterlund-2D2019-2D01-2D08_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=pLW5gSyetfVe_ixG4_u7qKX_VcjIqzN7Ju2BgM2rpQo&s=0YmC_XCAu4_GVYdFi0HxiKaKBpan2COYqBL1mB6bXrY&e= --aaron _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
