Re: WG Review: Deterministic Networking (detnet)

"Andrew G. Malis" <agmalis@gmail.com> Fri, 18 September 2015 16:53 UTC

Return-Path: <agmalis@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61CC1A6F1E; Fri, 18 Sep 2015 09:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKBo7V4YAfnL; Fri, 18 Sep 2015 09:53:04 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8BC51A6EFE; Fri, 18 Sep 2015 09:53:03 -0700 (PDT)
Received: by wiclk2 with SMTP id lk2so38590703wic.1; Fri, 18 Sep 2015 09:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kmnod1YpD8XJmrQ6mXDqnY+PYErk/tMishLJyVg5nAg=; b=NBtcD4ACRWwIzPUV+XwHeCOz8InshK/jn9CMvN2oGeqkFCcLaAezIynKUktlbhXTz4 NC16mREEv9DRTBxwHWArlXUU8IwV98sWVbX6Ge9mqV3CQE4vwIQ6CowoW0YTg7nfoqoF fOBaoSbOK8ZetnqbV5bU38xE4b3C5ATiM5tQReLYlbDCFSYowSAhaOfPS5BHduXsrYxy 8LgieFsl40FGtKR13W15YFd3wK+6gLFF7h+c+O3mHuVa8Gi6nybYJAlfwNQuzmyUKtYx 6r9SfjL/wryu49wfeRm6BKmA8qFqPG2Ggu1FapVsr7MPG7okev3X2ovDgWBNhXYOTzyu DGeA==
X-Received: by 10.194.117.133 with SMTP id ke5mr8497540wjb.116.1442595182372; Fri, 18 Sep 2015 09:53:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.9.212 with HTTP; Fri, 18 Sep 2015 09:52:42 -0700 (PDT)
In-Reply-To: <019c01d0f22e$d190ce90$74b26bb0$@olddog.co.uk>
References: <20150918145101.26656.63284.idtracker@ietfa.amsl.com> <018f01d0f228$095b0cc0$1c112640$@olddog.co.uk> <55FC332B.7000409@labn.net> <019c01d0f22e$d190ce90$74b26bb0$@olddog.co.uk>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Fri, 18 Sep 2015 12:52:42 -0400
Message-ID: <CAA=duU0Fi+U2_f0i=4ktW3cjmFoxinXS5jJoSfjhDd9bucKhJA@mail.gmail.com>
Subject: Re: WG Review: Deterministic Networking (detnet)
To: Adrian Farrel <adrian@olddog.co.uk>
Content-Type: multipart/alternative; boundary="001a1130d396666e9a0520085dcd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/dO8oGuKkfhFQ2R0xIIDCsvmU7Ns>
Cc: detnet WG <detnet@ietf.org>, IETF Discussion <ietf@ietf.org>, IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2015 16:53:09 -0000

Adrian and Lou,

When I first read the draft charter, my immediate reaction was that the
scope of work would be deterministic IP and MPLS flows layered over a
deterministic Ethernet infrastructure as defined by IEEE. This would
probably be pretty straightforward work.

However, your conversation got me to read the charter more closely, and
while the word "pseudowire" isn't used, the inclusion of the PALS WG in the
charter implies to me that the scope of work could include the transport of
deterministic Ethernet flows (as defined by IEEE) within pseudowires
carried by arbitrary IP and/or MPLS infrastructures. All of a sudden, the
work is much less straightforward. If this is indeed part of the scope of
work, it should be explicit in the charter (or explicitly excluded if not).

Cheers,
Andy


On Fri, Sep 18, 2015 at 12:26 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Thanks Lou,
>
> I think we're in agreement that a new WG would be helpful as a place to
> coordinate whatever work is needed and to provide a discussion forum. This
> is
> partly because there is no existing place where this work wold not provide
> a
> distraction.
>
> It is possible that the location for the work is RTG if the applicability
> document is describing the applicability of some of the control plane
> protocols,
> although applying RSVP would possibly put it in TSV. And if the work is
> applying
> IP, it might be in INT. Not so sure that this is a really important issue.
>
> But I am still left looking at the current charter text and thinking it is
> not
> describing the applicability statement that we are discussing. If my
> paragraph
> that you quoted describes the work well, can we do some serious edits to
> the
> charter to make it substantially clearer what the WG is actually doing. I
> might
> suggest removing nearly all of the text and replacing it with a short
> paragraph
> that says something like what I wrote (with perhaps a few more words).
> Currently
> I find the text confusing in scope and very open to misinterpretation.
>
> Thanks,
> Adrian
>
>
> > -----Original Message-----
> > From: Lou Berger [mailto:lberger@labn.net]
> > Sent: 18 September 2015 16:52
> > To: adrian@olddog.co.uk; ietf@ietf.org; iesg@ietf.org
> > Cc: 'detnet WG'
> > Subject: Re: WG Review: Deterministic Networking (detnet)
> >
> > Hi Adrian,
> >     I have to say that there were times that I felt the same as you, and
> > questioned what a DetNet WG would / should do.  I think you hit the key
> > points in your mail and the main work that needs to be done is to say
> > how all the pieces fit together when operating over IETF owned data
> > planes, i.e. IP and MPLS, without modification.  I think your last
> > paragraph summarizes the work to be done quiet well.
> >
> > > Are you sure that this work is more than an applicability statement
> that
> shows
> > > how existing tools are used to achieve the desired function. This
> document
> > might
> > > cover data plane, OAM, packet classification, configuration, control
> plane,
> > > security, etc. That would be useful work and would probably need a WG
> to
> > achieve
> > > the necessary discussion.
> >
> > This answers the question that the work belongs in the IETF in some WG,
> > but doesn't say that a new WG is needed.  I came the conclusion that a
> > new WG is needed to ensure that the overall solution "works" and that
> > the data plane details are sufficiently defined.
> >
> > Does this help?
> >
> > Lou
> >
> > On 9/18/2015 11:38 AM, Adrian Farrel wrote:
> > > Hi IESG,
> > >
> > > I am struggling to understand why this work is being proposed in the
> Routing
> > > Area. Actually, I am slightly struggling to understand why it is being
> proposed
> > > for the IETF.
> > >
> > > This is not say I don't think a WG is needed, but the only work I see
> described
> > > here is a documentation of data plane work and an "overall
> architecture". I
> > > assume that any modification to a layer 2 data plane will be carried
> out by
> the
> > > SDO that owns that data plane. In particular, if changes to Ethernet
> are
> needed,
> > > they will be done in the IEEE. So, that leaves us with work at L3 for
> which
> the
> > > proposed charter text says IP or MPLS. Now, it seems to me that any
> change
> to
> > IP
> > > or MPLS in the forwarding plane is alarming, and also that any change
> to IP
> > > would need to be done in the Internet Area.
> > >
> > > At the same time, the charter explicitly puts discussion of control
> plane
> out of
> > > scope.
> > >
> > > Are you sure that this work is more than an applicability statement
> that
> shows
> > > how existing tools are used to achieve the desired function. This
> document
> > might
> > > cover data plane, OAM, packet classification, configuration, control
> plane,
> > > security, etc. That would be useful work and would probably need a WG
> to
> > achieve
> > > the necessary discussion.
> > >
> > > Adrian
> > >
> > >> -----Original Message-----
> > >> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On
> Behalf Of
> > The
> > >> IESG
> > >> Sent: 18 September 2015 15:51
> > >> To: IETF-Announce
> > >> Cc: detnet WG
> > >> Subject: WG Review: Deterministic Networking (detnet)
> > >>
> > >> A new IETF working group has been proposed in the Routing Area. The
> IESG
> > >> has not made any determination yet. The following draft charter was
> > >> submitted, and is provided for informational purposes only. Please
> send
> > >> your comments to the IESG mailing list (iesg at ietf.org) by
> 2015-09-28.
> > >>
> > >> Deterministic Networking (detnet)
> > >> ------------------------------------------------
> > >> Current Status: Proposed WG
> > >>
> > >> Assigned Area Director:
> > >>   Deborah Brungard <dbrungard@att.com>
> > >>
> > >> Mailing list
> > >>   Address: detnet@ietf.org
> > >>   To Subscribe: https://www.ietf.org/mailman/listinfo/detnet
> > >>   Archive: https://mailarchive.ietf.org/arch/browse/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
> > >>
> > >>
> > >>
> > >> Milestones:
> > >
> > >
>
>
>