Re: [mpls] My question about "static LSP" in TEAS today

"Adrian Farrel" <> Wed, 06 April 2016 13:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CFB212D5AD for <>; Wed, 6 Apr 2016 06:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fZLlPCV3UxDk for <>; Wed, 6 Apr 2016 06:51:42 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 718A012D5C4 for <>; Wed, 6 Apr 2016 06:51:40 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u36DpZ4C024942; Wed, 6 Apr 2016 14:51:35 +0100
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u36DpWQt024880 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2016 14:51:34 +0100
From: Adrian Farrel <>
To: "'Tarek Saad (tsaad)'" <>
References: <05bc01d18f83$c57bfce0$5073f6a0$> <>
In-Reply-To: <>
Date: Wed, 06 Apr 2016 14:51:29 +0100
Message-ID: <078c01d1900b$6e1c8d60$4a55a820$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMEfdU07zIuFgpCnDD5Vj+l40Xc0wKuaC/VnQGjF7A=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--37.048-10.0-31-10
X-imss-scan-details: No--37.048-10.0-31-10
X-TMASE-MatchedRID: 0lhM5bBmjEOnykMun0J1wpJEUO2qIzlLkKAa/khZ3iTIvQIyugvKdTco lL66pGxavxjd8HDxJA7Oxo/f0SVhOAdNdS6cTLNYR+GtoiXVeDGGm/9Tv2/OgfgnJH5vm2+g5ee hiA0K53Qcm7TGmQXc1T0gMbrUmb4fQ+WOkQmWrLrsEjYqO+DyaLuesBT0pDFRInzOyTDR1uuWuL +jYTRdpowZrvRON7G4XXI3bMiDYvRBmRZWSonyTpYsKSXWWrsHgGa+oYp5i6prH7R0RhorDPIX6 6Noho9rqnea6Euo4wToRMmmVPjOW62Uzgqgb39dQz/LkQyz8mYxRS4RlA/AFpps2hiiMFB2qJlo 5lQZWaox6UfuqGepQT/RglLb5RzWEO6iheizlV4wo+sXt0rns2PIqSS8BzKh2nVuImEjI1Fdrb7 MTVw/5ZBOEhVhRWupFyCVjv7dlo5gRbV6VSX3KAPZZctd3P4BjLOy13Cgb4+e9toQ6h6LE8VJIR TDvqF7XCZPbUFnBYEYLjS0c7/5NXMtRMwL8VEPoMfp2vHck9Uzc8FC0MEwTxRZ/9wBMhGsLMRTl XcK2C3rLST+tNFoDBDkRVnCZf/d8FQaUkGHmlcXKqR+w9a7ULLdiE6f8zQxgrAXgr/AjP36p2mn E2PRyeXrs80uTFi5hJqfnrAnMyq4mqWVDqxbtOLz1o40byIqL34I8IpvQcKYFp2iw4hoIWf6W69 0ONYWr8RjrZqN+Iefb6bl1YfU92gwIvLATTKBRjjVhf+j/wpKdDgyPBo71yq2rl3dzGQ1A/3R8k /14e0=
Archived-At: <>
Subject: Re: [mpls] My question about "static LSP" in TEAS today
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Apr 2016 13:51:45 -0000


Thanks for the exchange.

I think we can jump to the bottom line.
Both data models are for the user/application to request or view an LSP.
You are correct that *normally* the user requests a static LSP in detail that
includes the nodes, interfaces, labels, and resources.
You are correct that *normally* a user requests a control-plane operated LSP
using at most nodes and links (interfaces) and resources.
That is, a user does not *normally* specify what labels to use.
However, use cases exist where:
- the user of the control plane does specify the labels to use
   (and the control plane supports signaling these labels)
- the user of the management plane for static LSPs does not
   specify the labels to use and this information is either
    - pulled out of the network nodes and then passed to the
      other network nodes
   - determined by some software component (people may 
      call this an orchestrator or controller)

More interesting, however, is that we are *modelling* the LSP not just
facilitating write-action requests for an LSP.
Once the LSP has been installed, it has the same information regardless of how
it was instantiated, and the data model must report all of that information. The
user wants to know all of this information.

This debate may come down to some more clarity about what we are trying to
achieve. I don't have a strong opinion about what we are trying to do, but I
think it is clear 
that it isn't clear :-) 

Like Andy, I recall the ATM MIB modules. And of course, I know a little bit
about the MPLS and GMPLS MIB modules. I can explain what we were trying to
achieve with them. I don't claim that you must model the same stuff in the same
way, but I do claim that the MPLS MB modules supported static LSPs as well as

Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
Or buy from me direct.

> -----Original Message-----
> From: Tarek Saad (tsaad) []
> Sent: 06 April 2016 04:15
> To: Adrian Farrel
> Cc:
> Subject: Re: My question about "static LSP" in TEAS today
> Hi Adrian,
> Thanks. Let me clarify my answer inline too..
> On 2016-04-05, 6:40 PM, "Adrian Farrel" <> wrote:
> >Hi,
> >
> >I probably wasn't clear in my question. To restate, my question is why is
> >the
> >static LSP model modelling an end-to-end LSP and not just a single "cross
> >connect"? Alternatively, what is the difference between an LSP
> >provisioned by a
> >control plane, and an LSP provisioned by the management plane? And we
> >might even
> >bring in "soft permanent LSPs" that are a stitching together of some
> >static
> >segments and some dynamic segments.
> Yes, we started thinking of stitching of static LSP with dynamic LSP, and
> we think it can be modelled with defining the respective mpls static
> cross-connect that is doing the stitching, but more clarification on
> static entries below.
> >
> >(You might look at the LSR MIB module that can be used to provision [aka
> >model]
> >static LSPs.)
> Yes, I think the static LSP model is inline with that (and to certain
> extent inspired from the MIB LSR).. So, the model allows for a list of
> MPLS cross-connect entries (that are keyed by ³name²) and that resemble
> the cross-connects of the named static LSP on every LER/LSR traversed.
> So, to instantiate a static LSP named foo (in its simplest form) that is
> traversing an ingress/transit/egress, the operator to provisions the
> following entries on the respective device:
> on ingress LER, operator provisions using YANG/NETCONF:
>  lsp name foo
>    in-segment=³10.0.0.0/8²
>    out-segment=16000
>    operation=impose-and-forward
>    out-inteface=if1
> on transit LSR, operator provisions (assuming UHP) using YANG/NETCONF:
>  lsp name foo
>    in-segment=16000
>    out-segment=16000
>    operation=swap-and-forward
>    out-inteface=if2
> on egress LER, operator provisions (assuming UHP) using YANG/NETCONF:
>  lsp name foo
>    in-segment=16000
>    out-segment=none
>    operation=pop-and-lookup
> Once provisioned, it is expected this configuration state will persist,
> hence ³static"
> >
> >When you model maybe you need to think about what is the purpose of
> >modelling.
> >There are three things going on:
> >
> >What is the user/application asking for?
> >What state is held in the network?
> There will be configuration state held for the LSP on each traversed mpls
> node.
> >What does the data plane have?
> The data plane will have the respective MPLS cross-connects/rewrite
> programmed. Yes, this practically is indistinguishable (for example) from
> those created dynamically using a signalling protocol.
> >
> >In this case there is no control plane, but there is still distributed
> >state
> >installed in the network.
> Yes, configuration state in this case.
> >You said that this is not a data plane model, which is fine.
> >So you are modelling either the state in the network or the user's
> >request.
> User¹s request.
> >Now, there may be protocol state (such as parameters of RSVP-TE that
> >exist to
> >keep the protocol on side) that are special, but the parameters that
> >describe
> >the state that applies to the LSP are surely identical regardless of how
> >the LSP
> >was set up. That is, the LSP is a sequence interfaces and labels as well
> >as some
> >information about reserved resources.
> >
> >I think I'm rambling. What I am trying to say is that an LSP is an LSP.
> IMO, there¹s a difference between the two. For example, it is expected
> that the statically created LSP properties on a device will never change ‹
> including the in/out label and in/out interface.. which is not the case
> for dynamically singled LSPs.
> Regards,
> Tarek
> >
> >Cheers,
> >Adrian
> >