Subject: [Detnet] Alia Atlas' Block on charter-ietf-detnet-00-00: (with BLOCK and COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Wed, 16 Sep 2015 07:45:17 -0700

Alia Atlas has entered the following ballot position for
charter-ietf-detnet-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-detnet/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I would like to see restrictions and assumptions in the charter about the
intended
reach of this technology.  I would be quite concerned if it is expected
to go across the
general Internet - due to the hardware requirements, for instance - but I
see no indications
of expected distance or scope.

Sorry for the very lateness of this concern - though I have mentioned it
before - but I'm
on vacation and this charter showed up on the telechat after I was
already out.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Here are my more specific comments on the charter.

1)	I am concerned about the “encapsulation of frames”.  This seems to
imply that yet another data-plane encapsulation could be pictured.  The
description of data plane as “This work will document a data plane method
of flow
identification and packet forwarding over Layer 3.”  doesn't clarify
this.  Could  “Candidate Layer 3 data plane technologies that may be
used, without modification, include: IPv4, IPv6, MPLS” be updated to “The
only candidate Layer 3 data plane technologies that may be used are IPv6
and MPLS; the selected technology must be used without modification.”?

This is also asking that IPv4 be taken off the table as a candidate.  I
am suggesting this for three reasons.  First, pragmatically IPv6 has a
flow label that can easily allow flow identification.  Second, if you
consider sunset4 – we as the IETF – are trying to move towards IPv6.   
Do tell me if and why you think this is a bad idea.

How does an L2 AVB packet get carried by a Router?  Is the idea to just
encapsulate it in an MPLS or IP packet?  Where is this being defined or
described?

2)	I am concerned about the lack of scalability considerations for the
deterministic data paths.  There have been several other efforts –
starting with RSVP – to reserve buffers and resources.  This doesn’t
scale to Internet-sized flows.  I’d like to see some words in the charter
indicating what the approximate design center is.  This can affect the
scaling in the hardware, the size of fields, and so on.

3)	As I mentioned in my quick Block, we need to nail down how to clarify
and constrain the scope of this technology to a reasonable domain that
can be under single control and have the needed hardware and software
functionality.  The current suggested text of “The Working Group will
focus on solutions for constrained environments,    such as those that
may be deployed in a single administrative domains.”  is not quite strong
enough; for instance, that wording is frequently used with technology
that is just getting started to bound the work effort.  This is
specifically not expected to be seen in the general Internet but is
constrained much more to purpose-built networks.

A related question is what constraints the timing synchronization imposes
on the scope of the network?  I don’t have a lot of background knowledge
here and the problem-statement claims that it is “done work” but AVB is
strongly dependent on synchronized time across its L2 domain. 

4)	Although the charter says “The work will cover the characterization of
flows, the
encapsulation of frames, the required forwarding behaviors, as well as
the state that may need to be established in intermediate nodes; it will
not include end-to-end considerations such as transport protocols,
modification of OAM, L3 forwarding and encapsulations, or control plane
protocols.”, the interactions to other WGs seems to clearly indicate that
DetNet would be selecting particular control protocols in the
architecture and providing requirements to the associated WGs.  I think
it would be better to clarify that DetNet will discuss and select
appropriate existing control plane protocols and provide requirements as
necessary to go to the appropriate WGs.  If, instead, the intent is to
focus on the centralized controller approach (as suggested in
draft-finn-detnet-problem-statement) – the I’d strongly suggest
clarifying that.   The urge to start work on control plane protocols and
claim that a favorite protocol is the right solution can seriously derail
a WG.  This was an issue with both SFC and NVO3.   Because of the
interactions described in this charter, it looks like there is a large
open door towards requirements and picking control plane protocols.

5)	I don’t see anything in the charter that indicates whether only
unicast flows are being considered or whether multicast are also to be
considered.  Can you please clarify in the charter?   I certainly see in
Sec 3 of draft-finn-detnet-problem-statement-03 that the “critical packet
flows that can be unicast or multicast”.

---

From: Lou Berger <[email-masked]>
Date: Wed, 16 Sep 2015 12:32:26 -0400

Hi Alia,
    see below.

> https://datatracker.ietf.org/doc/charter-ietf-detnet/
 The text to some degree is patterned after the other clear example of a
routing area technology that only operates within a constrained scope,
i.e., MPLS.  In this case, the charter doesn't spell out MPLS
applicability, but it's covered elsewhere both implicitly and explicitly. 

To address your comment we have a couple of changes: (See
http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter)
1) "The working group will document which deployment environments and
types of topologies are within (or outside) the scope of the DetNet
<http://trac.tools.ietf.org/bof/trac/wiki/DetNet> architecture."
2) "Problem statement and (constrained) deployment environments "

If you think it makes sense we can make 2 our first formal deliverable
to ensure that the work is head in the right direction.  I don't think
this will be too much of a diversion as I think there is general
agreement on this topic.

If you'd like to see/propose specific wording changes, that might help.

> imply that yet another data-plane encapsulation could be pictured. 
Sorry frames = packets in ieee.  So all we're saying is that Ethernet
could be encapsulated in something else -- think L2VPN/PWEs.

Would changing the text to "data encapsulation" help?

>  The

To address other IESG comments, this text has been changed to:

Candidate Layer 3 data plane technologies that may be used, without
modification, include: IP and MPLS.

> consider sunset4 – we as the IETF – are trying to move towards IPv6.   
The other concern was that v6 would be done without (or as a second
class to v4).  I think at this stage of the market (as others have
said), if doing IP (vs just MPLS), we need both v4 and v6.

> encapsulate it in an MPLS or IP packet?
Those are both options.

>   Where is this being defined or
> described?
As part of this WG.  The current text says:

"Data plane: This work will document a data plane method of flow
identification and packet forwarding over Layer 3."

> scaling in the hardware, the size of fields, and so on.
This is the same point (or perhaps just answered) by your blocking
point, correct?

if not, we can certainly call out scale: e.g.,:

"Problem statement and (constrained) deployment scale and environments "

> constrained much more to purpose-built networks.

See discussion above.

> strongly dependent on synchronized time across its L2 domain. 

Thankfully we have some really good work on this already that can be
leveraged.  I'm thinking draft-ietf-mpls-residence-time which is
applicable to MPLS-TE.  That draft refers to rfc5905 which may also have
some applicability, but this is for the WG to discuss.

> architecture and providing requirements to the associated WGs.
The selection and extension of control plane protocols are beyond the
proposed scope of the WG. Work is limited to YANG data models.  The
information represented is expected to be useful for control planes, but
this isn't a WG deliverable.

>   I think

> considered.
Both unicast and multicast are in scope (at least as far as I understand
it).

>   Can you please clarify in the charter? 

how about:
 s/the encapsulation of frames/unicast and multicast data encapsulation

>   I certainly see in

Thank you for the comments,
Lou

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 17 Sep 2015 17:50:00 -0400

All,

Alia, Deborah, Pat and I, discussed this offline and tweaked/clarified
the text to address Alia's concerns. The new proposed text is on the
wiki (http://trac.tools.ietf.org/bof/trac/wiki/DetNetDraftCharter) and
follows:

Draft DetNet Charter

The Deterministic Networking (DetNet) Working Group focuses on
deterministic data paths that operate over Layer 2 bridged and Layer 3
routed segments, where such paths can provide bounds on latency, loss,
and packet delay variation (jitter), and high reliability. The Working
Group addresses Layer 3 aspects in support of applications requiring
deterministic networking. The Working Group collaborates with IEEE802.1
Time Sensitive Networking (TSN), which is responsible for Layer 2
operations, to define a common architecture for both Layer 2 and Layer
3. Example applications for deterministic networks include professional
and home audio/video, multimedia in transportation, engine control
systems, and other general industrial and vehicular applications being
consider by the IEEE 802.1 TSN Task Group.

The Working Group will initially focus on solutions for networks that
are under a single administrative control or within a closed group of
administrative control; these include not only campus-wide networks but
also can include private WANs. The DetNet WG will not spend energy on
solutions for large groups of domains such as the Internet.

The Working Group will specify an overall architecture that encompasses
the data plane, OAM (Operations, Administration, and Maintenance), time
synchronization, management, control, and security aspects which are
required to enable a multi-hop path, and forwarding along the path, with
the deterministic properties of controlled latency, low packet loss, low
packet delay variation, and high reliability. The work applies to
point-to-point (unicast) and point-to-multipoint (multicast) flows which
can be characterized in a manner that allows the network to 1) reserve
the appropriate resources for the flows in advance, and 2) release/reuse
the resources when they are no longer required. The work covers the
characterization of flows, the encapsulation of frames, the required
forwarding behaviors, as well as the state that may need to be
established in intermediate nodes. Candidate Layer 3 data plane
technologies that may be used, without modification, include: IP and
MPLS.

The working group will document which deployment environments and types
of topologies are within (or outside) the scope of the DetNet
architecture. This work focuses on the data plane aspects and is
independent from any path setup protocol or mechanism. The data plane
will be compatible with the work done in IEEE802.1 TSN.

The Working Group's scope explicitly excludes modifications of transport
protocols, OAM, Layer 3 forwarding, encapsulations, and control plane
protocols.

DetNet is chartered to work in the following areas:

    Overall architecture: This work encompasses the data plane, OAM,
    time synchronization, management, control, and security aspects. 

    Data plane: This work will document how to use IP and/or MPLS to
    support a data plane method of flow identification and packet
    forwarding over Layer 3. 

    Data flow information model: This work will identify the information
    needed for flow establishment and control and be used by a
    reservation protocol or by YANG data models. The work will be
    independent from the protocol(s) used to control the flows
    (e.g. YANG+NETCONF/RESTCONF, PCEP or GMPLS). 

    Identification of additional YANG models: This work will document
    device and link capabilities (feature support) and resources
    (e.g. buffers, bandwidth) for use in device configuration and status
    reporting. Such information may also be used when advertising the
    deterministic network elements to a control plane. Control plane
    related information will be independent from the protocol(s) which
    may be used to advertise this information (e.g. IS-IS or GMPLS
    extensions). Any new YANG models will be coordinated with the
    Working Groups that define any augmented base models. 

    As needed, problem statement: This effort will establish the
    deployment environment and deterministic network requirements. 

    As needed, vertical requirements: This effort will detail the
    requirements for deterministic networks in various industries, for
    example, professional audio, electrical utilities, building
    automation systems, wireless for industrial applications. 

    To investigate whether existing data plane encryption mechanisms can
    be applied, possibly opportunistically, to improve security and
    privacy. 

The WG coordinates with other relevant IETF Working Groups, including
CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, and 6TisSCH. As the work
progresses, requirements may be provided to the responsible Working
Group, e.g. PCE, TEAS, and CCAMP, with DetNet acting as a focal point to
maintain the consistency of the overall architecture. The WG will liaise
with appropriate groups in IEEE and other Standards Development
Organizations (SDOs).

WG deliverables include:

    As standard track or informational RFCs

    Overall architecture
    Data plane specification
    Data flow information model
    YANG model augmentations

WG sustaining/informational documents may include:

    These documents may not necessarily be published, but may be
    maintained in a draft form or on a collaborative Working Group wiki
    to support the efforts of the Working Group and help new comers:

    Problem statement and (constrained) deployment environments
    User-driven use cases

Send comments to the list.

Thanks!