Re: [Detnet] WG Review: Rewording in scope statement

["S.V.R.Anand" <[e-mail]>]

The change looks good to me. This said, I am wondering if the scope
automatically includes the possibility of (i) an heterogeneous network
comprising of mix of L2 technologies, wired and wirelss, within its
administrative domain, rather than strictly a homogeneous one and (ii) 
mobile
scenarios where the talker or listener or both can be mobile.

Anand



On Saturday 19 September 2015 01:45 AM, Grossman, Ethan A. wrote:
> I like this change.
 > Ethan.
 > ________________________________________
 > From: Eric Gray [[e-mail]]
 > Sent: Friday, September 18, 2015 12:16 PM
 > To: Lou Berger; Andrew G. Malis
 > Cc: detnet WG; IETF Discussion; IESG
 > Subject: Re: [Detnet] WG Review: Deterministic Networking (detnet)
 >
 > 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
 >
 >
 >
 >
 > _______________________________________________
 > detnet mailing list
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/detnet
 >



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.