Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation?
Maarten Vissers <maarten.vissers@huawei.com> Mon, 08 March 2010 08:24 UTC
Return-Path: <maarten.vissers@huawei.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2E23A677D for <mpls-tp@core3.amsl.com>; Mon, 8 Mar 2010 00:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.494
X-Spam-Level:
X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkNUvS6Sr+Al for <mpls-tp@core3.amsl.com>; Mon, 8 Mar 2010 00:24:58 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 585A83A67F6 for <mpls-tp@ietf.org>; Mon, 8 Mar 2010 00:24:58 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYY00GK8FDFKF@szxga04-in.huawei.com> for mpls-tp@ietf.org; Mon, 08 Mar 2010 16:24:51 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KYY00FKQFDFFN@szxga04-in.huawei.com> for mpls-tp@ietf.org; Mon, 08 Mar 2010 16:24:51 +0800 (CST)
Received: from M00900002 ([10.202.112.101]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KYY00BSMFDDHP@szxml06-in.huawei.com> for mpls-tp@ietf.org; Mon, 08 Mar 2010 16:24:51 +0800 (CST)
Date: Mon, 08 Mar 2010 09:24:48 +0100
From: Maarten Vissers <maarten.vissers@huawei.com>
In-reply-to: <201003050550.o255oxpY010979@harbor.orleans.occnc.com>
To: curtis@occnc.com
Message-id: <005601cabe98$d2783480$6570ca0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acq8J+Z6ged+YN6yRqK+glcWSx9xgwCbdAQw
Cc: mpls-tp@ietf.org
Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation?
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2010 08:25:00 -0000
Curtis, MPLS-TP and other packet transport technologies can be run over a compound link. Such compound link can be provided by multiple section layer transport paths or by multiple edge-to-edge LSPs. In both cases the nodes at the edge of such compound link have to make sure that all traffic within a service/transport path is transported via only one link within the compound link. This to maintain e.g. the order of packets/frames within the service/transport path. To deploy the survivability provided by compound links, ITU-T Q.9/15 has developed the Adaptive Compound Link SubNetwork Group protection with Inherent monitoring (ACL-SNCG/I) mechanism. This ACL-SNCG/I protection controls the distribution of 1) PWs, service-LSPs and service path layer PST LSPs over a service path layer component links (supported by edge-to-edge LSPs) within a compound link, 2) edge-to-edge LSPs and transport path layer PST LSPs over a transport path layer component links (supported by sections)within a compound link . The initial work done assumed the presence of non-adaptive media, which would cause a component link to be completely available or completely unavailable (as in ethernet LAG). At the moment this work is being extended to also support adaptive media, which are able to reduce their bandwidth to a lower level; i.e. creating a partly available state in between the original two states. Input to the distribution process is the CIR(EIR) and relative priority of each service path or transport path that is carried over the compound link and the available bandwidth of each component link within the compound link. The distribution process computes the distribution of the service paths, or transport paths. If the bandwidth of the compound link becomes too small to support all, then the lowest priority service/transport paths are blocked and packets/frames of those paths are not longer forwarded over the compound link. A service path or transport path's bandwidth must always be smaller then the bandwidth of the component links. Regards, Maarten -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Curtis Villamizar Sent: vrijdag 5 maart 2010 6:51 To: Adrian Farrel Cc: mpls-tp@ietf.org; Rui Costa Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: ~ECMP =>~ETH aggregation? In message <21AFCCB59EFE4816B26E280DF3355CE2@your029b8cecfe> "Adrian Farrel" writes: > > Surely the formation of the server layer and the use of OAM within the > server layer is entirely an issue for the server layer. > > It is a mistake for the MPLS-TP layer to be aware of the underlying > technology that provides the link connectivity between to adjacent > LSRs. The links provided by the server layer have certain resiliency > and recovery properties, as well as properties associated with > in-order (or not) packet delivery that are announced to the MPLS-TP > network (usually through > configuration) and the MPLS-TP network can choose which links to use > accordingly. The goal is to make OAM work by adding entropy. If there is no underlying LAG, then the entropy serves no purpose but does no harm. If there is an underlying LAG then not having entropy allows the OAM traffic to test only one member. For example, if an MPLS LSP hop (section) is a LAG, traffic within that MPLS LSP would take different LAG members if the entire label stack was not the same for all traffic or if the LSP carried IP traffic from more than one host pair. If the OAM traffic had a fixed label stack it would test only one LAG member. > LAG at a server Ethernet layer is a way of providing a composite link > to the MPLS-TP layer. That link has specific properties, but the > MPLS-TP layer cannot be expected to take specific measures to operate > the link. That is the job of the server layer itself (noting that the > adaptation into the LAG is a function of the server layer, just as the operation). If CL is allowed for MPLS-TP, then OAM must work for CL. We should not knowingly just specify something that is broken. > So, the MPLS-TP layer runs OAM across the link. It doesn't know how > the link is formed. It is the responsibility of adaptation function to > either distribute the MPLS-TP packets across the group members such > that link degradation will be noticed by the MPLS-TP layer (this could > be noted as a requirement that the MPLS-TP layer puts on the server > layer that link degradation should be detectable by any measure of > MPLS-TP packets); or the server layer must perform its own OAM to > detect link degradation and report it to the MPLS-TP layer at the link end points. For plain old MPLS, it doesn't know about any LAG either, but the 127.x source addresses add the entropy needed to provide effective OAM. That is why IETF specified MPLS Ping and and rejected 1711 and why MPLS Ping works and 1711 doesn't work. > LAG is not the only "complex" way of forming links in the MPLS-TP > network from multiple links in the server network, and we really don't > want to embark on making MPLS-TP understand each and every server technology. > > Cheers, > Adrian However, any method which is capable of supporting an LSP that is greater in capacity than any one component link needs to look below the top label to do so. I think that is trivailly provable given that the top level is always the same for that LSP. Therefore no matter what we define CL to be, if this CL supports LSP of greater than a LAG member size, a capability we currently have with Ethernet LAG or ECMP over parallel links (another form of link aggregation that predates Ethernet LAG by over a decade), then OAM needs to provide entropy to insure that any CL/LAG/ECMP along the path is exercised. Curtis > ----- Original Message ----- > From: "Stewart Bryant" <stbryant@cisco.com> > To: <curtis@occnc.com> > Cc: "Rui Costa" <RCosta@ptinovacao.pt>; <mpls-tp@ietf.org> > Sent: Wednesday, March 03, 2010 10:59 AM > Subject: Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-plane-00: > ~ECMP => ~ETH aggregation? > > > > Curtis Villamizar wrote: > >> In message <4B87B8C7.5010406@cisco.com> Stewart Bryant writes: > >> > >>> I would think that if the operator wanted the bandwidth more than > >>> they wanted the fate sharing, they will deploy the technology. > >>> - Stewart > >>> > >> > >> > >> There is no reason not to put some entropy in the extension to MPLS > >> Ping so that there was fate sharing over LAG. > >> > >> Curtis > >> > >> > > Curtis > > > > Do you have some text in mind? > > > > - Stewart > > _______________________________________________ > > mpls-tp mailing list > > mpls-tp@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls-tp _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp
- [mpls-tp] Comments on draft-fbb-mpls-tp-data-plan… Rui Costa
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Stewart Bryant
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Vishwas Manral
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Peng He
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Vishwas Manral
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… David Allan I
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Peng He
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Vishwas Manral
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Phil Bedard
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Alexander Vainshtein
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Alexander Vainshtein
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Maarten Vissers
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Rui Costa
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Rui Costa
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Rui Costa
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Stewart Bryant
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Stewart Bryant
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Adrian Farrel
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Vishwas Manral
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Alexander Vainshtein
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… benjamin.niven-jenkins
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… David Allan I
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Adrian Farrel
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Thomas D. Nadeau
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… David Allan I
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Thomas D. Nadeau
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… neil.2.harrison
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Maarten Vissers
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Maarten Vissers
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… David Allan I
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Phil Bedard
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… John E Drake
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Stewart Bryant
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Stewart Bryant
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Peng He
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… tom.petch
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Maarten Vissers
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Alexander Vainshtein
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Maarten Vissers
- Re: [mpls-tp] Comments on draft-fbb-mpls-tp-data-… Curtis Villamizar
- [mpls-tp] MPLS-TP LM OAM usage over a LAG [was: R… Maarten Vissers
- Re: [mpls-tp] MPLS-TP LM OAM usage over a LAG [wa… Curtis Villamizar