Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Fri, 01 May 2015 13:41 UTC

Return-Path: <mustapha.aissaoui@alcatel-lucent.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3821B31BE for <mpls@ietfa.amsl.com>; Fri, 1 May 2015 06:41:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 tKrinZFTYh6E for <mpls@ietfa.amsl.com>; Fri, 1 May 2015 06:41:05 -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 96D951B31BD for <mpls@ietf.org>; Fri, 1 May 2015 06:41:04 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B44D736F83C42; Fri, 1 May 2015 13:40:58 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t41Dex1X014771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 09:40:59 -0400
Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 1 May 2015 09:40:59 -0400
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: Loa Andersson <loa@pi.nu>, "Andrew G. Malis" <agmalis@gmail.com>
Thread-Topic: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01
Thread-Index: AdCBzIr6SsqnVpHOQqOMLXhwS/KfnQAogseAAAwv7YAAKVIdvwABTeSgADVYhIAAAwNEUA==
Date: Fri, 01 May 2015 13:40:59 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D948351FD@US70UWXCHMBA01.zam.alcatel-lucent.com>
References: <4A79394211F1AF4EB57D998426C9340D948330B5@US70UWXCHMBA01.zam.alcatel-lucent.com> <55408663.1070906@pi.nu> <4A79394211F1AF4EB57D998426C9340D94833E1C@US70UWXCHMBA01.zam.alcatel-lucent.com> <5541DC9A.5000200@pi.nu> <CAA=duU084CCWuqTzbWtC9TApwEi-_VV6n3yUmROcwOYr+VhaiQ@mail.gmail.com> <4A79394211F1AF4EB57D998426C9340D948345F6@US70UWXCHMBA01.zam.alcatel-lucent.com> <55435C39.5050208@pi.nu>
In-Reply-To: <55435C39.5050208@pi.nu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/qP7H8jkp-bRTcy_xmGIr0YSmU88>
Cc: "mpls@ietf.org" <mpls@ietf.org>, Nevil Brownlee <rfc-ise@rfc-editor.org>
Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2015 13:41:07 -0000

Hi Loa,
I am fine with "configured labels" or maybe "labels assigned and reclaimed by configuration".

Having said that, one of my comments on the draft was to explain how the labels were actually managed and assigned/reclaimed to/from routers over time. From you description below, it seems the NMS first reserves a common range of labels *available on all routers* for this application. Once reserved, no other control plane protocol on any router can use a label from this range even if the label is available. That way, the NMS management of the labels will not clash with the control plane protocols on any of the routers.

Regards,
Mustapha.

> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]
> Sent: Friday, May 01, 2015 6:58 AM
> To: Aissaoui, Mustapha (Mustapha); Andrew G. Malis
> Cc: mpls@ietf.org; Nevil Brownlee
> Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01
> 
> Mustapha and Andy,
> 
> If we are talking about manual configure (manually installed labels), this is not what
> is not what is going on in the hard-pipe network.
> 
> It is of course possible to run any MPLS network with all or a subset of the labels
> manually installed. We did that in 1999 whenm I worked with a Swedish operator.
> Awaiting tests and decision on the mix of signalling protocols we for several
> months did run our network by installing all labels manually, we never thought
> about that as "static", but I could live with that terminology if we want to use it.
> 
> What is going on in the hard-pipe network is a bit different. The NMS (centralized
> controller) is configured with a label space per node to be used for the hard-pipe
> stratum. The NMS then allocate labels to be installed on the nodes as a LSP is
> requested and remove them and returns them to the pool when the LSP is taken
> down.
> 
> I tend to think about this as dynamic configured labels. Dynamic as they are
> installed and removed depending on the life time of the LSPs.
> Configured as it is done by the NMS.
> 
> Mustapha,
> 
> Would "configured labels" cover the concerns you have.
> 
> /Loa
> 
> On 2015-04-30 15:42, Aissaoui, Mustapha (Mustapha) wrote:
> > Thanks Andy for the reference. Indeed, I was referring to assignment
> > of initial label and of any subsequent label change of an LSP or a PW
> > by configuration. This is sometimes referred to as “manual”
> > configuration and the LSP or PW is referred to as static.
> >
> > That definition fits I believe what is being described in
> > draft-hao-mpls-ip-hard-pipe-01 but Loa can confirm.
> >
> > Regards,
> >
> > Mustapha.
> >
> > *From:*Andrew G. Malis [mailto:agmalis@gmail.com]
> > *Sent:* Thursday, April 30, 2015 8:52 AM
> > *To:* Loa Andersson
> > *Cc:* Aissaoui, Mustapha (Mustapha); mpls@ietf.org; Nevil Brownlee
> > *Subject:* Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01
> >
> > Loa,
> >
> > I think the reference that you're looking for is section 3.11 of RFC 5921.
> >
> > Cheers,
> >
> > Andy
> >
> > On Thu, Apr 30, 2015 at 3:41 AM, Loa Andersson <loa@pi.nu
> > <mailto:loa@pi.nu>> wrote:
> >
> > Mustapha,
> >
> > That is still not a definition possible to refrence.
> >
> > I've always been a bit confused by the distinction between "static"
> > and "dynamic", especially when it comes to labels, a bit less so if we
> > talk about LSPs.
> >
> > To me the term  "static" and "dynamic" seems to indicate how long
> > lived or how easy they are to change.
> >
> > If an NMS or any centralized controller instal and remove LSPs/labels
> > with the same frequency as e.g. LDP are they still "static"?
> >
> > I agree that there is a possible classification of "configured
> > LSPs/labels" vs. "signaled LSPs/labels".
> >
> > In that terminology I'd say that draft-hao-mpls-ip-hard-pipe uses
> > configured labels.
> >
> > Would that terminology be acceptable for you?
> >
> > /Loa
> >
> >
> >
> > On 2015-04-29 19:26, Aissaoui, Mustapha (Mustapha) wrote:
> >
> > Hi Loa,
> > By static label, I meant a label which is assigned to a LSP or a PW by
> > configuration and not by a control plane protocol. I believe this is
> > what is being described in this draft but let me know if I am wrong.
> >
> > Regards,
> > Mustapha.
> >
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.nu <mailto:loa@pi.nu>]
> > Sent: Wednesday, April 29, 2015 3:21 AM
> > To: Aissaoui, Mustapha (Mustapha); mpls@ietf.org
> > <mailto:mpls@ietf.org>
> > Cc: Nevil Brownlee
> > Subject: Re: [mpls] Review of draft-hao-mpls-ip-hard-pipe-01
> >
> > Mustapha,
> >
> > in line please.
> >
> > On 2015-04-28 18:01, Aissaoui, Mustapha (Mustapha) wrote:
> >
> > Dear all,
> > I was asked to review this draft which is intended to be handled in
> > the
> >
> > Independent Stream. Below are my comments to the authors.
> >
> >
> > Members of this list can also provide comments to the authors. Please
> > copy the
> >
> > Independent Submission Editorial Board at the following address:
> >
> > rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org>
> >
> > Regards,
> > Mustapha.
> > ----------------------------
> > https://tools.ietf.org/html/draft-hao-mpls-ip-hard-pipe-01
> >
> > 1. Overall comment:
> > This document describes how a guaranteed bandwidth service can be
> > deployed
> >
> > in a MPLS network by partitioning the network resources into two
> > managed layers, referred to as strata. The  guaranteed service layer
> > is referred to as "Hard Pipe"
> > stratum.
> >
> >
> > The management of the resources and the placement of the MPLS tunnels
> > and
> >
> > services into the  "Hard Pipe" stratum are performed with a management
> > system.
> > Thus the transport and service labels are static but this important
> > information has not been stated upfront in the document.
> >
> > Do you have a a definition of "static labels" that we can refer to?
> >
> > /Loa
> > Only in section 6 that MPLS-TP was mentioned. Furthermore, the
> > reference to T- LDP signaled labels in Section 3 adds to the
> > confusion.
> >
> >     I propose that the Introduction and Scope sections be explicit
> > about the
> >
> > framework used to achieve the "Hard Pipe" stratum, that is by means of
> > a management system and static transport and service labels.
> >
> >
> > In fact, I would think the document value would be in describing more
> > details of
> >
> > the framework including configuration aspects, resource and service
> > management including resilience. These aspects have not been
> > sufficiently addressed and the focus was more on how to use MPLS
> > labels to differentiate the two strata.
> >
> >
> > 2. Section 1.1 - Scope:
> > As part of the second bullet, I cannot find in the document how a
> > router protects
> >
> > the traffic of the "Hard Pipe" stratum if the "Normal IP/MPLS" stratum
> > overbooks a link. Having a separate label for the guaranteed service
> > is not sufficient. The authors should describe if LSP pre-emption
> > and/or QoS markings are used to differentiate the treatment across the
> > strata.
> >
> >
> > 3. Section 3:
> > If the document objective is to describe the framework used, then this
> > section
> >
> > should begin by explaining the initial configuration performed by the
> > NMS to lay the ground for the building of the two stratums. This
> > includes the partitioning of the links, the assignment of transport
> > and service label ranges in the routers, the overbooking strategy,
> > etc.
> >
> >
> > Then, you can discuss how a guaranteed service is configured in the
> > network
> >
> > using static transport labels and static service labels. This should
> > cover the placement of the working and backup paths since Section 6
> > mentions MPLS-TP protection is used.
> >
> >
> > Next, a description of how the transport LSP and service are monitored
> > for
> >
> > continuity and defects.
> >
> >
> > Finally, the behavior when resources are overbooked and what services
> > are pre-
> >
> > empted or degraded should be described.
> >
> > ------------------------------------
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org <mailto:mpls@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> >
> > --
> >
> >
> > Loa Andersson                        email: loa@mail01.huawei.com
> > <mailto:loa@mail01.huawei.com>
> > Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> > <tel:%2B46%20739%2081%2021%2064>
> >
> >
> > --
> >
> >
> > Loa Andersson                        email: loa@mail01.huawei.com
> > <mailto:loa@mail01.huawei.com>
> > Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> > <tel:%2B46%20739%2081%2021%2064>
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org <mailto:mpls@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> --
> 
> 
> Loa Andersson                        email: loa@mail01.huawei.com
> Senior MPLS Expert                          loa@pi.nu
> Huawei Technologies (consultant)     phone: +46 739 81 21 64