On 7 Mar 2019, at 04:55, Holland, Jake <jholl...@akamai.com> wrote:
Hi taps,
(Trying again, but simpler.)
I'm looking for a consensus yes or no answer:
Is a normative config input format an interesting and useful
direction?
The idea is to add functionality like this, in taps-interface:
newPre = PreConnection.NewFromJson('''{
"remote-endpoint":{
"hosts":[
{ "host":"example.com" }
]
}
}''')
With a fully specified json input format that can provide all the
configurable values.
If no, I'll move on and assume I just don't understand taps goals.
If yes, I'd like 15 minutes to discuss in Prague, and keep reading:
I think a full definition of an input json format can be exactly
specified by a YANG model. (With xml for free, if you want it.)
I tried to sketch a start at what a YANG model for this might look
like:
https://tools.ietf.org/html/draft-jholland-taps-api-yang-00#section-3
I'm not a YANG expert yet, and it's not much of a model. And it's
very
far from complete. But it compiles, and all the examples in the
draft
validate against that model with libyang. If it's worthwhile, I
think
something like this can be good (and extensible!), if done right.
I believe something along these lines would sharpen up taps-interface
a lot. (After filling in all the taps-interface properties.)
The reason I'm asking is because right now, taps-interface to me
seems _almost_ really good, except too confusing and vague to
actually
build an API that can replace BSD sockets. I think with a solid
config
format with normative and testable examples, that could be fixed.
If consensus says "interesting", I'll want 15 minutes to discuss it,
and
to start digging into how to make it good. (And also to add
multicast
support to the model and at least one implementation.)
Thanks for your consideration.
Cheers,
Jake
On 2019-03-04, 17:19, "Holland, Jake" <jholl...@akamai.com> wrote:
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
