Re: [CCAMP] Notes: Microwave Topology - 2020-05-18

Jonas Ahlberg <jonas.ahlberg@ericsson.com> Wed, 20 May 2020 10:04 UTC

Return-Path: <jonas.ahlberg@ericsson.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 B81A43A073D; Wed, 20 May 2020 03:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 dEKh74DEuBxe; Wed, 20 May 2020 03:04:44 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130048.outbound.protection.outlook.com [40.107.13.48]) (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 D8EF33A067A; Wed, 20 May 2020 03:04:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kTV2C5P9yjWTItLI9+WBXvvpoBbMzcBdOkVWDFNVd+gdbd759vcx954AegZ5Hsx+Upv4M1Nx6cnm/LMHGFwQkM9Y7+JNQwAMl1aQncALXKG52Wsh85hIC615FAPPx3U/M/3GmaAwRVBRMNRevzTWHzifuxzX+5nRrlpjCzymMlP+nYeZq/ELOkJgIzZkDA0kMWjrmojjyo8YsbaMPyrK5k+vYJTi2xeh3iw6D3FnLe3Fx4bgpqddV/EDf4DsNNZnM1x+RZsvb46ZqwM9CA/qtZCxGuc4yWNiLAWTXWN6FCtgSx9PvZvBKKePMx5ph3MM4nWKz8kiykjXnOtTsEdgLg==
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=P8jbapHDmdh76J10AzuDgcfhcB1Bv/x1Qg1QFGCgT8E=; b=Ktf3ehoDP92W40pFRgGGZ+OnLtmH6mWq8uk6RgBVfvO12TLzOnAFXONKEDWTElWi9OZT6eQFDooRHKfjShsNYtajicsUsDzvi4rslURgyuYjxx/1vSHEOxl7rVmIN2qeSBsor9TTvGEeeOws2pornU17m0W7018Cgg8QGdBucxGw20qehQaS0z8QFmvYtQ4E22baZOf5OWU5U0cZan3uT5agKYfudhVdSULI/yQ4ZXe548XqaVKbJKzkwNNs/xubSDEKmUnHIhzlvOFr3oWEMqUmEtz7wys96URu8Sd/sNh9J0XF4YOk9yPiR9S5g0BCGmCU/uPNpkuupAwb+z0/Pg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=P8jbapHDmdh76J10AzuDgcfhcB1Bv/x1Qg1QFGCgT8E=; b=ljlC764tt3rtrDMaYiJahV+FRY//iFC+kUUeFDXWsVZDjcxHdQWBXRVTRBtZFMzDmEmmaePwKiIAjggNMStIFXjZTSxdULr4GdQsLLZRra1E4Yj7xjcdHcFtp1Uj4UwVQPiu60VdWSahS/OZ3miwoOnoCruy3g0sF8O80C1NqjE=
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com (2603:10a6:208:24::20) by AM0PR0702MB3666.eurprd07.prod.outlook.com (2603:10a6:208:16::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.13; Wed, 20 May 2020 10:04:35 +0000
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::c0c4:eefc:6343:34f6]) by AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::c0c4:eefc:6343:34f6%3]) with mapi id 15.20.3021.019; Wed, 20 May 2020 10:04:35 +0000
From: Jonas Ahlberg <jonas.ahlberg@ericsson.com>
To: ccamp <ccamp@ietf.org>, CCAMP Working Group <ccamp-chairs@ietf.org>
Thread-Topic: Notes: Microwave Topology - 2020-05-18
Thread-Index: AdYtAoXyEMX8eirlS2GIpelxpk0nkQBfjSYg
Date: Wed, 20 May 2020 10:04:35 +0000
Message-ID: <AM0PR0702MB3537B4E9081611503C66360089B60@AM0PR0702MB3537.eurprd07.prod.outlook.com>
References: <AM0PR0702MB35377569324A60109E14B3EF89B80@AM0PR0702MB3537.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR0702MB35377569324A60109E14B3EF89B80@AM0PR0702MB3537.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [94.234.48.57]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ecf5f366-514e-4eb9-b047-08d7fca532fa
x-ms-traffictypediagnostic: AM0PR0702MB3666:
x-microsoft-antispam-prvs: <AM0PR0702MB36662CDC467019322358C55289B60@AM0PR0702MB3666.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 04097B7F7F
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QzTVDRzR3+980FjH3e0e/+JOfNT/I91EV6TZ8GwNd2Fak6bD6zrNoaPdmJGDIIU5Zvy3/ajVHyxJFyGirXIte4gJvmbgpu+oPW3bSKEINp0Tel7Lj8yH5EKTZ43Vy1SsZkPtjItazjMYq4tpjxPLMrYvlFtNqa+voytce6xzk1FPF6oUuRxAbwACYcIhyuqvUtZ4SSPOEubXaQOEwPdUOWnFlfBkVFc3/sqnWzsrW+TYTk7OKFHOA1mZJsTVWO7/vrRzIWrbDTwjrtNDANfOtR4JhfxzdUm/y2Yo7A/izWqLVAL5jtIOEzTI0tTXpqq0LOwDbg4Hf4CsfHcMSiWH6Ch/5RsDRMiu+AiWZ/Ry2iFbnl6xFOSugX9WZQt7zj/Z5GIn1sDaVqyvwQHSTkXD7A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3537.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(66446008)(450100002)(8936002)(64756008)(66556008)(76116006)(44832011)(66476007)(66946007)(8676002)(86362001)(6506007)(110136005)(7696005)(53546011)(30864003)(316002)(19627405001)(186003)(26005)(16799955002)(52536014)(4001150100001)(166002)(9686003)(966005)(55016002)(478600001)(71200400001)(33656002)(5660300002)(2906002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: pomae+wqohPfgzzN+OrGlyPN2r0xDcRMFE0Dh2POMFsbTqPYFW5JmKWQ9CRbtr2i/aSPmoMNNnRwNpCssC+a/78khdJvIP70tPbafBrVijSSiSoJGI/nQaDawNct91IqCQZFwnBLQZgXfe8yhnHScXB3CzUY5a08fFnvs3tzR+LxT6I6+2PaeNLJB5fOdh7WzkWlYldI0C6HZfvyfPIv3lSFhBYC0OWjmVUTUHAPUpGOoVUmW04jeI1kxDTeS0PAinDVS+vNvotNXhu9IiQ3e/7/YUaGfDYkO7SiR84Vwp2SmOuZQRAo7/Az3OsNVBvvUwBPbxi4NKGXBTC/dUC3+3Ln82xktLAie1MWOyBUNk1cVNTAPVgKB99EYc+yHd6KkVI1H6aIM3Ckz1dw37uXJfxNNRvB8m9AffJVfqen3+NBg0ZxDweOldpR/UwlQF7Xh4lvZVBzWVzFPSiC2ULgoGcw5SRJDoSct8A9n5BK3vE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB3537B4E9081611503C66360089B60AM0PR0702MB3537_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ecf5f366-514e-4eb9-b047-08d7fca532fa
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2020 10:04:35.0678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /c4Nr0NitcUOD9mQFFYpcNetBEaUnY2WRK6YtxlBcpRy4AYcc45rUBZMfIqd3UaMXnsgvTwJIRtXS/gvFQpbxbaDyKNzXd0bQsrSrXKThN4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3666
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/0Jn1UHwraZspYw-sDvVx4N8R2JA>
Subject: Re: [CCAMP] Notes: Microwave Topology - 2020-05-18
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: Wed, 20 May 2020 10:04:51 -0000

Hi all,

This is my input on the attributes required in a topology model for microwave in order to support the use cases (chapter 5.1) defined in the ETSI use case document, “Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimeter wave transmission”.
Let’s discuss at the meeting on Monday.

5.1.2 Efficient power consumption
There are a number of ways to reduce the power consumption,

  *   changing to a lower level coding and modulation & thereby reducing output power
  *   deactivating a carrier in a bonded configuration
  *   taking down the complete radio link, in cases where there a still possibilities to reach the far-end for restart of the radio link gain
  *   …
All this can be done using the interface management model for microwave, RFC 8561, and I don’t see that there is a need to duplicate that functionality in a topology model. There should however be support for navigating from a topology model, a termination point, to the corresponding entity in the interface management model. This is already covered by the rlt-interface-path attribute discussed in previous meetings.

The topology model should support with:

  *   Understanding of the overall topology, e.g. what parts of the network or what services are impacted by reducing the capacity provided by a particular radio link
     *   The microwave topology model can only show link by link and has no information about how different links are related to each other. That information is only available on higher layers, e.g. in a L2/Ethernet topology.
     *   Already supported by existing models - no additional information is required.
  *   Understanding the capacity (speed) provided by a link.
     *   Already supported by existing models - no additional information is required.
  *   Understanding the utilization of a link
     *   Is there a standard set of attributes we can refer to? Radio link level? Ethernet level?

5.1.3 Dynamic traffic distribution
The actual traffic is managed on layers above the microwave radio link layer and the associated topology model.
The radio link layer is however expected to support the process with the following information:

  *   current link speed/capacity – Supported by the already proposed bandwidth attributes : maximum & current
  *   availability/capacity - Supported by the already proposed availability/capacity matrix
  *   link status? – New attribute?
  *   notification about changes in provided speed/capacity over a link? – New?


5.1.4 Interference handling
Interference is in this use case managed by changing the frequency/bandwidth of selected/affected carriers.
Carriers are not modeled as links in the currently proposed topology model, just as attributes of a radio link. (There is a possibility to include a new topology level for carriers, supporting links to radio link, but that is a separate topic)
I suggest that this use case is managed in the same way as use case 5.1.2 and use the interface management models for performing the actions towards the carrier terminations, such as change of frequency.
The topology model could support with the understanding of the overall topology, e.g. what termination points are affected/related and what parts of the network and what services are impacted by making the changes of frequencies for a particular carrier. Already supported by existing models - no additional information is required.


5.1.5 OAM of MW/mmW networks
Considering the concreate use cases mentioned in the text.

  *   Detection and configuration of new MW devices
     *   Detection is supported by other types of interfaces, e.g. LLDP
     *   Configuration is performed on a device level and should be supported by corresponding device models, such as RFC 8561
  *   Detection and visualization of the configured/currently effective MW network
     *   The detected topology of a microwave network, radio link level and Ethernet level, should be possible to record in the associated topology models
        *   Already supported by existing models - no additional information is required.
  *   Receiving, displaying and storing of alarm information
     *   Should be supported by alarm management functionality
     *   The topology model should support correlation of alarms
        *   Relationships between device and link (the rlt-interface-path attribute)
        *   Relationships between links/termination points on different layers. Already supported by existing models - no additional information is required.


In general I think that most operations in his area are related to devices and not to abstract links. There could however be useful to have a good understanding of the status of a link. Would that require a new attribute?

5.1.6 Automated frequency allocation
More or less the same type of use case as 5.1.4 and I suggest that we use the same approach.


/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 18 maj 2020 15:24
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-05-18

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

The meeting agreed that we should try to progress more work outside the actual meetings and leave room at the meetings to draw conclusions and create consensus on way forward.

Next steps:

  *   Identify attributes required to be supported by the topology model.
     *   To be based on the use cases described in the ETSI use case document, “Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimetre wave transmission”
        *   https://www.etsi.org/deliver/etsi_gr/mWT/001_099/016/01.01.01_60/gr_mWT016v010101p.pdf
     *   1 step is to review the use cases in chapter 5.1 “Radio link network segment in itself”
     *   To be reviewed at next meeting
     *   It would be appreciated if you could share your findings on the mailing list before the meeting.



  *   Stephen to resend a previously shared alternative illustrating some interesting concepts to be further discussed and agreed upon.


Next meeting:

  *   The current meeting time on Mondays might not be the best and we still expect feedback from the team about their preferences.
  *   Until then, we will keep the current time, which means that next meeting will be Monday, May 25, 11-12 CEST.

/JonasA



From: Jonas Ahlberg
Sent: den 11 maj 2020 12:23
To: Spreafico, Daniela (Nokia - IT/Vimercate) <daniela.spreafico@nokia.com<mailto:daniela.spreafico@nokia.com>>; Xi Li <Xi.Li@neclab.eu<mailto:Xi.Li@neclab.eu>>; Stephen Cheng <Stephen.Cheng@Aviatnet.com<mailto:Stephen.Cheng@Aviatnet.com>>; Dragos-Iulian Dosan <dragosd@ceragon.com<mailto:dragosd@ceragon.com>>; Italo Busi <Italo.Busi@huawei.com<mailto:Italo.Busi@huawei.com>>; Yemin (Amy) <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>; Scott Mansfield <scott.mansfield@ericsson.com<mailto:scott.mansfield@ericsson.com>>
Subject: Notes: Microwave Topology - 2020-05-11

Hi all,

We cancelled the meeting today since the participation was poor.
It’s fully understandable that there will be occasions where someone has a conflict, but lately the attendance in general has been a bit too low in order to progress the work in a good way. Especially since we want to anchor this broadly within the community.

Maybe, the time and day for the meeting is not the best.
Please suggest time slots that would work better (or equally good) for you, and then we can try to find a time that is better for all or at least most of us.

Regards
JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 6 maj 2020 08:02
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-05-04

Hi all,

Participants:
Dragos Dosan
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Meeting discussion:

  *   rlt-interface-path, using an yang:xpath1.0 expression, to provide a relation to the RLT interface in the interface management module for radio link
     *   What is the corresponding use cases explaining why this attribute/reference is required?
     *   The attribute is optional, but in order to use the xpath, the controller need to have implemented support for the interface management module, RFC 8561
     *   Xpath v.s. Mount point – Needs a clear justification why xpath is better
        *   Using a mount point means that you create a stand-alone & independent copy (a new separate instance) of the RLT interface, which means that you e.g. cannot make use of the interface to traverse up and down the higher & lower layer relationships.
        *   Using a xpath you just point to an already existing instantiation of the interface management model, and you have the possibility to use all the information & capabilities provided by that model.


  *   Which microwave related attributes to be included in the topology model
     *   Bandwidth: maximum & current
     *   Availability matrix
     *   Clarify the scope:
        *   Supporting path computation & setting up services across a microwave radio link
        *   Microwave specific tasks related to configuration/inventory/monitoring of radio links & carriers
     *   Other candidates – Need to be explained by clear use cases
        *   Frequency (Xi) – Carrier level
        *   Energy efficiency (Xi)
        *   Signal id (Dragos)
        *   Auto discovery (Dragos)
        *   Oper/Admin status - There is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers
     *   It was suggested that we could use the ETSI use case document, “Applications and use cases of Software Defined Networking (SDN) as related to microwave and millimetre wave transmission”, as a reference
        *   https://www.etsi.org/deliver/etsi_gr/mWT/001_099/016/01.01.01_60/gr_mWT016v010101p.pdf
        *   It was agree that we should analyze what attributes the ETSI use cases would require on a topology level.

Next meeting the focus will be on use cases and associated attributes required in a topology model for microwave.

/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 27 april 2020 14:40
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-27

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Xi Li
Jonas Ahlberg

Meeting discussion:

  *   Association with the RLT interfaces, rlt-interface-path, using an yang:xpath1.0 expression
     *   What is the corresponding use cases explaining why this attribute/reference is required?
     *   The attribute is optional, but in order to use the xpath, the controller need to have implemented support for the interface management module, RFC 8561
     *   Xpath v.s. Mount point – Needs a clear justification why xpath is better


  *   Which microwave related attributes to be included in the topology model
     *   Bandwidth: maximum & current
     *   Availability matrix
     *   Clarify the scope:
        *   Supporting path computation & setting up services across a microwave radio link
        *   Microwave specific tasks related to configuration/monitoring of radio links & carriers
     *   Other candidates – Need to be explained by clear use cases
        *   Frequency (Xi)
        *   Energy efficiency (Xi)
        *   Signal id (Dragos)
        *   Oper/Admin status - There is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers

Next meeting the focus will be on use cases and associated attributes required in a topology model for microwave.

/JonasA

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 20 april 2020 12:15
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-20

Hi all,

Participants:
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Due to poor attendance we decided to cancel the meeting this time.
Instead, we will hopefully meet again next week, Monday  April 27, 12.00-13:00 (CEST)

Regards
JonasA

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 6 april 2020 13:49
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-04-06

Hi all,

Participants:
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Please remember that next Monday is Easter Monday and our next meeting is April 20

Meeting discussion:

  *   Walk through of the YANG model sent out by Stephen. See attachment.
     *   The key concept discussed was the association with the RLT interfaces, rlt-interface-path, using an yang:xpath1.0 expression.
     *   The meeting agreed with the suggested approach.
        *   Both the rlt-interface-path and the microwave specific attributes in the topology model can exist at the same time.
        *   The duplicated information in the topology model should always be derived from the interface model, if rlt-interface-path exists
        *   To be decided upon at out next meeting to allow for the rest of the team to review
     *   Other comments:
        *   ct-interface-path is actually not required since they can be reached via the rlt-interface-path and the attribute lower-layer-if
        *   How should a situation be handled when 2 devices provide inconsistent link information, e.g. different bandwidth info?
  *   Next step:
     *   Focus on which microwave related attributes to be included in the topology model
        *   Is there any radio link or carrier attributes required in the topology that are not already included in the interface management model?
        *   See also open topics below


Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Xpath as a reference to RLT interfaces. Pending review & comments from the rest of the team
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
        *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
        *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
        *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio



  *   Provider-id/client-id/te-topology-id
     *   Use case TBD



  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label



  *   Admin & Oper Status in te-topology
     *   Refers to the status of a te-link
     *   Use case: TBD
     *   There is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers in the interface management model.



  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?


  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies

/JonasA





From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 31 mars 2020 08:23
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-30

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Italo Busi
Scott Mansfield
Stephen Cheng
Jonas Ahlberg


Meeting discussion:

  *   Alignment of RFC 8561 Microwave Interface YANG with the topology model - node-instance-identifier and duplication of information in multiple models (interface & topology)
     *   Information in multiple models (alignment issue)
     *   Use node-instance-identifier (or alternative approach) to reference another model where the info resides
        *   Stephen to write an example of what it could look like – Yang Model
        *   If reference is not available – Allow for population of the data in the topology model itself
        *   Can be made conditional depending if the interface model exists or not
        *   Would have been simplified if the interface management model had been structured with groups
        *   The complete interface management model could be referenced
     *   A description of the associated behavior in the different data stores – both read-only & write
        *   Running/operational datastores
        *   Alignment of duplicated information???
     *   Is there any radio link or carrier attributes required in the topology that are not already included in the interface management model?
     *   Discussion to be continued based on the proposal from Stephen.



  *   Admin & Oper Status in te-topology
     *   Refers to the status of a te-link
     *   Use case: TBD
     *   There is a need to describe how such attributes on a topology level relate to the admin/oper status of the radio link and carriers in the interface management model.
     *   Discussion to be continued.


Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
        *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
        *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
        *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?


  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio



  *   Provider-id/client-id/te-topology-id
     *   Use case TBD



  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label


  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies


/JonasA




From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 23 mars 2020 15:38
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-23

Hi all,

Participants:
Daniela Spreafico
Dragos Dosan
Scott Mansfield
Xi Li
Jonas Ahlberg


Meeting discussion:

  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio links & carriers
        *   Is the concepts relevant for anything else than a traffic engineered layer?
        *   Is maximum bandwidth reduced by the bandwidth allocated to TDM a relevant case?
           *   Why treat TDM different from other type of higher layer services/topologies?
        *   Agreement that reserved and un-reserved bandwidth are not relevant for a microwave radio link layer



  *   Is there any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant to model for a radio link?
     *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
     *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
     *   Amy to explain if/how it is used in the ETSI plug-test - To be confirmed after that



Summary of conclusion:

  *   Generic attributes
     *   A matrix of availability and associated bandwidth information to be added on the link level
  *   Microwave radio link attributes
     *   Maximum bandwidth is required - equal to capacity that can be provided when the highest modulation & coding is used
     *   Current bandwidth is required - equal to capacity that is provided by modulation & coding the system is currently operating in
  *   Not yet decided
     *   Any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant?
     *   Augmentation of network-topology or te-topology?

Other open topics:

  *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
     *   Use cases?
     *   Relevant for a topology model or the interface model?


  *   Frequency/carrier info
     *   Use case: TBD
     *   Treat this information as specific to microwave radio



  *   Admin & Oper Status
     *   Use case: TBD


  *   Provider-id/client-id/te-topology-id
     *   Use case TBD



  *   Carrier id/label
     *   Use case: TBD
     *   Relation to the interface id/label


  *   From previous meetings/mails
     *   Co-existence with the modelling of other L1 technologies
     *   Alignment of RFC 8561 Microwave Interface YANG with the topology model - node-instance-identifier
     *   Duplication of information in multiple models (interface & topology)


/JonasA



From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 16 mars 2020 12:00
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-16

Hi all,

Participants:
Amy Ye
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Jonas Ahlberg

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level


  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   Is it OK that the model augments network-topology???
        *   Availability/bandwidth information is relevant for a microwave link in general, not only when setting of te-paths, e.g. when setting up L2 bridged services, documentation of planning/config, … - Confirmed
        *   Is the scope of te-topology module to support all types of topologies or is it limited to te-topologies only? – To be confirmed once we have a complete picture of what needs to be modelled for microwave.



  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio links & carriers????
        *   Is the concepts relevant for anything else than a traffic engineered layer?
        *   Is maximum bandwidth reduced by the bandwidth allocated to TDM a relevant case?
           *   Why treat TDM different from other type of higher layer services/topologies?
        *   Bandwidth utilization is a dynamic performance counter and not the same as reserved/un-reserved bandwidth
        *   To be confirmed at next meeting



  *   Is there any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant to model for a radio link?
     *   Any use cases or examples on when any of the other bandwidth attributes are relevant/required for microwave radio link?
     *   If none, then we can conclude that it is only a single bandwidth attribute that is relevant from te-topology.
     *   To be confirmed at next meeting



  *   Other open topics:
     *   Bandwidth Utilization – PM data – How to capture this in a model? Already supported in other models?
     *   How this information relates to existing leafs in the te-topology model remains to be understood.


Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 5 mars 2020 13:10
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-03-05

Hi all,

Some notes from the CCAMP Microwave Topology meeting this week.
From next week we will run the meetings on Mondays, the same time, starting March 9.

Participants:
Dragos Dosan
Daniela Spreafico
Scott Mansfield
Stephen Cheng
Xi Li
Jonas Ahlberg

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level


  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   Is it OK that the model augments network-topology??? – To be confirmed at next meeting
        *   Availability/bandwidth information is relevant for a microwave link in general, not only when setting of te-paths (i.e. te-topology), e.g. when setting up TDM, documentation of planning/config, …
        *   Is there any drawbacks with augmenting network topology



  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
        *   Assume a link with dynamic modulation & coding:
           *   Max bandwidth is equal to capacity that can be provided when the highest modulation & coding is used (based on configuration, not equipment capability)
           *   Current bandwidth is equal to capacity that is provided by modulation & coding the system is currently operating in
     *   It was also decided that it is enough to model this for the link level
     *   Reserved & un-reserved bandwidth is not relevant modelled for a microwave radio link????
        *   To be confirmed at next meeting



     *   Other open topics:
        *   Utilization – PM data
        *   How this information relates to existing leafs in the te-topology model remains to be understood.
        *   Is there any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant to model for a radio link?


Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 3 mars 2020 08:50
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-27

Availability / Bandwidth information
Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service

  *   What information to model?
     *   It was decided to model a matrix of availability and associated bandwidth on the link level (radio link)
     *   It was decided not to model this on the channel/carrier level, unless a use case is identified/defined that that requires this information.
        *   Link level is enough for the service use case
        *   Carrier level is not enough for “calculating” the resulting availability on link level


  *   How to make it available to higher layers?
     *   It was decided to make it generic and create a separate module that can be reused by any technology in the MW-draft
     *   If the model should augment te-topology or network-topology remains to be agreed upon
        *   Is this information only relevant for te-topologies or not? Might also be useful for L2 topologies (not IP/MPLS TE)
        *   Is availability/bandwidth relevant to model in network-topology or only on te-topology?
        *   Up & down sides of the two options need to be understood - …
        *   It is related to how we decide to model bandwidth in general for a microwave radio link



  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   It was decided that the maximum bandwidth in perfect conditions (max-link-bandwidth, Nominal bandwidth, …) and current bandwidth (state) should be modelled.
     *   It was also decided that it is enough to model this for the link level
     *   How this information relates to existing leafs in the te-topology model remains to be understood.
     *   Other open topics:
        *   Is reserved & un-reserved bandwidth something that should/can be modelled for a microwave radio link?
        *   Is there any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant to model for a radio link?


Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

It was also decided to change the meeting time to Mondays, the same time from next week (March 9) and onwards.

/JonasA

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 20 februari 2020 12:16
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-20

Hi all,

These are the notes for CCAMP Microwave Topology meeting:

Participants:
Daniela Spreafico
Scott Mansfield
Xi Li
Dragos Dosan
Amy (Min Ye)
Jonas Ahlberg

It was decided to keep the current day & time for the future meetings.

Availability / Bandwidth information

  *   Use case: Information that should be possible to consider in the process of selecting a path/link when setting up connectivity or a service
  *   What information to model?
     *   There is a need to model a matrix of availability and associated bandwidth on link level
     *   There still might be a value of model it also on a carrier level
  *   How to make it available to higher layers?
     *   A few options:
        *   Keep it specific to microwave and leave the question for future discussions/drafts
        *   Make it generic
           *   A separate draft
           *   A separate module in the MW-draft
  *   What bandwidth information should be used for the bandwidth attributes for a link?
     *   Current bandwidth (state) – On link and carrier levels
     *   Nominal bandwidth (config)
        *   Maximum in perfect conditions
  *   The above to be confirmed / agreed by next meeting (Feb 27)


  *   Other topics:
     *   Reserved & un-reserved bandwidth
        *   Is this something that should/can be modelled for a microwave radio link?
     *   Is there any other bandwidth information in te-topology than “nt:link/tet:te/tet:te-link-attributes/tet:max-link-bandwidth” that is relevant to model for a radio link?
  *   The above to be discussed at our next meeting and/or in mails before that.

Frequency/carrier info

  *   Use case: TBD
  *   Treat this information as specific to microwave radio

/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Dragos-Iulian Dosan
Sent: den 13 februari 2020 16:43
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-13

Hi all,

These are the notes for CCAMP Microwave Topology meeting:

Participants:
Daniela Spreafico
Italo Busi
Scott Mansfield
Xi Li
Dragos Dosan

Discussed topics:

  1.  Change meeting day
Please reply if someone cannot attend to this meeting on Thursdays. Changing the days is doable, but not the hour since currently this meeting time is set for 05:00 for Scott and 23:00 for Stephen.


  1.  “Link-availability” for mw-topology
Starting from Jonas’s example [see attached JSON example], I formulated another example where the ‘link-availability’ I a property only o the Radio Link, there is no need for “availability” for channels [see attached .pptx].
I discussed with my colleagues and also friends working for various telecom companies, and the main used tool for radio planning is called Pathloss (http://www.pathloss.com/<https://protect2.fireeye.com/v1/url?k=0f162ba0-539ff18c-0f166b3b-0cc47ad93da2-3cf9d97c48ba66ed&q=1&e=f2199b22-bae2-4307-93a2-368cf41f44b5&u=http%3A%2F%2Fwww.pathloss.com%2F>)thloss.com%2F>). This application is delivering the “availabilities” per ‘Link’, regardless of the ‘link’ type [1+0, 1+1HSB, 1+1SD, MIMO, XPIC etc…]. Actually things are a bit more complicated, but bottom of line is the fact that the “link-availability” and “channel-bandwidth” is give per overall Link.

Other personal observations:

  1.  Propose to change the “mw-channels” with “mw-carriers” [aren’t they the same thing?] -> alignment with rfc8561.
  2.  The way the XPIC link is modeled in rfc8561 [one link with 2 carriers] is making things complicated when modeling this kind of link in upper layer models: actually from traffic point-of-view, the XPIC represents 2 parallel links using same medium.

Looking forward for your comments and ideas.

Regards,
Dragos D.



From: Jonas Ahlberg <jonas.ahlberg@ericsson.com<mailto:jonas.ahlberg@ericsson.com>>
Sent: Thursday, February 6, 2020 1:11 PM
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-06

Hi all,

The meeting continued the discussion about the different options for how to model a microwave topology, but did not reach a conclusion since the participation was too low.

There was also a discussion about how to make the availability information for a channel available to higher layers.
An example is attached, showing an instantiation of a model were a generic link attribute has been added to the network-topology model.

The example also shows a situation with two availability levels and associated bandwidth for each channel, which also have been aggregated to the link level.
That raises a new question. What availability level should be the basis for the bandwidth attribute for a link.
Let’s discuss over mail and at our next weekly meeting.

I will be on vacation next week and will not call in, but the webex meeting will be open for the rest of you.

Regards
JonasA



From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 3 februari 2020 13:29
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-01-30

Hi all,

The meeting agreed with the suggested way forward as proposed in the summary below, “Notes: Microwave Topology - 2020-01-23”.

The 1st step is to create example instantiations in JSON for the three different options.
We agreed to use the configuration in Appendix A.2. in the current draft, draft-ye-ccamp-mw-topo-yang.

Attached are:

  *   A powerpoint slide with a picture of the configuration, “IETF Topology - JSON example”
  *   A draft of an instantiation based on te-topology, “JSON example - te-topology”
  *   A draft of an instantiation based on network-topology, “JSON example - network-topology”

We will continue to evolve these drafts and use them as a basis for the decision on model approach as described in step 2 in the summary below.

/JonasA

From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 23 januari 2020 16:58
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP] Notes: Microwave Topology - 2020-01-23

Hi all,

This is an attempt to create a high level summary of the discussions/conclusions about the microwave topology model that hopefully can help us taking a step forward.
What are the key conclusions, which are the main questions that remain to be resolved and what are the options for modelling a microwave radio link layer.

There is a difference between microwave and most other technologies.

  *   Microwave is a link-by-link technology, not a network technology
  *   It is not possible to switch/route/cross-connect traffic on the microwave radio link layer. It is always done on higher layers, e.g. on Ethernet or TDM layers.
  *   Therefore, concepts such as “Node Connectivity Matrix” and “Local Link Connectivity” are not applicable

Two use cases have been analyzed:

  *   Provisioning of bridged L2 services (E-LINE) across an Ethernet topology
  *   Provisioning of L3VPN services across an IP/MPLS (TE) infrastructure
The main conclusions from that analysis are:

  *   The microwave radio link information is not used directly in the process of selecting the path/resources to be used for the service. Instead, the process uses information in the Ethernet and LSP layers respectively.
  *   How the microwave radio link information can be made available to those higher layers remains to be understood and clarified
     *   If there is a corresponding attribute in the higher layer topology model, then the PNC can update that attribute based on information in the supporting microwave radio link layer (e.g. bandwidth). If there is no corresponding attribute, then changes have to be done to the higher layer models and/or the functionality of the PCE (e.g. availability).
     *   The mapping/aggregation of microwave radio link information to higher layers requires intelligence (SW-code) in the PNC and cannot be derived from the model. An example is the calculation of the resulting availability on a higher layer link that might be composed of a number of different underlying microwave radio links, each based on multiple channels in protected and/or bonded configurations.

There are a few options for how to model microwave radio links.

  *   Augment ietf-te-topology (currently used in draft-ietf-ccamp-mw-topo-yang)
     *   Only a small subset of the complete model is relevant
     *   Focus should be on clearly describing which parts are relevant and which parts are not applicable, using textual descriptions and examples of instantiations.
  *   Augment ietf-network-topology
     *   Extending a basic model
     *   Attributes that already exist in ietf-te-topology might need to be added as microwave specific extensions.
  *   Multiple augmentation ietf-network-topology + ietf-te-topology
     *   Augmenting network-topology with microwave specific extensions
     *   Use multiple augmentation and include te-topology when required

Some questions related to the attributes to be included

  *   In the te-topology model there are already generic attributes for max-link-bandwidth and unreserved-bandwidth. Why do we need to add microwave specific attributes for bandwidth and unreserved bandwidth? Why can’t the generic attributes be used also for microwave?
  *   Is there a way for a PNC to keep track of the unreserved bandwidth of a microwave radio link when the allocation is done on higher (possibly multiple) layers. What does it really represent?
  *   In RFC 8330, availability level and associated bandwidth is introduced as a generic (technology independent) concept (for OSPF-TE).
Should we follow that approach of making it generic also in the modelling of topologies or is there a reason for making it microwave specific?
  *   To what extent should the topology model align with RFC 8561. Can we assume that a PNC implements both a topology model and RFC 8561, or should the topology model provide an alternative to RFC 8561 for configuration of the interfaces/termination points?
  *   There is a need to illustrate how the rw-leafs for a channel is supposed to be used for configuration/re-configuration.


Suggested way forward:

  1.  Extend the example in draft-ietf-ccamp-mw-topo-yang to a complete instantiation of all relevant parts of the te-topology

Create corresponding examples for the other two options based on ietf-network-topology & multiple augmentation


  1.  Evaluate the options and decide which one to use



  1.  Define and justify which microwave specific attributes/leafs the model should be extended with


/JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 9 januari 2020 16:02
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] Microwave Topology - 2020-01-09

Hi all,

Notes from today’s meeting.
This is based on my own understanding/interpretation of our discussion. Please add any missing or incorrect information.

Use case 2: Provisioning of bridged Ethernet services

  *   Based on ETSI microwave plug-test use cases
  *   In the plug-test, the underlay concept is used to describe the relationship between the Ethernet layer and the microwave layer, whereas the supporting link is the approach used in the draft-ye-ccamp-mw-topo-yang.
     *   There is a need to clarify which approach is the correct/best
  *   Path computation is performed on the Ethernet layer and uses only information provided by that layer
  *   The microwave layer need to provide information that might be of interest for path computation, such as bandwidth and availability.
  *   How that microwave information can be made available to the Ethernet layer (and thereby the PCE) remains to be understood
     *   If there is a corresponding attribute in the Ethernet topology, then the domain controller can update that attribute based on information in the supporting microwave layer
     *   If there is no corresponding attribute in the Ethernet topology, then changes have to be done to the Ethernet topology model and/or the functionality of the PCE. But this is outside the scope of this work.

There was a discussion about possible future extensions:

  *   Point-to-multipoint implementations
     *   Is there any implementations within the industry today that we can refer to?
     *   Is the connectivity managed on the radio link layer or on higher layers, e.g. on the Ethernet layers as in implementations 10-15 years ago?
  *   IAB – Integrated Access Backhaul
     *   A new protocol (layer?), BAP, is introduced to manage the connectivity in a multi-hop IAB network.
     *   Does this really change the previous assumption that microwave is only a link-by-link topology and not a  network topology?
     *   Is IAB within the scope of our work?

Next step
A suggestion:

-          I think there are communalities in the findings from the two use cases. Let’s summarize them in a good way.

-          Based on that, let’s start to draw conclusions and define requirements for what a microwave topology model need to support.

Regards
JonasA


From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> On Behalf Of Jonas Ahlberg
Sent: den 19 december 2019 13:16
To: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>; ccamp <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] Microwave Topology - 2019-12-19

Hi all,

Some notes from the meeting today.

We had a short discussion about the IP/MPLS (TE) L3VPN use case. The detailed information provided by Stephen need to be further explained/discussed at our next meeting.
We agreed with the conclusion that TE information in L1 microwave topology is not necessary for the proper functioning of a PCE, but we also need to consider other aspects before we decide how to proceed.

  *   We need to understand and draw conclusions also from the remaining two use cases
  *   Other drafts augmenting te-topology (e.g. MPLS-TP, OTN and WSON) are network technologies in that sense that paths/tunnels can be created using links and connectivity matrices from within that single te-topology. Microwave is not a network topology in that sense. It is only a “link-by-link topology” since paths/tunnels can only be created on higher layer topologies, e.g. TDM and Ethernet. How should this affect the choice of basis for a microwave topology model?
  *   How to take care of future use cases that might require te-information? Does it really impact the choice today?
  *   …


Next meeting is planned for Thursday January 9, 11-12 CET.

Merry Christmas & Happy New Year.

/JonasA

-----Original Appointment-----
From: CCAMP Working Group <ccamp-chairs@ietf.org<mailto:ccamp-chairs@ietf.org>>
Sent: den 3 oktober 2019 12:00
To: CCAMP Working Group; ccamp
Subject: [CCAMP] Webex meeting changed: Microwave topology
When: Occurs every torsdag effective 2019-11-14 until 2020-06-04 from 05:00 to 06:00 (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna.
Where: https://ietf.webex.com/ietf



CCAMP Working Group changed the Webex meeting information.


When it's time, join the Webex meeting here.


Meeting number (access code): 647 343 270

Meeting password: D7dhCJpZ


Occurs every Thursday effective Thursday, November 14, 2019 until Thursday, June 4, 2020 from 5:00 AM to 6:00 AM, (UTC-05:00) Eastern Time (US & Canada)
5:00 am  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr



Join meeting<https://ietf.webex.com/ietf/j.php?MTID=ma65a6a5186962890ec535e711ec3d3f9>



Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-3208<tel:%2B1-650-479-3208,,*01*647343270%23%23*01*> Call-in toll number (US/Canada)
1-877-668-4493<tel:1-877-668-4493,,*01*647343270%23%23*01*> Call-in toll free number (US/Canada)
Global call-in numbers<https://ietf.webex.com/ietf/globalcallin.php?MTID=m57c83575d64804b110f94f798d438720>  |  Toll-free calling restrictions<https://www.webex.com/pdf/tollfree_restrictions.pdf>



Need help? Go to http://help.webex.com


This email message and any attachments are intended solely for the use of the addressees hereof.
This message and any attachments may contain information that is confidential, privileged and exempt from disclosure under applicable law.
If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission.
If you have received this message in error, please promptly notify the sender at Ceragon by reply E-mail and immediately delete this message from your system.