Subject: [Stackevo] Stack Evolution: looking back, looking forward

From: Brian Trammell <[email-masked]>
Date: Wed, 1 Feb 2017 13:06:45 +0100

Greetings, all,

First off, thanks to all for your work on the Stack Evolution Program. Looking back, I think the discussions we've had, the workshops we've put together, have a done a lot to keep "the A in IAB". Within the IETF, there are several activities afoot to break up the logjam in the transport stack we worked to draw attention to in 2014. Not all of the activities we've kicked off have been successful, but I think we-the-community are in a better position now than then, and I'd like to think that we-the-program have had something to do with that.

I'd like to think about where we want to go next, partially in the context of a long-overdue IAB review of the program. Looking over our list of current active work we have three things on the list:

(1) Discussion of principles for making new protocols within the IP stack deployable, following in part on RFC 5218 “What Makes for a Successful Protocol”

This has turned into draft-iab-transition-principles, which is now in community review, so we can I think tick this off as done for program purposes.

(2) Discussion of principles for the use of encapsulation at various layers within the protocol stack. UDP-based encapsulations are not only useful for evolution above the IP layer, but in many tunneling contexts as well. The probable commonalities among all these applications of encapsulation might be useful in simplifying their implementation, deployment, and use.

AFAICT we haven't moved forward on this one very much, even though the situation continues to develop on its own in multiple areas of the IETF -- e.g. the QUIC working group is designing its own UDP encapsulation, after a fashion, integrated with the transport protocol itself. Is there still something to do here?

(3) Architectural guidance on the interoperability of protocol stacks for use in constrained devices, focusing on issues related to mutually incompatible interactions among application, transport, network, and link layer protocols.

Same question, though as far as I know most of the continuing developments here are *outside* the IETF.

If there's neither urgency nor energy in dealing with the latter two items, we can certainly free up the space on our current items list, which would leave the question: are there other issues we as a program should be engaging with?

Thanks, cheers,

Brian (program lead hat)

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Feb 2017 08:47:48 -0800

Hi Brian,

I promised many moons ago to take the "Slouching toward Catanets" slide
deck and move it toward a draft.  That got pushed down the stack by too
many things, but I'd like to move it back up and have the program take it
on.  As an architectural challenge, the drift toward networks that must
have translating gateways is one that we need to understand.  Some of that
relates to the constrained network topic you list below, and some of it is
more general.   The heartening news on the constrained network front is
that some of the links are getting a little less constrained, which may
move some of the complexity out of the gateways again.  The increased
packet size in Bluetooth 5, for example, simplifies the stitching needed to
create IP packets.

If you don't see a draft from me on Slouching within two weeks, please
start nagging.

best,

Ted

On Wed, Feb 1, 2017 at 4:06 AM, Brian Trammell <[email-masked]> wrote:

> Greetings, all,
>
> First off, thanks to all for your work on the Stack Evolution Program.
> Looking back, I think the discussions we've had, the workshops we've put
> together, have a done a lot to keep "the A in IAB". Within the IETF, there
> are several activities afoot to break up the logjam in the transport stack
> we worked to draw attention to in 2014. Not all of the activities we've
> kicked off have been successful, but I think we-the-community are in a
> better position now than then, and I'd like to think that we-the-program
> have had something to do with that.
>
> I'd like to think about where we want to go next, partially in the context
> of a long-overdue IAB review of the program. Looking over our list of
> current active work we have three things on the list:
>
>
> (1) Discussion of principles for making new protocols within the IP stack
> deployable, following in part on RFC 5218 “What Makes for a Successful
> Protocol”
>
> This has turned into draft-iab-transition-principles, which is now in
> community review, so we can I think tick this off as done for program
> purposes.
>
>
> (2) Discussion of principles for the use of encapsulation at various
> layers within the protocol stack. UDP-based encapsulations are not only
> useful for evolution above the IP layer, but in many tunneling contexts as
> well. The probable commonalities among all these applications of
> encapsulation might be useful in simplifying their implementation,
> deployment, and use.
>
> AFAICT we haven't moved forward on this one very much, even though the
> situation continues to develop on its own in multiple areas of the IETF --
> e.g. the QUIC working group is designing its own UDP encapsulation, after a
> fashion, integrated with the transport protocol itself. Is there still
> something to do here?
>
>
> (3) Architectural guidance on the interoperability of protocol stacks for
> use in constrained devices, focusing on issues related to mutually
> incompatible interactions among application, transport, network, and link
> layer protocols.
>
> If there's neither urgency nor energy in dealing with the latter two
> items, we can certainly free up the space on our current items list, which
> would leave the question: are there other issues we as a program should be
> engaging with?
>
> Thanks, cheers,
>
> Brian (program lead hat)
>
> _______________________________________________
> Stackevo mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/stackevo
>
>

---

From: "Black, David" <[email-masked]>
Date: Tue, 14 Feb 2017 23:21:46 +0000

Brian,

On item (2), I think your note may have undersold Stackevo's contribution.

> (2) Discussion of principles for the use of encapsulation at various layers within
> the protocol stack. UDP-based encapsulations are not only useful for evolution
> above the IP layer, but in many tunneling contexts as well. The probable
> commonalities among all these applications of encapsulation might be useful in
> simplifying their implementation, deployment, and use.
> 
> situation continues to develop on its own in multiple areas of the IETF -- e.g. the
> QUIC working group is designing its own UDP encapsulation, after a fashion,
> integrated with the transport protocol itself. Is there still something to do here?

I think Stackevo can claim some credit here, perhaps indirect, for the additional UDP-encapsulation-motivated material in the updated UDP guidelines - draft-ietf-tsvwg-rfc5405bis-19, which should be out as an RFC any day now, start with Section 3.1.11.   IMHO, the importance that Stackevo placed on UDP as a new neck-of-the-hourglass protocol was among the things that lead to adding material on UDP encapsulation and tunnels ... and I write that as one of the people who ensured that this new material was added.

I don't think there's more to do here now.  Speaking for myself ;-), having survived the MPLS/UDP and GRE/UDP experiences (and yes ... "survived" is an entirely appropriate word), I think the next step is to see how well the community deals with these 3 RFCs, i.e., 5405bis on guidelines, MPLS/UDP and GRE/UDP as worked examples, before doing anything more.  FWIW, publication of the GRE/UDP RFC is also imminent.

Thanks, --David

> -----Original Message-----
> From: Stackevo [mailto:[email-masked]] On Behalf Of Brian Trammell
> Sent: Wednesday, February 01, 2017 7:07 AM
> To: Stackevo
> Subject: [Stackevo] Stack Evolution: looking back, looking forward
> 
> Greetings, all,
> 
> First off, thanks to all for your work on the Stack Evolution Program. Looking back,
> I think the discussions we've had, the workshops we've put together, have a
> done a lot to keep "the A in IAB". Within the IETF, there are several activities
> afoot to break up the logjam in the transport stack we worked to draw attention
> to in 2014. Not all of the activities we've kicked off have been successful, but I
> think we-the-community are in a better position now than then, and I'd like to
> think that we-the-program have had something to do with that.
> 
> I'd like to think about where we want to go next, partially in the context of a long-
> overdue IAB review of the program. Looking over our list of current active work
> we have three things on the list:
> 
> 
> deployable, following in part on RFC 5218 “What Makes for a Successful Protocol”
> 
> This has turned into draft-iab-transition-principles, which is now in community
> review, so we can I think tick this off as done for program purposes.
> 
> 
> (2) Discussion of principles for the use of encapsulation at various layers within
> the protocol stack. UDP-based encapsulations are not only useful for evolution
> above the IP layer, but in many tunneling contexts as well. The probable
> commonalities among all these applications of encapsulation might be useful in
> simplifying their implementation, deployment, and use.
> 
> situation continues to develop on its own in multiple areas of the IETF -- e.g. the
> QUIC working group is designing its own UDP encapsulation, after a fashion,
> integrated with the transport protocol itself. Is there still something to do here?
> 
> 
> (3) Architectural guidance on the interoperability of protocol stacks for use in
> constrained devices, focusing on issues related to mutually incompatible
> interactions among application, transport, network, and link layer protocols.
> 
> If there's neither urgency nor energy in dealing with the latter two items, we can
> certainly free up the space on our current items list, which would leave the
> question: are there other issues we as a program should be engaging with?
> 
> Thanks, cheers,
> 
> Brian (program lead hat)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Feb 2017 11:59:46 -0600

Ted,

> If you don't see a draft from me on Slouching within two weeks, please

I will be pleased to see this happen.

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 16 Feb 2017 12:06:30 -0600

Just to add to what David said ...

On Tue, Feb 14, 2017 at 5:21 PM, Black, David <[email-masked]> wrote:

> layers within
> I think Stackevo can claim some credit here, perhaps indirect, for the
> additional UDP-encapsulation-motivated material in the updated UDP
> guidelines - draft-ietf-tsvwg-rfc5405bis-19, which should be out as an
> RFC any day now, start with Section 3.1.11.   IMHO, the importance that
> Stackevo placed on UDP as a new neck-of-the-hourglass protocol was among
> the things that lead to adding material on UDP encapsulation and tunnels
> ... and I write that as one of the people who ensured that this new
> material was added.
>
> I don't think there's more to do here now.  Speaking for myself ;-),
> having survived the MPLS/UDP and GRE/UDP experiences (and yes ...
> "survived" is an entirely appropriate word), I think the next step is to
> see how well the community deals with these 3 RFCs, i.e., 5405bis on
> guidelines, MPLS/UDP and GRE/UDP as worked examples, before doing anything
> more.  FWIW, publication of the GRE/UDP RFC is also imminent.

I agree with David here, that STACKEVO has been influential on the
UDP-ization of the protocol stack, and it's likely that he's right about
not having much more to do in that space, at least until QUIC is a bit
further down the road.

But I do wonder if there's more to do on the encapsulation topic in
general. Brian and David know that we've been in discussions about the
In-Situ OAM work this week, and there are a lot of questions that I'm
asking about the effects and risks of encapsulation more broadly than "if
you jack your protocol up on UDP and launch it, the packets could go
anywhere". Perhaps an intentional deep dive on that would be helpful.

Thanks,

Spencer

---

From: "Black, David" <[email-masked]>
Date: Thu, 16 Feb 2017 19:41:58 +0000

>  But I do wonder if there's more to do on the encapsulation topic in general. Brian and David know that
> we've been in discussions about the In-Situ OAM work this week, and there are a lot of questions that
> I'm asking about the effects and risks of encapsulation more broadly than "if you jack your protocol up
> on UDP and launch it, the packets could go anywhere". Perhaps an intentional deep dive on that would be helpful.

Joe Touch’s intarea-tunnels draft (unfortunately expired at the moment, but definitely not abandoned), is highly recommended reading on this topic:

https://datatracker.ietf.org/doc/draft-ietf-intarea-tunnels/

In particular, embedding this first sentence of section 3.1 (and its implications listed in section 3.5) into the IETF’s community’s collective conscience will go a long way:

A tunnel can be modeled as a link in another network

This draft’s been around for a while, and has been basically a 1-person effort by Joe.   Perhaps Stackevo could help with text drafting/editing and focusing the scope to get this draft completed and published sooner rather than later.

Thanks, --David

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 1:06 PM
To: Black, David
Cc: Brian Trammell; Stackevo
Subject: Re: [Stackevo] Stack Evolution: looking back, looking forward

On Tue, Feb 14, 2017 at 5:21 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Brian,

I agree with David here, that STACKEVO has been influential on the UDP-ization of the protocol stack, and it's likely that he's right about not having much more to do in that space, at least until QUIC is a bit further down the road.

But I do wonder if there's more to do on the encapsulation topic in general. Brian and David know that we've been in discussions about the In-Situ OAM work this week, and there are a lot of questions that I'm asking about the effects and risks of encapsulation more broadly than "if you jack your protocol up on UDP and launch it, the packets could go anywhere". Perhaps an intentional deep dive on that would be helpful.

Thanks,

Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 22 Feb 2017 21:54:37 +0100

hi David,

> On 16 Feb 2017, at 20:41, Black, David <[email-masked]> wrote:
> 

Have read over the document... and that seems like a good idea. Do you happen to know what Joe's plan for this is going forward? Shall we invite him to solicit co-authors among the program to continue working on this for publication on the IAB stream?

Cheers,

Brian

---

From: Dave Thaler <[email-masked]>
Date: Wed, 22 Feb 2017 21:12:02 +0000

It's an intarea document, so it's IETF stream.
That's stronger than the IAB stream so I would not try to suggest it be in the IAB stream.

Dave

-----Original Message-----
From: Stackevo [mailto:[email-masked]] On Behalf Of Brian Trammell (IETF)
Sent: Wednesday, February 22, 2017 12:55 PM
To: Black, David <[email-masked]>
Cc: Stackevo <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Subject: Re: [Stackevo] Stack Evolution: looking back, looking forward

hi David,

> > general. Brian and David know that we've been in discussions about 
> > the In-Situ OAM work this week, and there are a lot of questions 
> > that I'm asking about the effects and risks of encapsulation more broadly than "if you jack your protocol up on UDP and launch it, the packets could go anywhere". Perhaps an intentional deep dive on that would be helpful.
> 

Cheers,

Brian

> > layers within the protocol stack. UDP-based encapsulations are not 
> > only useful for evolution above the IP layer, but in many tunneling 
> > contexts as well. The probable commonalities among all these 
> > applications of encapsulation might be useful in simplifying their implementation, deployment, and use.
> >
> > AFAICT we haven't moved forward on this one very much, even though 
> > the situation continues to develop on its own in multiple areas of 
> > the IETF -- e.g. the QUIC working group is designing its own UDP 
> > encapsulation, after a fashion, integrated with the transport protocol itself. Is there still something to do here?
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Feb 2017 21:18:36 +0000

Hi Brian,

> On Feb 22, 2017, at 3:54 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> hi David,
> 

It is already a WG document in the intarea working group. It has been around for a *very long* time. I was handling this document as the chair of the intarea wg before I became AD. I agree that the document is useful but I think Joe T. and Mark T. are extremely constrained on time and this led to glacial progress even after repeated reminders(~2 years per rev: WG -00 was published in 2010). I think the best we can do is to offer help to the authors to move this forward instead of moving it into the IAB stream.

Thanks
Suresh

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 22 Feb 2017 16:02:02 -0600

FWIW,

On Wed, Feb 22, 2017 at 3:18 PM, Suresh Krishnan <
[email-masked]> wrote:

> general. Brian and David know that
> on UDP and launch it, the packets could go anywhere". Perhaps an
> intentional deep dive on that would be helpful.
>
>
> Joe Touch’s intarea-tunnels draft (unfortunately expired at the moment,
> but definitely not abandoned), is highly recommended reading on this topic:
>
> In particular, embedding this first sentence of section 3.1 (and its
> implications listed in section 3.5) into the IETF’s community’s collective
> conscience will go a long way:
>
> This draft’s been around for a while, and has been basically a 1-person
> effort by Joe.   Perhaps Stackevo could help with text drafting/editing and
> focusing the scope to get this draft completed and published sooner rather
> than later.
>
>
> Have read over the document... and that seems like a good idea. Do you
> happen to know what Joe's plan for this is going forward? Shall we invite
> him to solicit co-authors among the program to continue working on this for
> publication on the IAB stream?
>
>
> It is already a WG document in the intarea working group. It has been
> around for a *very long* time. I was handling this document as the chair of
> the intarea wg before I became AD. I agree that the document is useful but
> I think Joe T. and Mark T. are extremely constrained on time and this led
> to glacial progress even after repeated reminders(~2 years per rev: WG -00
> was published in 2010). I think the best we can do is to offer help to the
> authors to move this forward instead of moving it into the IAB stream.
>

Agreed on this document mattering, and agreed on offering to help publish
it in the IETF stream.

Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 22 Feb 2017 23:44:11 +0100

hi Spencer, Suresh, all,

Ah, right, -intarea is a WG. Nothing to see here. Agreed, no need to publish in the IAB stream.

All right then. Who has cycles to help get another rev going?

Cheers,

Brian

> On 22 Feb 2017, at 23:02, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> FWIW,
> 
> On Wed, Feb 22, 2017 at 3:18 PM, Suresh Krishnan <[email-masked]> wrote:
> Hi Brian,
> 
> Agreed on this document mattering, and agreed on offering to help publish it in the IETF stream.
> 
> Spencer