Subject: [Detnet] What we need to get a BOF in November

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Tue, 16 Sep 2014 23:11:02 +0000

The deadline for application for a BOF is Sept 26.  At the IEEE meeting, last week, we talked about several things we might do for the BOF, including:

Pick one or two leaders.
Write some drafts.

In particular, it was felt we need a Problem Statement draft.  Here is a proposed outline.  Comments/suggestions welcome:

1. Goal of document
  - Describe the Deterministic Networking problem statement, with an eye to a BOF and consequent working group.
2. Fundamental problem statement
  Given:
   * A moderate-sized mixed Layer 2 / Layer 3 network composed of bridges, routers, and end stations;
   * One or more “critical flows,” consisting of unicast or multicast data flows;
   • The willingness of a network administrator and/or application programs to take steps to allocate network resources before transmitting a critical data flow (and to be told, “no” if the resources are not available); and
   * Suitable buffering, queuing, shaping, and scheduling facilities in the network nodes;
   Provide to those flows a Quality of Service that has one or more of the following characteristics:
   * Guaranteed minimum and maximum end-to-end latency; and
   * Arbitrarily low packet loss probability;
   With as few restrictions as possible with regard to:
   * Bandwidth of critical flows (must support critical flows totaling >= 75% of links’ bandwidth);
   * Bandwidth of non-critical flows (all bandwidth unused by critical flows must be available to best-effort traffic);
   * Any particular choice of L2 or L3 topology control or routing protocol; or
   * Any specific transport protocol.
3. Demonstrated user communitites
   • Audio and video studios
   * Automobiles and other vehicles
   * Factory floor, machinery control, process control
4. Demonstrated solutions and their limitations
   * IEC 62439-3 HSR/PRP
   * IEEE 802.1BA Audio Video Bridging
   * IEEE 802.1 Time-Sensitive Networking standards in progress
5. Potential avenues for exploration: Zero congestion loss
   * 802.1 credit-based shaper
   * 802.1 Cyclical Queuing and Forwarding
   * 802.1 Time-scheduled queues
   * Urgency Based Shaping
6. Potential avenues for exploration: Multiple paths
   * Various forms of Seamless Redundancy
   * The serial number problem: HSR/PRP vs. 802.1 vs Pseudowires vs various transport protocols
7. Potential avenues for exploration: data plane and packet identification
   * {VLAN, Destination MAC address}
   * IP 5-tuple
   * Other
8. Potential avenues for exploration: Control paradigms
   * Peer-to-peer protocols (along the lines of MSRP or RSVP)
   * Central controller (along the lines of SDN or PCE)
   * Connection to Operations (Application) Controllers
   * Mixed scenarios

— Norm

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 17 Sep 2014 01:47:04 +0000

Norm -

The intro the the document should touch upon the applications with a forward pointer.  It is important that the problems statement be a succinct as possible.

I'm not clear on what sections 4 and 5 are about.  Do any of the things in section 4 have anything to do with bridges and routers working together?

Section 5 (and perhaps section 4 – if these are technical solutions to the problem) can be used to offer a feel for what the point of all this is.  But the IETF is not going to standardize any specific behavior of any device internally.  The IETF (as far as specification goes defines "what goes on the wire", i.e.  the protocols between routers and recently the interactions of controllers with routers.  It will be controversial enough just to talk about bridges.

Note:  I think we can actually technically avoid direct interactions between routers by having the routers talk only to each other and having the router's chosen interface acting as a host on the bridged network.
Obviously this can also be done with controllers.

Sections 6, 7, 8 look fine!

It is fine to have separate presentations on the stuff in sections 4 and 5, but I would not dwell on these or go into short-comings other that how they relate to setting things up.  What I would emphasize is what's done peer to peer and what's done controller to device.

George

From: "Norman Finn (nfinn)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 16, 2014 7:11 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Detnet] What we need to get a BOF in November

Pick one or two leaders.
Write some drafts.

1. Goal of document

— Norm

---

From: Alia Atlas <[email-masked]>
Date: Wed, 17 Sep 2014 10:12:53 -0400

Norm,

Have you asked for an IAB BOF Shepherd?   I would recommend doing so.
A shepherd would be able to help you figure out how to scope the desired
BOF,
provide comments, and be able to answer questions when the BOF proposal is
discussed.  There is extremely limited time before the BOF requests are
discussed.

Regards,
Alia

On Tue, Sep 16, 2014 at 7:11 PM, Norman Finn (nfinn) <[email-masked]>
wrote:

>  The deadline for application for a BOF is Sept 26.  At the IEEE meeting,
> last week, we talked about several things we might do for the BOF,
> including:
>
>  Pick one or two leaders.
> Write some drafts.
>
>  In particular, it was felt we need a Problem Statement draft.  Here is a
> proposed outline.  Comments/suggestions welcome:
>
>  1. Goal of document
>    • The willingness of a network administrator and/or application
> programs to take steps to allocate network resources before transmitting a
> critical data flow (and to be told, “no” if the resources are not
> available); and
>    * Bandwidth of non-critical flows (all bandwidth unused by critical
> flows must be available to best-effort traffic);
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
>

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 17 Sep 2014 17:54:33 +0000

Thanks for the advice!  See some replies in-line.  Let’s collect some comments, and then we can revise the outline.

By the way — a comment of my own.  Somewhere (section 2?), we should mention the fact that some kind of high-precision time synchronization, although not a part of this group’s efforts to specify, can be assumed to be present, insofar as it is helpful to achieving our real goals.

— Norm

From: "George Swallow (swallow)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 16, 2014 at 18:47 PM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] What we need to get a BOF in November

Norm -

Agreed.

Well, everything in section 4 has to do with bridges, which are part of the solution.  Obviously, bridges are not routers.  But, as far as queuing, shaping, and scheduling are concerned, there is no fundamental difference between bridges and routers; that’s a major point, and one that makes the whole bridge+router story meaningful.  IMO, an awareness of existing solutions, their strengths and limitations, would be required knowledge for anyone who wants to work on the problem.

In the interest of document brevity, we might well replace section 4 with pointers to good summaries of the existing and in-progress L2 solutions.  A very similar argument applies, in L3->L2 direction, to the proposed section 8.  The bridging people have to get up to speed on RSVP and PCE, if they want to contribute in a meaningful way.  (But, see below.  You have a better suggestion than this for resolving this.)

This is an important point, and needs further discussion.  Let’s start:

Real-world experience shows that the low-level queuing/shaping/scheduling mechanisms used in the queues on each port (typically in hardware, but what is hard- and what is software, any more?) HAVE to be specified carefully in order to achieve absolute 0 congestion loss.  Any slop in your algorithm for transmitting critical packets, whether through implementation details or lack of specification rigor, becomes my obligation to provide extra buffers to handle the worst case, which in turn, forces me to be more aggressive in dumping them, and so-on down the line.  The interactions can be quite devious.  IMO, one (just one) of the reasons RSVP never took off is that, while the cost of establishing state in every router was clear, the benefits to be accrued were small in the absence of these low-level details.  Current users are finding that zero congestion loss makes that cost worthwhile.

If the IETF is uncomfortable with defining this, and frankly, I wouldn’t want to see two organizations working exactly the same problem, perhaps the way forward is to define the 802.1 queuing/shaping/scheduling standards as part of the IETF problem statement.  Part of the division of labor, if you will.  Section 5 becomes a given, instead of a probably avenue, and moves up towards or inside section 2.

Yes.  I think we’re saying the same thing, but I like your formulation better.

Of course, there may be no bridge between the two end station / routers.

I was worried about that being too much for one document.  Presumably, we’ll keep it short.

It is fine to have separate presentations on the stuff in sections 4 and 5, but I would not dwell on these or go into short-comings other that how they relate to setting things up.  What I would emphasize is what's done peer to peer and what's done controller to device

Given the teeny bit of discussion we’ve had so far, I’m inclined to separate those out as separate documents.  Love to hear from others on this subject.
.
George

Pick one or two leaders.
Write some drafts.

1. Goal of document

— Norm

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 17 Sep 2014 19:08:38 +0000

From whom do I acquire an IAB BOF Shepherd?  I see document shepherds on the IETF site, but …

— Norm

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 17, 2014 at 07:12 AM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] What we need to get a BOF in November

Norm,

Have you asked for an IAB BOF Shepherd?   I would recommend doing so.
A shepherd would be able to help you figure out how to scope the desired BOF,
provide comments, and be able to answer questions when the BOF proposal is
discussed.  There is extremely limited time before the BOF requests are discussed.

Regards,
Alia

On Tue, Sep 16, 2014 at 7:11 PM, Norman Finn (nfinn) <[email-masked]<mailto:[email-masked]>> wrote:
The deadline for application for a BOF is Sept 26.  At the IEEE meeting, last week, we talked about several things we might do for the BOF, including:

Pick one or two leaders.
Write some drafts.

1. Goal of document

— Norm

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

---

From: Alia Atlas <[email-masked]>
Date: Wed, 17 Sep 2014 15:11:48 -0400

Norm,

Take a read through
http://trac.tools.ietf.org/bof/trac/wiki/WikiStart
which was recently updated with this information.

Basically - you ask a relevant AD.

Alia

On Wed, Sep 17, 2014 at 3:08 PM, Norman Finn (nfinn) <[email-masked]>
wrote:

>   From: Alia Atlas <[email-masked]>
> To: Norman Finn <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>>  The deadline for application for a BOF is Sept 26.  At the IEEE
>> meeting, last week, we talked about several things we might do for the BOF,
>> including:
>>
>>  Pick one or two leaders.
>> Write some drafts.
>>
>>  In particular, it was felt we need a Problem Statement draft.  Here is
>> a proposed outline.  Comments/suggestions welcome:
>>
>>  1. Goal of document

---

From: Pat Thaler <[email-masked]>
Date: Wed, 17 Sep 2014 22:38:00 +0000

One important piece of information on that page is the deadline for November BOF requests which is very soon: 2359 UTC Friday, September 26, 2014.

Pat

From: detnet [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, September 17, 2014 12:12 PM
To: Norman Finn (nfinn)
Cc: [email-masked]
Subject: Re: [Detnet] What we need to get a BOF in November

Norm,

Take a read through

Alia

On Wed, Sep 17, 2014 at 3:08 PM, Norman Finn (nfinn) <[email-masked]<mailto:[email-masked]>> wrote:
From whom do I acquire an IAB BOF Shepherd?  I see document shepherds on the IETF site, but …

— Norm

Norm,

Regards,
Alia

Pick one or two leaders.
Write some drafts.

1. Goal of document

— Norm

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Sep 2014 23:31:16 +0000

Norm,

We also need to start working on the actual proposed charter text. That can be imho done in parallel to writing the other documents. 

Jouni

-- 
Jouni Korhonen
Broadcom

(Sent from my mobile..)

> "Norman Finn (nfinn)" <[email-masked]> kirjoitti 17.9.2014 kello 7.11:
>

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 17 Sep 2014 23:37:52 +0000

Can you write a first draft, Jouni?

— Norm

-----Original Message-----
From: Jouni Korhonen <[email-masked]>
Date: Wednesday, September 17, 2014 at 16:31 PM
To: Norman Finn <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Detnet] What we need to get a BOF in November

>Norm,
>
>We also need to start working on the actual proposed charter text. That
>can be imho done in parallel to writing the other documents.
>
>Jouni
>
>-- 
>Jouni Korhonen
>Broadcom
>
>(Sent from my mobile..)
>
>>meeting, last week, we talked about several things we might do for the
>>BOF, including:
>> 
>> Pick one or two leaders.
>> Write some drafts.
>> 
>>   - Describe the Deterministic Networking problem statement, with an
>>eye to a BOF and consequent working group.
>>programs to take steps to allocate network resources before transmitting
>>a critical data flow (and to be told, “no” if the resources are not
>>available); and
>>    * Bandwidth of critical flows (must support critical flows totaling
>>>= 75% of links’ bandwidth);

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 18 Sep 2014 06:43:38 +0000

Hello Norm and Jouni:

My suggestions:

A relevant example can be found in Homenet http://tools.ietf.org/wg/homenet/charters

We want a charter with deliverables that can be achieved in a reasonable period of time and does not spread too much over other WGs/areas (security, transport...)

Main components of the charter:

- In the scope of the work, I see campus networks such as factories, and SoHo networks such as a TV studio. I would exclude the WAN and the Service Provider space for the first round, even if we can think of extending to that space later. The considered network would be a mix or L2 routed fabric and L3 routed fabric.

- Deliverables for the first round could be/include :
  * an analysis of the requirements in a number of environments (3-4 drafts which would include process control, factory automation, planes and video studios)
  * a status of the work at IEEE with the general problem statement as perceived there, and the directions that is being taken
  * a generic format for flow identification that works across layers. A study of scoping, including the definition of Realm-Local scope and Admin-Local scope (pre RFC 7346) where for instance the deterministic technology is consistent over a Realm and achievable across technologies and layers over an Admin local scope
  * and a requirement draft for the definition of a PhB at the transport area.
  *  all informational track for the first round of chartering,

- Optional timeline/milestones: We can probably ship that to IESG within a year after the WG has formed. Work can start now

Recommendations for the BoF session:

- present all the work prior to opening the floor to question
- for the work already in progress, stay very high level, do not open to questions that could defocus the meeting or trouble the audience
- very clear gap analysis, what's missing, what needs to be done, constraints (e.g. L2/L3 interworking)
- no discussion of tech problem resolution. Rather, focus on charter text, edit it online till the room is happy.
- show activity and strong membership. Ideally we'd start some work beforehands
- do not frighten the audience - and the IAB - with liaison work. It might be sufficient (to start with) to have participant that follow with IEEE and IETF and can cross-report.

What do you think?

Cheers,

Pascal

> From: detnet [mailto:[email-masked]] On Behalf Of Norman Finn
> (nfinn)
> Sent: jeudi 18 septembre 2014 01:38
> To: Jouni Korhonen
> Cc: [email-masked]
> >> In particular, it was felt we need a Problem Statement draft.  Here
> >>is a proposed outline.  Comments/suggestions welcome:
> >>
> >> 1. Goal of document
> >>programs to take steps to allocate network resources before
> >>transmitting a critical data flow (and to be told, “no” if the
> >>resources are not available); and
> >>    * Bandwidth of non-critical flows (all bandwidth unused by
> >>critical flows must be available to best-effort traffic);
> >>    * Factory floor, machinery control, process control  4.
> >>Demonstrated solutions and their limitations
> >>    * IEC 62439-3 HSR/PRP
> >>    * IEEE 802.1 Time-Sensitive Networking standards in progress  5.
> >>Potential avenues for exploration: Zero congestion loss
> >>    * The serial number problem: HSR/PRP vs. 802.1 vs Pseudowires vs
> >>various transport protocols  7. Potential avenues for exploration:
> >>data plane and packet identification

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 22 Sep 2014 17:51:21 +0000

Sorry that I missed this.. I was on the road the rest of the week (and still am actually). Fortunately Pascal took the call already ;)

- Jouni

> From: Norman Finn (nfinn) [mailto:[email-masked]]
> Sent: Thursday, September 18, 2014 2:38 AM
> To: Jouni Korhonen
> Cc: [email-masked]

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 24 Sep 2014 00:00:10 +0000

I sent some markups.  Please offer your suggestions!

— Norm

-----Original Message-----
From: Jouni Korhonen <[email-masked]>
Date: Monday, September 22, 2014 at 07:51 AM
To: Norman Finn <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [Detnet] What we need to get a BOF in November

>Sorry that I missed this.. I was on the road the rest of the week (and
>still am actually). Fortunately Pascal took the call already ;)
>
>- Jouni
>