Re: [Taps] call for agenda items at TAPS IETF-104

[Michael Welzl <[e-mail]>]

Hi,

A few answers in line; I'll mark them with MW:


> On 7 Mar 2019, at 20:10, Holland, Jake <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Thanks for responding, much appreciated.  (And also to Tommy
> and Aaron.)
> 
> Based on the replies from you, Tommy, and Aaron, I'll plan
> to present something in Prague, and can you please put me
> on the schedule, Aaron?
> 
> More responses inline with <jh></jh>, and thanks, these
> questions were very helpful to help me focus on what needs
> explaining vs. what's obvious.
> 
> 
> On 2019-03-07, 00:32, "Michael Welzl" <[e-mail]> wrote:
> 
>    Hi,
> 
>    Very sorry for the silence. I can only speak for myself, but here's an example of why this one person was silent:
>    - When you created your issue on multicast in github, I thought of answering (positively), but then thought that the repo is about to move, and it would probably be better to delay things until the move is finished.
>    - Then, the issue was overruled by your email. I read it and found it interesting, but hoped for someone else to answer because, frankly, I was afraid to make a fool of myself ... because I know almost nothing about YANG.
> 
> <jh>
> Thanks for explaining, I'm sympathetic and grateful that you
> overcame your concerns.  I was in the same place on YANG not
> too long ago, and I still have a ways to go, though I now think
> I see some of its promise.
> 
> But I don't think I created a multicast issue on github?  I just
> noticed a few nits while reading and sent a pull request, nothing
> really substantial yet.

MW: Sorry, that might have just been a response to an issue or PR somewhere, I saw an email flying by, that's all...


> </jh>
> 
>    But now I'll be brave  :)   I'll go ahead and ask: how exactly is this YANG proposal more than just a syntax change?  What would it give us?
>    (I understand that YANG can be automatically parsed / checked by some tools, but... what does THAT give us?)
> 
> <jh>
> Syntax plus tool support is the only difference between machine code
> and <your favorite programming language>, so even if that's the only
> thing we got, it's not to be sneezed at.  (And there is a lot of room
> for growth here, but there are already tools that can generate API
> header code from yang, e.g:
> https://wiki.onosproject.org/display/ONOS/YANG+Tools )
> 
> But I'm actually pushing from the other direction; my understanding
> of the current docs is that taps-arch is a high level design and goals
> document, and taps-interface (and taps-minset) make an attempt to
> lay out the concrete implementation details that would make taps-arch a
> reality, if an implementation covers them.
> 
> My claim here is twofold:
> - that taps-interface as it stands today is another high level design
>  document, which will have a necessarily fuzzy mapping to any actual
>  implementation.
> - that taps-interface is _really_ _close_ to laying out the concrete
>  implementation details in a non-fuzzy way that can be directly used
>  by implementors, so I'm suggesting that taking that extra step is
>  highly valuable.
> 
> On the question of benefits:  I'll lay out some of the ones
> that seem important to me, but I'll first say that in theory,
> these benefits could be realized by any concrete configuration
> format. The benefit of YANG specifically comes from tool
> support and the confidence from existing work that make it clear
> it's a reasonable format for networking configuration.
> 
> Basically, because there's so much YANG work already done for
> networking, using YANG lets us leverage some of that work in a way
> other options don't.
> 
> In particular, there are a bunch of networking-specific concepts
> that are already defined in detail. For example, the ipv6-address
> type has a complicated regex that many implementors are likely to
> get wrong if they try to roll their own (at least, I've certainly
> done so, and seen it a bunch of times):
> https://tools.ietf.org/html/rfc6991#page-19
> 
> But by making the obvious choice of using yang tools to parse yang
> stuff, implementors automatically get checking against that 
> (normative!) regex for free without having to notice and check it
> themselves.
> 
> There's other side benefits, like that interfaces are themselves
> explicitly defined (https://tools.ietf.org/html/rfc8343#section-5),
> and so where things like interface types might be used, the past
> and future work of people who formalize and extend the set of
> interface types gets automatically imported by referencing the
> normative yang definition for network interfaces.
> 
> But to list a few of the specific benefits from having an explicit
> config format:
> 
> - cross-platform portability:
> If I've got a program using a taps api that talks to some service,
> and now I want to write a new program in a different language to talk
> to that service, I can export the config and load it in my new
> program (even in a new language), and I can be reasonably sure
> it'll form the same kind of connection.
> 
> Although it's possible to make it work anyway as long as the APIs
> have a 1-to-1 mapping, normalizing on a config file format instead
> of a list of features seems to me like it'll save me perhaps up to a
> day or so of effort each time I have to do this, which when multiplied
> by all the implementors in the world over the next decade or 2, starts
> to add up.
> 
> - testability:
> Again, this mostly saves time, but by having a defined input format,
> it's possible for different implementations to use the same suite of
> test configuration files to verify the same interpretation of their
> contents.  If each implementation has its own way of configuring the
> features, it's not impossible to design a suite that can test them,
> but it's vastly harder.
> 
> - completeness:
> One of the points of confusion I had with taps-interface was that the
> Local/RemoteEndpoints seemed both critical to an implementation and
> very underspecified.  Although it's possible to address that by raising
> concerns specifically about the Local/Remote Endpoints, I'm not sure
> there aren't other underspecified areas of the taps-interface draft.
> 
> I expect that a reference implementation based on parsing a config
> format would uncover all such underspecified areas of configuration,
> if the config format examples are used to describe all the supported
> use cases.
> 
> (So part of my goal with this proposal is to solve this problem in
> the general case, which implies that it'll also be solved for the
> specific cases of Local/Remote Endpoints, though of course the
> details for each instance of incompleteness are separate topics.)
> 
> There might be some other benefits, but I'll stop there, hoping the
> point is sufficiently clear.
> </jh>

MW:  Absolutely, yes - some very good arguments here.
The "common config format" argument in particular got me excited!


>    Also, I actually see 3 separable things being proposed here:
> 
>    1) the YANG model
> <jh>
> I'd phrase the current status of the proposal as an in-principle
> "use a YANG model", rather than "use this specific YANG model".
> 
> The current draft is kind of a throw-away example proof of concept,
> which is certainly very incomplete, and some of my reading yesterday
> suggests that it's actually not very well structured either.  I've
> probably already made a fool of myself to any actual YANG experts,
> that ever try to read it, but such are the risks of posting public
> comments... :)
> </jh>
> 
>    2) multicast support  (I find your conclusion that not much needs to change interesting!  Though the example you're giving (joining an SSM channel) is only a part of what we'd need, as you also say...)
> <jh>
> Fair point, this really is a separate topic.  I brought it up
> really only because it's a motivating factor in my participation
> here, not because it's a primary factor for taps in general.  Let's
> drop it for this thread, and I'll plan to raise it as a separate
> issue when the yang questions are settled and I've got something
> more thought out.
> </jh>

MW: To be clear, there has always been only one argument against multicast in TAPS, and that was: "it's complex, so let's deal with it later."
So I think we're all for it... we just didn't get to work on it.


>    3) applying preferences to addresses and port numbers  (which you seem to take for granted in your draft, but which I don't think is supported by our current document).
> 
> <jh>
> Yes, this is a case in point for my concerns about incompleteness
> on the Endpoint specifications.
> 
> I wasn't sure how to treat this, so I'm not surprised if I got it
> wrong.  I was sort of pattern-matching on the rest of what the spec
> does, plus guessing at intended meanings of this paragraph from
> https://tools.ietf.org/html/draft-ietf-taps-interface-02#section-5.1:
> 
>   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.
> 
> By the time I finished making the examples, I had noticed I was
> maybe doing it wrong, but I didn't want to bother fixing it unless
> people agree it's worth spending effort in this general direction, and
> I didn't want to hold off on opening the discussion.  Of course, it
> should be changed to match the consensus of the wg on what belongs
> here.
> </jh>
> 
>    Side note: unless I'm mistaken, this wouldn't fit our structure well: e.g. a port number would then be a Transport Property that has a certain value, but also has a preference, but currently we say that a Transport Property has "one of a set of data types", one of which is a Preference. Isn't that structure too limiting? Or am I missing something?
> 
> <jh>
> I'm not sure.  This is part of what I mean when I say I find the
> current taps-interface a little too loose.  I _think_ what I posted
> is a valid (though perhaps not optimal) interpretation of the current
> text.  I might be wrong about that, so I'd be grateful for a pointer
> to the text that prohibits this interpretation.

MW: Things have changed so much since the -02 version, including a re-organization of properties... and the latest version doesn't seem to pop up under the "editor's copy" link now, after the move.
Therefore, I don't want to point to some specific bit of the text now. Let's get back to this discussion later, on the basis of the next -interface draft version.


> But really, that's beside the point.  I'd be even more grateful for an
> alternate proposal that more closely matches the intended design for
> a taps API, with the same level of concreteness.

MW: I liked your proposal!  It just maybe calls for a change of what we have (rather than changing what you propose).


> </jh>
> 
>    I guess that 2) needs 3), but perhaps it's useful to see 2) and 3) as separate... maybe there are other use cases for 3) alone ?
> 
> <jh>
> Yes, I think so.  I think I understand an ultimate goal for taps to
> be "as an app designer, don't worry about which transport, just
> send the magic API to go discover one that works".
> 
> However, it seems to me in the interim that it'll be necessary
> to specify port numbers in order to interoperate with a lot of
> existing services, especially in cases like RTP (or a lot of
> other generalized UDP stuff), where there's not an explicit
> service-to-port mapping. (Also to interoperate with a lot of
> other deployed systems like firewalls.)
> 
> I have a few nebulous ideas about how explicit layering might be a
> good way to solve this, but I think in order to make the ideas sharp
> enough to evaluate, I thought I'd first try the easier task of making
> taps sharp enough that I can express the ideas as proposed changes
> to an existing well-formed concept.
> </jh>

MW: all of that makes sense to me, too.


>    IMO, all of these things are interesting, and would be good to discuss on site. However, I doubt that we can deal with them all in only 15 minutes  :-)
> 
> <jh>
> Fair point.
> 
> I propose during the taps meeting to check preliminary consensus about
> moving forward with a YANG model within taps, and if so whether to
> integrate, replace, or make a paired doc with the existing taps-interface.
> Separately, I'll encourage those interested and available to spend some
> time in offline clarifying discussion during the week prior.
> 
> Cheers,
> Jake
> </jh>

MW: IMO, making a paired doc seems like a good strategy.

Cheers,
Michael