Subject: Re: [Detnet] Opsdir last call review of draft-ietf-detnet-mpls-05

From: Balázs Varga A <[email-masked]>
Date: Sat, 18 Apr 2020 13:47:29 +0000

Hi Shwetha,

Many thanks for your review.

Yes, your assumption is right. OAM is covered in dedicated drafts:
- https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-oam/
- https://datatracker.ietf.org/doc/draft-mirsky-detnet-ip-oam/

Thanks
Bala'zs

-----Original Message-----
From: Shwetha Bhandari via Datatracker <[email-masked]> 
Sent: Friday, March 13, 2020 12:20 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir last call review of draft-ietf-detnet-mpls-05

Reviewer: Shwetha Bhandari
Review result: Ready

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts per guidelines in RFC5706 .
Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary:
This document specified Deterministic Networking data plane over MPLS Packet Switched Networks.

Focussing the review checklist from RFC5706:
- This document does not specify the controller and OAM function - It defers DetNet MPLS to use an associated controller and Operations, Administration, and  Maintenance (OAM) functions that are defined outside of this  document.
- It discusses the deployment scenario.
- There is a Management and Control Information Summary section describes the information needed by service and forwarding layers of the data plane from DetNet controller plane.  This includes reference to existing MPLS label advertisement mechanisms needed for operationalizing DetNet MPLS data plane. - For connectivity verification and monitoring: this document follows procedures set out in rfc5085 for Pseudowire Virtual Circuit Connectivity
Verification(VCCV) and supports In-Band VCCV (type 1) only. I assume this would defer a detailed discussion to a different draft produced by detnet wg
(draft-mirsky-detnet-mpls-oam-01?) However this is not called out in this document. - There is also a dedicated document  to specify data model for provisioning of end-to-end DetNet service - draft-ietf-detnet-yang-05, hence not covered in this document.

Hence with regards to operational considerations listed in RFC 5706 I dont see any issues in this document.