Re: WG Review: Deterministic Networking (detnet)
2015-09-18 13:05:11
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 <lberger(_at_)labn(_dot_)net> 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
<adrian(_at_)olddog(_dot_)co(_dot_)uk
<mailto:adrian(_at_)olddog(_dot_)co(_dot_)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(_at_)labn(_dot_)net
<mailto:lberger(_at_)labn(_dot_)net
]
> Sent: 18 September 2015 16:52
> To: adrian(_at_)olddog(_dot_)co(_dot_)uk
<mailto:adrian(_at_)olddog(_dot_)co(_dot_)uk>;
ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>;
iesg(_at_)ietf(_dot_)org
<mailto:iesg(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
<mailto:ietf-announce-bounces(_at_)ietf(_dot_)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
<http://ietf.org>) by 2015-09-28.
> >>
> >> Deterministic Networking (detnet)
> >> ------------------------------------------------
> >> Current Status: Proposed WG
> >>
> >> Assigned Area Director:
> >> Deborah Brungard <dbrungard(_at_)att(_dot_)com
<mailto:dbrungard(_at_)att(_dot_)com
> >>
> >> Mailing list
> >> Address: detnet(_at_)ietf(_dot_)org
<mailto:detnet(_at_)ietf(_dot_)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:
> >
> >
|
|