Re: [Detnet] proposed revised Charter

[Lou Berger <[e-mail]>]

Hi Xuesong,


On 3/11/2020 5:53 AM, Gengxuesong (Geng Xuesong) wrote:
>
> Hi Chairs & Quan,
>
> A brief question based on Quan’s previous email: Whether New Data 
> Plane Solution(e.g. SRv6) is included in the new charter?
>
> This seems different from the conclusion in IETF 106: SRv6 based data 
> plane solution is supposed to be promoted in other WG, e.g., SPRING.
>
> Thank you for raising this, and this is important to find a proper 
> home for our SRv6 based drafts.
>
I don't think this revision of the charter has change anything WRT Data 
plane solutions. We don't define forwarding plane technologies, but we 
may define how existing technologies may be used to support detnets.  We 
also can coordinate with other working groups to ensure that their 
forwarding technologies support detnet requirements. For SRv6 we need to 
continue coordinating with the SRv6 chairs (and working group) as 
previously discussed.

Thanks,

Lou

> Best Regards
> Xuesong
>
> *From:*detnet [mailto:[e-mail]] *On Behalf Of 
> *[e-mail]
> *Sent:* Wednesday, March 11, 2020 4:33 PM
> *To:* [e-mail]; [e-mail]
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Detnet] proposed revised Charter
>
>
> Hi Janos and Lou,
>
> It looks good to me. I think there are three main changes as following:
>
> a, increase the solutions of Control and Management Planes,
>
> b, increase the types of Data plane, such as SRv6,
>
> c, increase the requirements of the deterministic networks in all 
> industries.
>
> I think these are useful and I will contribute as the revised Charter.
>
> A question I am confused is that what the Management Planes cover, 
> such as OAM,PM?
>
> Thanks,
>
> Quan
>
>
>       <<[Detnet] proposed revised Charter
>
> Janos Farkas <[e-mail] 
> <mailto:[e-mail]>>Fri, 06 March 2020 14:29 UTCShow 
> header 
> <https://mailarchive.ietf.org/arch/msg/detnet/GcBVsW-_AeC6G1ryWpc_N5LuXIs/>
>
> WG,
> As discussed at the last IETF, it is time for us to update our 
> charter. We have put together the following proposal:
> 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 the IEEE
> 802.1 Time-Sensitive Networking (TSN) Task Group, which is responsible
> for Layer 2 operations, to ensure an aligned 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 industrial automation, as well as other general
> industrial and vehicular applications being considered 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 address solutions
> for large groups of domains such as the Internet.
> The Working Group is responsible for the overall DetNet architecture and
> DetNet-specific specifications 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. Layer 3 data plane technologies that
> can be used include: IP and MPLS, and Layer 2 encapsulations that run
> over IP and/or MPLS, such as pseudowires and GRE.
> 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 working group
> will also document DetNet Controller Plane [1] approaches that reuse
> existing IETF solutions, such as Path Computation Element (PCE), and
> identify the appropriate Working Group for any extensions needed to
> support DetNet. Documents produced by the Working Group will be
> compatible with the work done in IEEE802.1 TSN and other IETF Working
> Groups.  The Working Group's scope explicitly excludes modifications of
> transport protocols, OAM, Layer 3 forwarding, encapsulations, and
> control plane protocols, but it may define requirements for such
> modifications and identify the appropriate Working Group for any needed
> modifications.
> 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. Other IETF defined data plane technologies may also be used.
> Controller Plane: This work will document how to use IETF control plane
> solutions to support DetNet. This work includes identification of any
> gaps in existing solutions and identifying the appropriate Working Group
> for any needed extensions.
> Data flow information model: This work will identify the information
> needed for flow establishment and control and be used by reservation
> protocols and 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).
> 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 base models that are to be augmented.
> As needed, vertical requirements: This effort will detail the
> requirements for deterministic networks in various industries that have
> previously not been documented or cannot be supported using defined
> DetNet solutions.
> To investigate whether existing data plane encryption mechanisms can be
> applied, possibly opportunistically, to improve security and privacy.
> The Working Group coordinates with other relevant IETF Working Groups,
> including CCAMP, PCE, PALS, TEAS, OSPF, IS-IS, TSVWG, RAW, 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
> and related solutions. The WG will liaise with appropriate groups in
> IEEE and other Standards Development Organizations (SDOs).
> [1] The DetNet Controller Plane is defined in RFC 8655 as "the
> aggregation of the Control and Management Planes"
>