RE: [Detnet] WG Review: Deterministic Networking (detnet)

[Eric Gray <[e-mail]>]

No objection from me.

-----Original Message-----
From: ietf [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Friday, September 18, 2015 3:14 PM
To: Andrew G. Malis
Cc: detnet WG; IETF Discussion; IESG
Subject: Re: [Detnet] WG Review: Deterministic Networking (detnet)

I like this change. 

Any objections?

Thank you!
Lou
On 9/18/2015 2:04 PM, Andrew G. Malis wrote:
> Lou,
>
> I would suggest the following:
>
> OLD
>
> Candidate Layer 3 data plane
> technologies that may be used, without modification, include: IP and 
> MPLS.
>
> NEW
>
> Candidate IETF data plane
> technologies that may be used, without modification, include IP, MPLS, 
> and Layer 2 encapsulations that run over IP and/or MPLS, including but 
> not limited to pseudowires and GRE.
>
>
> (I changed "Layer 3" to "IETF" so that we don't get into the debate 
> over whether MPLS is layer 3 or not).
>
> Cheers,
> Andy
>
>
>
> On Fri, Sep 18, 2015 at 1:16 PM, Lou Berger <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Andy,
>
>     On 9/18/2015 12:52 PM, Andrew G. Malis wrote:
>     > 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.
>
>     PWs has been mentioned as an option, but section of (existing)
>     encapsulation to be used is the subject of the WG.  So PALS is
>     included
>     really to cover this possibility.
>
>     > 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).
>     >
>     Do you have any suggested changes?  (It would help to understand your
>     concern.)
>
>     Thanks,
>     Lou
>
>     > Cheers,
>     > Andy
>     >
>     >
>     > On Fri, Sep 18, 2015 at 12:26 PM, Adrian Farrel
>     <[e-mail] <mailto:[e-mail]>
>     > <mailto:[e-mail] <mailto:[e-mail]>>> 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:[e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>]
>     >     > Sent: 18 September 2015 16:52
>     >     > To: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>;
>     >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>     >     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     > 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:[e-mail]
>     <mailto:[e-mail]>
>     >     <mailto:[e-mail]
>     <mailto:[e-mail]>>] 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 <http://ietf.org>
>     >     <http://ietf.org>) by 2015-09-28.
>     >     > >>
>     >     > >> Deterministic Networking (detnet)
>     >     > >> ------------------------------------------------
>     >     > >> Current Status: Proposed WG
>     >     > >>
>     >     > >> Assigned Area Director:
>     >     > >>   Deborah Brungard <[e-mail]
>     <mailto:[e-mail]> <mailto:[e-mail]
>     <mailto:[e-mail]>>>
>     >     > >>
>     >     > >> Mailing list
>     >     > >>   Address: [e-mail] <mailto:[e-mail]>
>     <mailto:[e-mail] <mailto:[e-mail]>>
>     >     > >>   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:
>     >     > >
>     >     > >
>     >
>     >
>     >
>
>
>
>
>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet