Re: [CCAMP] Webex meeting changed: Optical impairments draft

Dieter Beller <Dieter.Beller@nokia.com> Sat, 31 October 2020 09:28 UTC

Return-Path: <dieter.beller@nokia.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C49D3A09BC; Sat, 31 Oct 2020 02:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.147
X-Spam-Level:
X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmrYQtfAntuv; Sat, 31 Oct 2020 02:28:37 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30129.outbound.protection.outlook.com [40.107.3.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3E53A09B7; Sat, 31 Oct 2020 02:28:36 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fJ+gp3q883k+aEgzdTTznZBL7vb8VHO1usNVnmr5tUBkG826SFUVXSLbcbL46x32wZYm0yHedJzrWw1FOYEzZMRZMfW8C0m3fkBnsIXMYVClL1pgvhAktJSEZmawjLjYkW2gu4LWRQs/Cl8PczCG9WNPFAYbXN9NCyHQEyV0Zxe+MJakiFzfHGUPfuLMS7VdFf5z0B9JMky42fSDFEUXoB6MDEoahqRyXZpa9LNiy1bmMRuru0ElWK1t7eYn+Uytk1aHFSLDokUnKf8N+ifrl2BLtNxv4BFIr15tCN1QTTtTtLnijzWUxd95fzr3oG6EOcqc1qvmD40Qdj23uNHTpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QnxVhMUddm34xat8rfCphzrPOR8adwo0cBQoEoZl46A=; b=oao4gT1n7o+q5MwKoWppRCzu3L+2/lmKAhAZzqb4x8jNNZsiZynZFFMfO0NAMIRS4zLtPatAvgNOPR66p4klwC29I8C8Da7h8nFvKX5VcUkELuXAaTh4mYXL7qKlo4x11gZcZit2NHlj3TrxC0vlWEBfN9WBIfOs5w3L+8KvxgTjj72RZ0Ueul29MQJS6OWWyFzOnbRftUOpN+WRxzmThWbAnuYsV62eWE6BEYJUWxEiqO/mrxRIMizePfGEFJlXtRSN/pHXSDlhkSHrSgh7zF6SJZ6aHO9poqTAlGHPLkVe1WTSJBJHJmEoEsboVxDjr3fa3/S4ws9+tueJv4/gYg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QnxVhMUddm34xat8rfCphzrPOR8adwo0cBQoEoZl46A=; b=fPdfXSWJ0ltzR82am49HFCIkxjVA/zfJAhwDQbcJBGv9nFJ4AVZ5NH1paRN6wkWbVi8XyvpfWv/4U/T/Of6ncPSQQhA9gAyGtBBUlWXIXsNKI8x+8J8ZQ5wRBLdhWxFaxrKrxF24wDIp9rNpztos0g/QoRpj7TxnL3fc3gM1NbY=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com;
Received: from AM7PR07MB6788.eurprd07.prod.outlook.com (2603:10a6:20b:1be::14) by AS8PR07MB7701.eurprd07.prod.outlook.com (2603:10a6:20b:256::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.15; Sat, 31 Oct 2020 09:28:31 +0000
Received: from AM7PR07MB6788.eurprd07.prod.outlook.com ([fe80::9df3:ea87:4d40:dba5]) by AM7PR07MB6788.eurprd07.prod.outlook.com ([fe80::9df3:ea87:4d40:dba5%5]) with mapi id 15.20.3499.029; Sat, 31 Oct 2020 09:28:30 +0000
To: Italo Busi <Italo.Busi@huawei.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
References: <E3FA7667-4767-4DC6-9F08-210FB254F629@juniper.net> <af767563835443ce889b7b05afc5b87d@huawei.com>
From: Dieter Beller <Dieter.Beller@nokia.com>
Organization: Nokia
Message-ID: <379ed6ba-a3da-82a2-d867-148c8070da9a@nokia.com>
Date: Sat, 31 Oct 2020 10:28:28 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
In-Reply-To: <af767563835443ce889b7b05afc5b87d@huawei.com>
Content-Type: multipart/alternative; boundary="------------29C320E8D37585540D826864"
Content-Language: en-US
X-Originating-IP: [88.152.185.31]
X-ClientProxiedBy: AM0PR08CA0017.eurprd08.prod.outlook.com (2603:10a6:208:d2::30) To AM7PR07MB6788.eurprd07.prod.outlook.com (2603:10a6:20b:1be::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.18.11] (88.152.185.31) by AM0PR08CA0017.eurprd08.prod.outlook.com (2603:10a6:208:d2::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Sat, 31 Oct 2020 09:28:30 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: bd8f28a4-a013-447c-ca4f-08d87d7f5493
X-MS-TrafficTypeDiagnostic: AS8PR07MB7701:
X-Microsoft-Antispam-PRVS: <AS8PR07MB7701B969C9380D0BD69DA58FE2120@AS8PR07MB7701.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 7PzEEieMa/YYROlH4LsUTY8rty9KDaSkTm4I2xj2ldw0YwC2NOEq8x0XgLTtpzpJa68XfGHJndL+7nP3yoJgbtl27aIr0PusfS7QtDWPQqL0DApOk7SI0XiebI0SkeU9gaRkSk2LRUFklQt13vMCsEug1HwUmUzCeUi6sgwf+V5lLUu+DR/dvulnbZk5rOT1DVz+Sv0hFiaUta6YYbrPTFFmditvnFuWvKJPpKt/NRshUHyUZZ9u/nrK3UczumzTUKjgFGbWfwhPjP6fkt1x/xDGp+U5CSin5LIlPgPRXX7aW20K7ezUdDbWz71DzfEGn9jpDBCv1z6Nsd07OU6XLrEfbKZoLZtlVAnKmte4D6sFKJ35Ol8C9OjqM/AQ0PszeJP0Hal0QIeEGvWDrre43aNsCrZzcBSzBamW/4M8iEJ+edHP9olB5xvWRk3AHo30EpplSNfKHmoAkVNpfFqpyA==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6788.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(39860400002)(136003)(376002)(316002)(2616005)(86362001)(956004)(110136005)(16576012)(966005)(30864003)(478600001)(16526019)(26005)(83380400001)(33964004)(186003)(53546011)(66946007)(166002)(66476007)(66556008)(8936002)(2906002)(8676002)(5660300002)(36756003)(36916002)(31686004)(6486002)(31696002)(43740500002); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: EMImMdo5LEPoMTJnobVLY2w3/Lj3k8itarsBplhQK8i7+gbIhPcIj51X9B4qCbQBn6Jfh6IwXYhbP7xHlauHVVlr9iPSQmJ5juAXATBeYHa1diaGudBl66SMkXKEvEDlc1hnfDF/40tKTzWLdv+Kk10Cg0/Iy8hRZLNnfEOc8RTAMUi60m3TTUXrNdqtFkxCOXeEN3MxM0XxyXmcFqhPD6jJzZkOdMVIzFlQoPAbLPsBNTU8Ivo7Be4EHx5AHhdYveTRJYXc/JKGGDcyVX7usglmtLLb/uBi1KHxSrf8mI9BIpczjKvAVvl90Kt0aOaFFkpmt+nRU7MuGPrWtvwtOQ7Cxo2uuOmIKzWJN2AaunvXQkhHMLfI7ssEyQxd+NnQ9IeWpUWGH6s56mZZtS31SPhOGyyKtKdMb1wM/lb+SmgNom4A8O9EotBIl0vrpplVWKIx1X6hbuzUeOJ9uKcj3O7FbQ77h77ja63UDkSaDzapZbyOn9NeUO1WBXwxHZFJGOrBzY3UfbmsA1v8LAXyGZDtBNwdudZHB+lbwn2YCsrX4os5IKXGQUPWekg/MwxgGNGtBMiOMJ3rp5XLpPq+hpJ8Oh26HWqWzLScsrziR3noGci0GD7VqNdYP7dYxObwD6FZzfVu0/BOTy0Gv0kE3Q==
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bd8f28a4-a013-447c-ca4f-08d87d7f5493
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6788.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Oct 2020 09:28:30.7913 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: QZOFhwkODaAxybAHFOy6YAogD7qWbLI+zNNWx7Zt0Kl7QYlqeX/AaSfRm7d/lVQZRFHt5XVZaNgkELVgMzYi8w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB7701
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/cLA0QgB8iMH4W088n2KN6Jqh6aw>
Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Oct 2020 09:28:40 -0000

Thanks, Italo, for your contribution to the technical discussion!

I would like to emphasize that the text on GitHub ( see 
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150) 
tries
to provide the technical justification for the modeling approach taken 
for the organizational mode option - here is the text, which was 
referenced in Italo's mail:

*Organizational Mode:*
Organizations like operator groups, industry fora, or equipment vendors 
can define organizational modes, which will allow these organizations to 
make use of advanced transceiver capabilities going beyond existing 
standardized application codes. Such an organizational mode is 
identified by the organization-identifier attribute defining the scope 
and an operational-mode that is meaningful within the scope of the 
organization. Hence, the two attributes must always be considered 
together. Two transceivers are inter-operable, if they have at least one 
(organization-identifier, operational-mode) pair in common and if the 
supported carrier frequency and power attributes have a matching range. 
This is a necessary condition for path computation in the context of 
organizational modes. An operational mode is a transceiver preset (a 
configuration with well-defined parameter values) subsuming several 
transceiver properties including:
• FEC type
• Modulation scheme
• Encoding (mapping of bit patterns to symbols in the constellation diagram)
• Baud rate (symbol rate)
• Carrier bandwidth (typically measured in GHz)

The major reason for these transceiver presets is the fact that the 
attribute values typically cannot be configured independently and are 
therefore advertised as supported operational mode capabilities.
It is the responsibility of the organization to assign operational modes 
and to ensure that operational modes are unique and not ambiguous within 
the scope of the organization.
In addition to the transceiver properties subsumed by the operational 
mode, optical power and carrier frequency related properties are modeled 
separately, i.e., outside of the operational mode. This modeling 
approach allows transponders using different transceiver variants (e.g. 
optical modules) with slightly different power and/or frequency range 
properties to interoperate without defining separate operational modes. 
Different optical modules (pluggables) from different suppliers 
typically have slightly different input and output power ranges or may 
have slightly different carrier frequency tuning ranges.
The received channel power and the received total power are two 
parameters that can be measured by the receiver and can be provided by 
the transceiver in order to allow a controller to determine the expected 
performance of the end-to-end service taking into account the optical 
impairments along the path.


Moreover, implementations exist that are based on the same modeling 
approach and hence it is *already field proven!*


Thanks,
Dieter


On 30.10.2020 17:14, Italo Busi wrote:
> Hi Gert,
>
> Let me try to look at this issue from a different perspective.
>
> I think the objective of our work is to define a YANG model for the optical specification methodologies which are used in the field to represent the capabilities of the transponders.
>
> I do not think that it is in the scope of our work to discuss the optical specification methodologies other than understanding how they could be used for path computation (ensuring interoperability between the sender and receiver) and modelled using YANG.
> 	
> As far as I have understood from past discussion, we have agreed to support three optical specification methodologies which are used by existing optical interfaces implementations and we have named them as application code (ITU-T G.698.2), organizational mode and explicit mode.
>
> After some rounds of discussions and questions for clarification, the latest proposed text to describe the behavior of the organization mode has been prepared on github:
>
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150
>
> I think this updated description has improved the clarity of how the operational mode are implemented and, in particular that:
>
> "Two transceivers are inter-operable, if they have at least one (organization-identifier, operational-mode) pair in common and if the supported carrier frequency and power attributes have a matching range."
>
> As a consequence, I think that the YANG model defined in "Case A" below does not work (since it does not provide enough information to check that " the supported carrier frequency and power attributes have a matching range ") while the one defined in "Case B" works properly.
>
> This text describing the operational mode behavior has been provided by people who have implemented it.
>
> Therefore, I think we can update the draft with the changes discussed in the last few weeks incorporating the definitions capturing our current understanding of how these optical specification methodologies (application code, organizational mode and explicit mode) behave and the YANG model aligned with our current understanding (i.e., based on "Case B" below).
>
> Since we are not yet in WG LC stage, we still have plenty of time to update both the description and the YANG model based on the feedbacks we receive from data plane experts.
>
> My 2 cents
>
> Italo (as co-author of the draft)
>
> -----Original Message-----
> From: Gert Grammel [mailto:ggrammel@juniper.net]
> Sent: giovedì 29 ottobre 2020 17:34
> To: ccamp-chairs@ietf.org; ccamp@ietf.org
> Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> We discussed today a difference in the interpretation of the model related to https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29 and its interpretation. The different interpretation lead to different computation requirements.
> The design team appreciates feedback which of both Cases is preferred and what consideration led to the preference
>
>
> Case A:
> ======
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528 from August 20 documented the structure of the model:
> +--ro supported-modes* [mode-id]
>>    +--ro mode-id
>>    +--ro (mode)?
>>    |  +--:(G.698.2)
>>    |  |  +--ro standard-mode?                standard-mode
>>    |  +--:(organizational-mode)
>>    |  |  +--ro operational-mode?             operational-mode
>>    |  |  +--ro organization-identifier?      vendor-identifier
> ➢ |  +--:(explicit-mode)
> ➢ |    +--ro supported-standard-mode*? leafref
>>    |     +--ro modulation-types                   identityref
>>    |     ......
> This snippet would allow to use standard mode or operational mode as a simple matching criteria for compatibility i.e. two transponders with Operational-mode=X and suitable line parameters would interoperate.
> In case of “explicit” mode, the set of parameters provided, can support one or more application code/organizational mode, that means this set of parameters if applied to configure the transceiver, is aligned with one or more application code/organizational mode.
> (Note that there are no additional parameters associated to the organizational mode in this case)
>
> Case B:
> ======
>
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree contains additional parameters to the Operational Mode that are also replicated in the explicit mode. Those parameters are related to the min/max ranges which are allowed.
>
>    +--ro supported-mode* [mode-id]
>                  +--ro mode-id                      string
>                  +--ro (mode)
>                     +--:(G.698.2)
>                     |  +--ro standard-mode?         standard-mode
>                     +--:(organizational-mode)
>                     |  +--ro organizational-mode
>                     |     +--ro operational-mode?
>                     |     |       operational-mode
>                     |     +--ro organization-identifier?
>                     |     |       organization-identifier
>                     |     +--ro min-central-frequency?
>                     |     |       frequency-thz
>                     |     +--ro max-central-frequency?
>                     |     |       frequency-thz
>                     |     +--ro minimum-channel-spacing?
>                     |     |       frequency-ghz
>                     |     +--ro tx-channel-power-min?      dbm-t
>                     |     +--ro tx-channel-power-max?      dbm-t
>                     |     +--ro rx-channel-power-min?      dbm-t
>                     |     +--ro rx-channel-power-max?      dbm-t
>                     |     +--ro rx-total-power-max?        dbm-t
>                     +--:(explicit-mode)
>                        +--ro explicit-mode
>                           +--ro supported-modes
>                           |  +--ro supported-application-codes*
>                           |  |       -> ../../mode-id
>                           |  +--ro supported-organizational-modes*
>                           |          -> ../../mode-id
>                           +--ro line-coding-bitrate?
>                           |       identityref
>                       <snip>
>                           +--ro min-central-frequency?
>                           |       frequency-thz
>                           +--ro max-central-frequency?
>                           |       frequency-thz
>                           +--ro minimum-channel-spacing?
>                           |       frequency-ghz
>                           +--ro tx-channel-power-min?
>                           |       dbm-t
>                           +--ro tx-channel-power-max?
>                           |       dbm-t
>                           +--ro rx-channel-power-min?
>                           |       dbm-t
>                           +--ro rx-channel-power-max?
>                           |       dbm-t
>                           +--ro rx-total-power-max?
>                                   dbm-t
>
> In this case, interoperability can only be provided if the organizational code on each side match AND all other explicit parameters defined in the organizational-code have a matching range.
> (Note that min/max parameters are associated to the organizational mode AND to the explicit mode in this case)
>
>
>
> Juniper Business Use Only
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp