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>>> 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> > <mailto:adrian@xxxxxxxxxxxx <mailto:adrian@xxxxxxxxxxxx>>; > > ietf@xxxxxxxx <mailto:ietf@xxxxxxxx> <mailto:ietf@xxxxxxxx > <mailto:ietf@xxxxxxxx>>; iesg@xxxxxxxx <mailto:iesg@xxxxxxxx> > > <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> <mailto: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