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

Jonas Ahlberg <jonas.ahlberg@ericsson.com> Thu, 20 February 2020 11:16 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 2F4011200E6; Thu, 20 Feb 2020 03:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 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, 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 CsaijJN-ySrk; Thu, 20 Feb 2020 03:16:21 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10085.outbound.protection.outlook.com [40.107.1.85]) (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 8DF3D12001A; Thu, 20 Feb 2020 03:16:20 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GVSPWA8xO4TUz1UaYuRjiuXRmGNNQb9L6cwsu54hwMBaZ4UtYVzI611uBob1Z/2OL9evtV0Be8QFHe4TzLMNSuSoj8ZoKFzfvr2iw27aQsSsQpgk3oXwOxk1D3nxSVcn74clPc8Fcm2mkRoFXwNfSNn7CooJMLCoEEZ5jTNqoeZZNDMXplNYtxW0Yq47/WLgd+H1E/A/8UQ40FbNKeEu0iCxMFpyAep6BNHeHVgoSCCjQL07oKNdgCOPJQXK7+rRrfpA51ax6xUqyW2WiDsGQi98k0Jb3a6/pgLul8T+kPEhikKrqwHvN8zlyCMQnPJnf0JGeW3PA6GJ5O/tMOYaqA==
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=zQLafa20zF0Fte96Fnks0YoeWA5bPEvfu8W1hSiJedk=; b=Bc2XU6eGV8h1wOCyOeNGVy2thGpWavbDgCIrZrklng3Lc3AwHY4+ugp1me2P234TyJZOFwkQAfAUWy+sjeAybhyBJ3+MOjRV33RaVHtUtczgnEEpoX2r8dijK4XZiI6ZGk44BxRSFkzljOk3b55skd2HbQKr+K85kabi28p3AKzH+DUu+P4Yl2f9Af4wEGPDd52QREfJ+iXWWPe3PBzQV2zZbDiyMTzVMSx4jlTpiwGHn4vM2BcjljNqnGSSwqVIe6C8syBhkm5mUoXKz8qqyY8sm5+ncUKHJZ7qQkQQAB+wiw1NanFoINf7iWw23O65mfLl0rdX4KXsSr9UUbgrgQ==
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=zQLafa20zF0Fte96Fnks0YoeWA5bPEvfu8W1hSiJedk=; b=YdZCJ2B6mekuef62+8XiS6O7oXa8JCrKGbfUR18UOSx6o0XWlcl+zF8A41nI3gJxuBN8Eq21ut6gdlFLsPLodjNtTzunMViURttWyU3ZCR3aTO5uLaj2iucQlSTCLyYo0EDg/cJuueatdq/NpX39eoPurNwQhG142cufaxG4DKE=
Received: from AM0PR0702MB3537.eurprd07.prod.outlook.com (52.133.50.20) by AM0PR0702MB3569.eurprd07.prod.outlook.com (52.133.48.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Thu, 20 Feb 2020 11:16:17 +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.2750.016; Thu, 20 Feb 2020 11:16:17 +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-20
Thread-Index: AdXn178jEUEw/lFsT2elBZ0tHK1ePg==
Date: Thu, 20 Feb 2020 11:16:17 +0000
Message-ID: <AM0PR0702MB3537DEFF52AAAE33A1F4EA1389130@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: 2eb43e3c-5618-4f08-3dfa-08d7b5f64e64
x-ms-traffictypediagnostic: AM0PR0702MB3569:
x-microsoft-antispam-prvs: <AM0PR0702MB3569012F0ED58DA17679B7F189130@AM0PR0702MB3569.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 031996B7EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(376002)(366004)(136003)(39860400002)(189003)(199004)(33656002)(55016002)(76116006)(52536014)(8936002)(966005)(53546011)(186003)(9686003)(44832011)(6506007)(4001150100001)(110136005)(66946007)(450100002)(66446008)(16799955002)(71200400001)(8676002)(81166006)(26005)(66556008)(2906002)(30864003)(66476007)(19627405001)(5660300002)(81156014)(316002)(86362001)(478600001)(7696005)(64756008)(579004)(559001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0702MB3569; 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: 6BTwcvjK96M3ltDx07f9bLpr0nF3FU0LJy0fb0snLp1JxtfotSOg1rjfikWM8iI1igvtZWqvt6p8el2ZsqLZXSBbVrM3UGckwNRde9pcAUwGiYT1cMabjdqJcJopFL6u1giXt+MbnSq9eXT0nXZx4cCfCEnHXBmlFw4v8oaswJf5lC3Ax5Gcifjb731t/EaG8Hm0NAsgUwgUVZt3ZfcxVGPLDTMZ6AqhWNr9hTJy4ou29V2ijyiC9GfTOpknav16greYAv78CX3Wkn4WmyDrfuUHIEVkaxECRs1qUUtPn8lI3v9LgzQvP/aW7YbJX8+D15vuDDvJdbYWOu9W4SJ+Wk9dTx2RBRFneFBBNkknQocCSib3sMwy5byjScXnhCpfyZgw6gCMWijnDxYyQqy+jw6u52O6avgn3sa6Xs2Hr5XB4KBPZHBuy/s/oNJ/K1wjYfpANwChSheAWFlB7pTb4p0eer/ApldITSOdh2mBplm9mDNe8yTiQqudaVCDIhY/RZUx8OEzmtOnMDrsAteAUQ==
x-ms-exchange-antispam-messagedata: zcmYn7YSg116qura9vZQnXgu3Ci8Mx5s6BoUjImWf936ioG/275Cq5CQWhQoIsrR8KqlVx3YEnNumyb04eA6ZAUF5Fa1V2tFvdQOJ8DWqVHF+wV/wr5iHmx2Vh+W5DlCJAGhoaPuCzkKEtxeoDZ9Tw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM0PR0702MB3537DEFF52AAAE33A1F4EA1389130AM0PR0702MB3537_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2eb43e3c-5618-4f08-3dfa-08d7b5f64e64
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2020 11:16:17.6709 (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: ++JzOQl8+dRMIAnWaKMmTXWJ7JKLeO6Sk1V7fF3rvI3tO/VhFGutUgNXRvl45RNvbRlK6gG7ldGyqA4Fu3PzvT6/fArpDH+6eOhhAP1ttVQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0702MB3569
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/9GGwG6eodpDhoZ822AUztiKILv4>
Subject: [CCAMP] Notes: Microwave Topology - 2020-02-20
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, 20 Feb 2020 11:16:26 -0000

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> On Behalf Of Dragos-Iulian Dosan
Sent: den 13 februari 2020 16:43
To: CCAMP Working Group <ccamp-chairs@ietf.org>; ccamp <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>). 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.