[CCAMP] Notes: Microwave Topology - 2020-02-06

Jonas Ahlberg <jonas.ahlberg@ericsson.com> Thu, 06 February 2020 11:11 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 CC66112023E; Thu, 6 Feb 2020 03:11:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 QTRpCzXZ-BiO; Thu, 6 Feb 2020 03:10:59 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::631]) (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 A2D9112025D; Thu, 6 Feb 2020 03:10:58 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QRSva16t0bbREJxcaqtXMDNqj4aH8vPEtA8CbfDSeiN2APCckt2mw2sWdCPapg9OQzfa1dux35G5vsC2V8PcP4WGnt+uacZbkgX2czkYTQjdVJ5Q3Nqfh3bLZYtPlmpJRYCzpNNz+kER44LwXx/lCMdMkXJDNZemHm16dnvO5Jr6phGAI263EVDU5uibqNbvRyDy/b3ufey4YNTSwjKIuudQeb5Zsm8vha1ZLrHBwjRD/RzCPD1i0xSrayC15w7X0kt3nlZwCeJUUrO2ZTaL3zsVG8ytjuuR/vNd94+IyucGee37lJrcEh5X5niKf34bCLrhQqw2miX0FWLm0hVMAA==
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=EMlKFyHfuyTg0nl9yBMJq6jhe3KkxFh4Q7BmtgSaNY0=; b=WhK8la0/5GfgsRQ7ZbpCn+RYcDOgh7G0TQMotamfq1fWa6eV9rvag0UQ6Hnh/Cqyu7by0cFiZU8/YflFddPZ/3ZOb/EGc4E36TgtrfYFAeAmweOk+m/ktR2lESKSaT49zNTO1D2RPC+7apRnzRk+2q3ROm4vfpyqPVy29/RXsktzYgOY9ctGiVx0RiDxOPfo7JLBGQu1F3d4js29AZzvc30YzBai8hudi+JpftFMwrQ2ZirVesxu1r4LNtbUNs4uLseampDKi2QyWoSjmWGIjvy4D6lSN8+scfn4cu1rEH0ElIOvzG8Tr4kY/mDdDXSVDAqcJe+j5U+gYdhi+WsZpg==
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=EMlKFyHfuyTg0nl9yBMJq6jhe3KkxFh4Q7BmtgSaNY0=; b=p0mPRKXk57eMyX/+WBfSEFUNttnHQn3dKIBx7rX1Xhk+bqFrUkH0/M0Bj6a3TGQt1hE7rHannqF3EaEE6GVNTryyGib2QeGnROWJn/23Jf0NEvQiZDALsxkHVSUqhSE4UMlLbWNlvVbz8vmY4/5dgXgbNeIUL0B086JtHQgT+7Y=
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com (52.133.50.20) by AM0PR0702MB3809.eurprd07.prod.outlook.com (52.133.47.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.12; Thu, 6 Feb 2020 11:10:55 +0000
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::d514:a4d7:de14:1baf]) by AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::d514:a4d7:de14:1baf%6]) with mapi id 15.20.2707.018; Thu, 6 Feb 2020 11:10:55 +0000
From: Jonas Ahlberg <jonas.ahlberg@ericsson.com>
To: CCAMP Working Group <ccamp-chairs@ietf.org>, ccamp <ccamp@ietf.org>
Thread-Topic: Notes: Microwave Topology - 2020-02-06
Thread-Index: AdXc3hnO6UE3ABcYSaGIhVFGr0asug==
Date: Thu, 6 Feb 2020 11:10:55 +0000
Message-ID: <AM0PR0702MB3537FB8DB37027AD0032DB6C891D0@AM0PR0702MB3537.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jonas.ahlberg@ericsson.com;
x-originating-ip: [85.194.6.238]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5346eefc-650f-4ecf-3ee6-08d7aaf53ca4
x-ms-traffictypediagnostic: AM0PR0702MB3809:
x-microsoft-antispam-prvs: <AM0PR0702MB3809CEED833FA14FE3413C01891D0@AM0PR0702MB3809.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0305463112
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(366004)(346002)(376002)(39860400002)(189003)(199004)(2906002)(55016002)(76116006)(66946007)(4001150100001)(9686003)(16799955002)(450100002)(64756008)(66616009)(66476007)(66556008)(71200400001)(66446008)(52536014)(33656002)(5660300002)(86362001)(110136005)(30864003)(6506007)(53546011)(7696005)(8676002)(81156014)(81166006)(186003)(19627405001)(26005)(8936002)(478600001)(966005)(44832011)(316002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0702MB3809; H:AM0PR0702MB3537.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rfasagIuxUPLOpANGrm4aPGCzeWwGz9qti1+e0tDNd2ORnPBwjsgaLymhqt7ryY7WwmRfIap4pzETNVB75F3ErR/44lAx7B/wwaE/ShyyxA8NULJuF82VeB+lHd9LBHj1rtPSAlxMtyR2bxu935IDZNttSkwaadMb3NfSf4MT4D2tOIo1G8ULt6b4Yh5t6D/SASSsRgKEcyAy1j21Suk0iEPGHQwK7qjgEj1CZeaa1dR9/nC6SkDlAxna5Xv0HI1gxSD1aRzNoSCXsGWctjG2oDXl44OK9AoI1LyGGLXM/Tm+QNQ/Xbc/q82GJspKTvBPRfu87U4WFZXZCHWAwkxwOoRZ9p8mSFzM0I8vX29YPVzodtoEnEa4EiYxEhlrcLDtd0s6kgeCxq14I9rnRLrdVV8Hv+0h/OY8qjH5wv1jFzIHGNCQLvDcOal06g3PQ7m2BPlYwmicHApqxCAfvSYLusox4leE7A8JUcg/ULBE3ImpK/9r3nqQ62axacpwVtG+CkxBJvGMzoy+WBzrWafkA==
x-ms-exchange-antispam-messagedata: wcxv+CbSLPcVRVl9zvzGdTVjbT9OPo8klx2OOuVAl24WKsx8wCgpup54F1SGIP8Vgydn1omebs3uvbER5oDLJ4iAvt6HLudxLwHrF38DkF8vFhd9WiVYk0DyRSYEkznpjQTraHo+5W+K5bii2B8EpA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/mixed; boundary="_004_AM0PR0702MB3537FB8DB37027AD0032DB6C891D0AM0PR0702MB3537_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5346eefc-650f-4ecf-3ee6-08d7aaf53ca4
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 11:10:55.6681 (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: OCSCHtWSo/XLy/uL6aWkCExdcni67kDAlNZn3Qs0TFSB0LLgEUIxySYkyHy1Y2tQsUJmXRlKi1r7EIZ45Zupyl+Q67tPNXx/fHCe9VIXcFs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3809
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/XHnPvrLbZjl8fGNl9fQZK4tB2bs>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-06
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: Thu, 06 Feb 2020 11:11:04 -0000

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> On Behalf Of Jonas Ahlberg
Sent: den 3 februari 2020 13:29
To: CCAMP Working Group <ccamp-chairs@ietf.org>rg>; ccamp <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