Re: [Detnet] The new d-ACH format

"Yangfan(Fan,IP Standards)" <> Thu, 18 November 2021 02:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D9DF3A07E2; Wed, 17 Nov 2021 18:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DLsQuAltkt63; Wed, 17 Nov 2021 18:27:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 969C73A07BF; Wed, 17 Nov 2021 18:27:00 -0800 (PST)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4HvkFd108Wz67sVs; Thu, 18 Nov 2021 10:26:45 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 18 Nov 2021 03:26:56 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 18 Nov 2021 10:26:54 +0800
Received: from ([]) by ([]) with mapi id 15.01.2308.020; Thu, 18 Nov 2021 10:26:54 +0800
From: "Yangfan(Fan,IP Standards)" <>
To: Greg Mirsky <>
CC: DetNet WG <>, DetNet Chairs <>
Thread-Topic: [Detnet] The new d-ACH format
Thread-Index: AQHX1jT6kt4ISHhgWEiVyrfZDO18/KwGJc6AgAFbiDCAAGj8AIAAprqg
Date: Thu, 18 Nov 2021 02:26:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9a9661d82668449aaa82a625f6687b40huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [Detnet] The new d-ACH format
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Nov 2021 02:27:06 -0000

Hi Greg,

I agree we need a thoroughly discussion to this new d-ACH format. Let’s continue the discussion in biweekly OAM meetings.  And I’d be very happy to involve myself more on this work.
One more comment to OAM meetings, maybe it is good to share the meeting minutes in WG after each call, could be short but nice. I can do it as I propose it and doesn’t bring burdens to others.
Besides, I strongly encourage people to join this helpful meeting to progress DetNet OAM as we have already reached many common understandings on OAM requirements in previous months.


From: detnet [] On Behalf Of Greg Mirsky
Sent: Thursday, November 18, 2021 7:54 AM
To: Yangfan(Fan,IP Standards) <>
Cc: DetNet WG <>; DetNet Chairs <>
Subject: Re: [Detnet] The new d-ACH format

Hi Fan,
thank you for your comments and questions. Please find my notes in-lined below tagged GIM>>,

On Wed, Nov 17, 2021 at 2:26 AM Yangfan(Fan,IP Standards) <<>> wrote:
Hi Greg,

Regarding the new d-ACH format, I have a few questions to share, hopefully trigger more discussions.

1)       I feel we need more specifications of Node ID.  Using 20 bits to indicate a Node in MPLS data plane, can I deduce it is an MPLS label? In any MPLS data planes except SR-MPLS, there is no definition to use a label to identify a node. If we want a format generic for all MPLS data planes, I wonder whether node id is a good indicator? Whether 20 bits is enough?
GIM>> I agree that the DetNet WG will have more discussions on the definition of the Node ID field. I am looking forward to your participation in these discussions.

2)       I also noticed there is a session ID, but is only 4 bit length, which I believe is way too short. Moreover, whether originator node ID and session ID are duplicated here to identify an OAM session. To dig deeper, DetNet OAM should be stateless or stateful?
GIM>> Session ID field is only a tentative name. Would it help if we mark it Reserved?

3)       if we plans to take advantages of CFM y.1731 mechanisms,  level and flags are necessary but the length also needs further considerations.
GIM>> It is not clear if DetNet OAM could benefit from re-using some principles of Y.1731/CFM as the latter doesn't provide special support for the Service sub-layer.

Looking forward to further discussions.


From: detnet [<>] On Behalf Of Greg Mirsky
Sent: Wednesday, November 17, 2021 4:55 AM
To: DetNet WG <<>>
Cc: DetNet Chairs <<>>
Subject: Re: [Detnet] The new d-ACH format

Dear All,
I hope you've recovered from the IETF-112 (timing on the West Coast was brutal).
Please share your thoughts, comments, and questions about the proposed new format of d-ACH and whether you support including it and updating draft-ietf-detnet-mpls-oam.


On Wed, Nov 10, 2021 at 5:14 AM Greg Mirsky <<>> wrote:
Dear All,
Bala'zs has presented the new d-ACH (DetNet Associated Channel Header) format at the DetNet WG meeting. Earlier this week, the new d-ACH format was presented at joint PALS, MPLS, and DetNet meeting and received several positive comments. At the DetNet WG meeting, it was proposed to integrate the technical part, the new format of d-ACH<> into the draft-ietf-detnet-mpls-oam<>.
Please, respond with the indication of your support or no support for the proposed update of the WG document.

Greg (as the Editor of draft-ietf-detnet-mpls-oam)