Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
Dieter Beller <Dieter.Beller@nokia.com> Mon, 23 May 2016 14:44 UTC
Return-Path: <dieter.beller@nokia.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B456A1200A0 for <teas@ietfa.amsl.com>; Mon, 23 May 2016 07:44:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.187
X-Spam-Level:
X-Spam-Status: No, score=-6.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 BnMsbB9XGDgF for <teas@ietfa.amsl.com>; Mon, 23 May 2016 07:44:12 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7D7C112B064 for <teas@ietf.org>; Mon, 23 May 2016 07:44:11 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 84FEFE0FCBF2E; Mon, 23 May 2016 14:44:06 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4NEi7HD026448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 May 2016 14:44:09 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4NEhxpp016466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 May 2016 16:44:03 +0200
Received: from [149.204.106.226] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 23 May 2016 16:43:45 +0200
To: Igor Bryskin <Igor.Bryskin@huawei.com>, Cyril Margaria <cyril.margaria@gmail.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>
References: <02d101d1af76$b0317cd0$10947670$@gmail.com> <CADOd8-ueX_DJc-kZwNXjuu964vXAXWm=HOHGZY2ML74ok4g6=Q@mail.gmail.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB0A@dfweml501-mbx> <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com> <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx>
From: Dieter Beller <Dieter.Beller@nokia.com>
Organization: Nokia
Message-ID: <77293aff-c53d-3043-7d24-b9c95f2ac776@nokia.com>
Date: Mon, 23 May 2016 16:43:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/u1O0DlxflkR1ZDAKQWoElQFf50E>
Cc: TEAS WG <teas@ietf.org>
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 14:44:14 -0000
I am confused - maybe something we can clarify during our TEAS call today that will start in 15min.
Thanks,
Dieter
Dieter,
Your understanding is correct, and it does not contradict to what Cyril is saying. For example, a connectivity matrix in the OCh layer must provided on a lambda (not link) level. Likewise, as we discussed, in the OTN/ODUk layer the connectivity matrix entry should be specific, generally speaking, to ODU type. As you see, this has nothing to do with the inter-layer relationships.
Cheers,
Igor
From: Dieter Beller [mailto:Dieter.Beller@nokia.com]
Sent: Monday, May 23, 2016 10:06 AM
To: Igor Bryskin; Cyril Margaria; Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
Hi Igor, Cyril, all,
fixed client to server mappings is s multi-layer aspect if I'm not wrong.
I thought that the connectivity matrix was trying to address abstraction drawbacks within a single network layer, i.e., to provide additional
information that would get lost during the abstraction process (example: srlg information associated with the underlying topology that was
abstracted into a single node).
Thanks,
DieterOn 23.05.2016 15:51, Igor Bryskin wrote:
Cyril,
You are absolutely right. But this belongs to the layer specific augmentations, agreed?
On the other hand I do a see a value in adding an abstract label to the connectivity matrix (just like a label object in the TE path), so the basic model will be more complete to address more than one layer.
Igor
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Cyril Margaria
Sent: Monday, May 23, 2016 9:41 AM
To: Xufeng Liu
Cc: TEAS WG
Subject: Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
Hi,
Another item that can be considered is to add a Label (Following RFC7579) restrictions. This is needed, for example, in case of Fixed muxponders, where the connectivity between the Low order ODUs to the high-order ODU is fixed on each end.
Can it be added to the list of changes for the connectivity matrix?
Thanks,
Cyril
On 16 May 2016 at 09:27, Xufeng Liu <xufeng.liu.ietf@gmail.com> wrote:
Authors and contributors have discussed the use case of abstract topology,
to address the incompleteness of connectivity matrix.
Current connectivity modeling is as follows:
| +--rw connectivity-matrix* [id]
| | +--rw id uint32
| | +--rw from
| | | +--rw tp-ref? leafref
| | +--rw to
| | | +--rw tp-ref? leafref
| | +--rw is-allowed? Boolean
A Link TP may connect or disconnect to another Link TP, without detailed
information such as cost and resource sharing restriction. To get a better
abstraction of such connectivity, the following additional attributes are
planned to be added:
max-bandwidth? decimal64
max-resv-bandwidth? decimal64
unreserved-bandwidth* [priority]
priority uint8
+-- bandwidth? decimal64
+-- te-default-metric uint32
performance-metric // re-use the container from te-link-atrributes
te-srlgs // re-use the container from te-link-atrributes
Comments are welcome.
Thanks,
- Xufeng
_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas" target="_blank" rel="nofollow">https://www.ietf.org/mailman/listinfo/teas
_______________________________________________Teas mailing listTeas@ietf.orghttps://www.ietf.org/mailman/listinfo/teas" rel="nofollow">https://www.ietf.org/mailman/listinfo/teas
- [Teas] Connectivity matrix in draft-ietf-teas-yan… Xufeng Liu
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Cyril Margaria
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Igor Bryskin
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Cyril Margaria
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Dieter Beller
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Igor Bryskin
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Dieter Beller
- [Teas] R: Connectivity matrix in draft-ietf-teas-… Belotti, Sergio (Nokia - IT)
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Igor Bryskin
- Re: [Teas] Connectivity matrix in draft-ietf-teas… Igor Bryskin