[CCAMP] Notes: Microwave Topology - 2020-01-23

Jonas Ahlberg <jonas.ahlberg@ericsson.com> Thu, 23 January 2020 15:57 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 DA42C120118; Thu, 23 Jan 2020 07:57:58 -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 Wd2mmIidIHDF; Thu, 23 Jan 2020 07:57:54 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70083.outbound.protection.outlook.com [40.107.7.83]) (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 D49ED120113; Thu, 23 Jan 2020 07:57:53 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dP7A6o+gs3HproPpIbf3zrjxC4flXCDa/X6D9bG0SAD6ck8z47rqGJbsbazbyyXhYoUILJTwptWlChEb8YH31UKklROvQUlh/fuXJZr1keFe+e/9UVmE6gu9SELBzOPt4Syn0dbJ2wAmZgUh0K7qsYbXwzU7MApyUNJ2oleOE9yKqieEze2GwCScZQ3s5gKYcl26vFNI5dDAdsdilxkDluHC4CFE4luQPwgy8WFCmxja+OzF6BvGCKrVbUVsyn3/qCwAizPTexliHL8CYIw75z6KlJmryAgVJ/oC+BplHAZ/CPUw7D5diAOYn1fU/t7Q1SWggf5FZEVodagtjPta4w==
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=5JDwusOH+H46cqzlhJnJQRfk5lMvEcyF05cLZSPZygc=; b=IM/XJcrA/lIitwDKssJufIWP4JInR4EAD6tfRsSOvD8b1oDzmjPfmQggbIfIXYR5Hgg86h15tAD8By359l90xEVpNfyYIEqCWija6p7PM0qR+t1NNFfOvhTuPpowv+l+IZqX89aSCTSxVjYjLxfnTlgVil2J115pyEGufadTqg1Fp2yQEL4nic1JDAar7RPrP2SBt+MnV3WMCFyoPo189HOJihhdcYBQWH2IS3udR7/4nCpadNUmE5NwdVGLqIZ7M9jRDMh/wu43keiEInaQcZgIwLkpy4R+8O1sV9jbr1sSGNwO/aJ2x5KLqoh9+Asmi9LBUmo1cQEsZm0dNrR1jA==
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=5JDwusOH+H46cqzlhJnJQRfk5lMvEcyF05cLZSPZygc=; b=Bf8wtSO8aTnyVLidZKLYMNH/LQ0DovLHoESz+w2KoZMmyl1dxXsOGj8wlLbo9KvUO+1qEhUatGg3vdoXYD9W+rEcCvKJTzGyOAjc/L0i2CCdvNHn45J3o/iP3ncq63k6Lsr9WkxWozbWYuV8gB/sJgF4aZBbf5Djwb3YVeSYmHo=
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com (52.133.50.20) by AM0PR0702MB3553.eurprd07.prod.outlook.com (52.133.44.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.14; Thu, 23 Jan 2020 15:57:51 +0000
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::5dff:76dd:67e6:8e7f]) by AM0PR0702MB3537.eurprd07.prod.outlook.com ([fe80::5dff:76dd:67e6:8e7f%7]) with mapi id 15.20.2665.015; Thu, 23 Jan 2020 15:57:51 +0000
From: Jonas Ahlberg <jonas.ahlberg@ericsson.com>
To: CCAMP Working Group <ccamp-chairs@ietf.org>, ccamp <ccamp@ietf.org>
Thread-Topic: Notes: [CCAMP] Microwave Topology - 2020-01-23
Thread-Index: AdXR9zLsjPg6583tSkqlzIwq8PjBMw==
Date: Thu, 23 Jan 2020 15:57:51 +0000
Message-ID: <AM0PR0702MB3537E780EC064AFAE323735E890F0@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: 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: 0b51d3c9-4dcb-4865-4c6c-08d7a01d001a
x-ms-traffictypediagnostic: AM0PR0702MB3553:
x-microsoft-antispam-prvs: <AM0PR0702MB355384D98E6473046C51D229890F0@AM0PR0702MB3553.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 029174C036
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(39860400002)(396003)(376002)(136003)(199004)(189003)(33656002)(2906002)(110136005)(19627405001)(86362001)(316002)(4001150100001)(76116006)(66556008)(64756008)(52536014)(66946007)(478600001)(66446008)(5660300002)(66476007)(450100002)(966005)(9686003)(55016002)(8936002)(81156014)(81166006)(8676002)(16799955002)(44832011)(71200400001)(26005)(186003)(7696005)(53546011)(6506007)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0702MB3553; H:AM0PR0702MB3537.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: 4oS+FAZObEyUpyAUK8VBPFSLttbaDJomW0kJlHLEooPn7wBjouYe+p7WvnzBGwdiuvJOkliak7qJXRQoOY9pbiih6EQQdMkCnjSApWSCliefI82b2QrYTZozAGyabWggSdYROc2REeTS/hIY3TMlapo/fCuOm4VVQ5qoN3RRsFavq+XnisPjQU6hzj+xDNwzyRcvrLaUBkcXzjau+CxMY7wWh3znrjGdeVrvHE5Uk/8C+O0F24RIza2jK6f4w0HvzvEIe8XyAT+hhAV8EVryCxuCSWIKcUab8kYJMjx8EHl7fYHSdQB3Wo4Pnr488/Ca06I5vI7tBybwXPkMcNkQ4INKC/S+Clh75dToS4FZpUksJjn+KOJrqnE/KseBdnr0kbeRfivYm8hjKLrCVtD/yqM+md1OSsfSviWIuJpDCZa8E3TfM7M8C3gb4zy10J6Jx7SMpoPhUiPFXLrq7vImrZ95jgc5S1N1xSdubXWjYts=
x-ms-exchange-antispam-messagedata: NcNyKqylc5wntJKrdoKQrREsl/Et6onUNNQaOsSjOg8lkFVpgPg6m1rh3T8Jk1MhZZEerIIA2nJTUoDn5uW/m6tIkl+0TOMmjplQiOiVMSdqaeSNEjEjZs/k1L3hCMbUinvFgB0ZANxH2jJ4Cj7HEw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB3537E780EC064AFAE323735E890F0AM0PR0702MB3537_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b51d3c9-4dcb-4865-4c6c-08d7a01d001a
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 15:57:51.0944 (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: dLi35QWkvx6ht1zFBuWIFVF+sF14GO3RmS/Af80DijdpahC5BMbgI2xx6AArrgGsiYXmTpBiqnblkiFJW/esA7SwycTUrQtWPU9FIj6PfLg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3553
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/DokDSOTVALFw3hJOJnzp-sI5RN4>
Subject: [CCAMP] Notes: Microwave Topology - 2020-01-23
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, 23 Jan 2020 15:57:59 -0000

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