This looks fine to me. I will note that handling the multicast flows is part of what
may make just using pseudowires a bit more interesting.
Alia
On Fri, Sep 18, 2015 at 3:13 PM, Lou Berger <lberger@xxxxxxxx> wrote:
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 <lberger@xxxxxxxx
> <mailto:lberger@xxxxxxxx>> 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@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>
> <mailto:adrian@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>>;> > <mailto:adrian@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>>> 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@xxxxxxxx <mailto:lberger@xxxxxxxx>
> <mailto:lberger@xxxxxxxx <mailto:lberger@xxxxxxxx>>]
> > > Sent: 18 September 2015 16:52
> > > To: adrian@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>
> > ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <mailto:ietf@xxxxxxxx
> <mailto:ietf@xxxxxxxx>>; iesg@xxxxxxxx <mailto:iesg@xxxxxxxx>
> <mailto:dbrungard@xxxxxxx> <mailto:dbrungard@xxxxxxx> > <mailto:iesg@xxxxxxxx <mailto:iesg@xxxxxxxx>>
> > > 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@xxxxxxxx
> <mailto:ietf-announce-bounces@xxxxxxxx>
> > <mailto:ietf-announce-bounces@xxxxxxxx
> <mailto:ietf-announce-bounces@xxxxxxxx>>] 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 <dbrungard@xxxxxxx
> <mailto:dbrungard@xxxxxxx>>>
> > > >>
> > > >> Mailing list
> > > >> Address: detnet@xxxxxxxx <mailto:detnet@xxxxxxxx>
> <mailto:detnet@xxxxxxxx <mailto:detnet@xxxxxxxx>>
> > > >> 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
> detnet@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
detnet mailing list
detnet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/detnet