Re: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
Igor Bryskin <Igor.Bryskin@huawei.com> Mon, 23 May 2016 14:25 UTC
Return-Path: <Igor.Bryskin@huawei.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 2E16512D932 for <teas@ietfa.amsl.com>; Mon, 23 May 2016 07:25:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.636
X-Spam-Level:
X-Spam-Status: No, score=-5.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 ZNXog77S9sca for <teas@ietfa.amsl.com>; Mon, 23 May 2016 07:25:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE67D12D937 for <teas@ietf.org>; Mon, 23 May 2016 07:25:22 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CPI59014; Mon, 23 May 2016 14:25:19 +0000 (GMT)
Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 May 2016 15:25:07 +0100
Received: from DFWEML501-MBX.china.huawei.com ([10.193.5.178]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Mon, 23 May 2016 07:25:05 -0700
From: Igor Bryskin <Igor.Bryskin@huawei.com>
To: Dieter Beller <Dieter.Beller@nokia.com>, Cyril Margaria <cyril.margaria@gmail.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>
Thread-Topic: [Teas] Connectivity matrix in draft-ietf-teas-yang-te-topo
Thread-Index: AdGvdpxN0yo8TMwnRjC4jbLnP05ymwFvMywAAA51YLD//5NrAIAAcWJg
Date: Mon, 23 May 2016 14:25:04 +0000
Message-ID: <0C72C38E7EBC34499E8A9E7DD007863908EDCB69@dfweml501-mbx>
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>
In-Reply-To: <551bf645-eeb8-a0aa-ff41-26d1043d8d84@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.253.100]
Content-Type: multipart/alternative; boundary="_000_0C72C38E7EBC34499E8A9E7DD007863908EDCB69dfweml501mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.574312D0.0213, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ab9c02f803473b3c816b6bb401f2f1e5
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/LQ7uV6oY23tnd39l6amux2vM8uU>
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:25:26 -0000
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, Dieter On 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<mailto: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<mailto:Teas@ietf.org> https://www.ietf.org/mailman/listinfo/teas _______________________________________________ Teas mailing list Teas@ietf.org<mailto:Teas@ietf.org> 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