Re: [scale] new updated slides

Pedro Roque Marques <> Tue, 03 December 2013 08:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E53861AE08D for <>; Tue, 3 Dec 2013 00:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HBEuk_N6TMCb for <>; Tue, 3 Dec 2013 00:11:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c01::234]) by (Postfix) with ESMTP id D257D1AE074 for <>; Tue, 3 Dec 2013 00:11:59 -0800 (PST)
Received: by with SMTP id uo5so20471652pbc.25 for <>; Tue, 03 Dec 2013 00:11:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TQCH0CmDcH1qsFyaBXI3+Wkhc+nRtmjCTB074q+IFRs=; b=yfumusmR0AdEv7lC0oc607WUQfHrBVo7HSTyggTMyUYxogCa9d2CYk3CY4YS1oDOUV bFE83ncPxSS1vpiv6Li2YPxJOWFeR6xKs9CstMMwacaopjSKr3G6AVtbKbyQDSpnKV4V kzmkWZpI/tFwZqAfZpRa+UaohTkAzjOOYA625tsnogaUVdEDNo+8lpnqPR68AZJr1H5o Z0StE9VxYpZ+Edg0TJI+o87ulBdV0STULEuHncfRVI0BP//Vbqz9xZzpWnG8Lixxc5qN f4SJ9sA5LNdoNhGUDO+N5l1U+TmcghIlwqEqQZxeg8qkL9zwI6Ve2fH+qnmlFyFwCH3W +N9A==
X-Received: by with SMTP id xi5mr8683109pbb.168.1386058317430; Tue, 03 Dec 2013 00:11:57 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i10sm145213039pat.11.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Dec 2013 00:11:56 -0800 (PST)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Pedro Roque Marques <>
In-Reply-To: <>
Date: Tue, 3 Dec 2013 00:11:54 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Loa Andersson <>
X-Mailer: Apple Mail (2.1822)
Cc: Lou Berger <>,, Vero Zheng <>
Subject: Re: [scale] new updated slides
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MPLS VPN Scaling <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2013 08:12:02 -0000

Looking at the slides, it seems that most of the documents sited are aimed at promoting central label allocation. This is hardly a topic that i would consider related to scale other than in it decreases the flexibility of the solutions.

There seem to be a few attempts to justify central allocations in these documents:

a) VLAN emulation
VLANs use global tag to identify the virtual network; the default assumption from some technologies trying to emulate vlans is that this a positive. I believe this is a very significant misconception: a single tag makes it really hard to create topologies that are different from the default. For instance to implement a hub and spoke topology, which in switching is called "private vlans" requires a switch to use multiple internal vlans for the same external tag. Switches actually do map this external tag into an internal tag (locally assigned by the switch). They just lack the communication mechanism to make label assignment hob-by-hop.

There is no reason why VXLAN tags cannot be egress assigned for instance. The EVPN control plane can (and is) used to manage VXLAN encapsulation and does downstream assignment.

LAN services can be provided when downstream assignment is used. Downstream assignment can enable one to, for instance, insert an appliance between two end-points without modifying the network configuration on the end-points. i.e. by simply manipulating next-hops. This has been one of the traditional limitations of LANs.

b) Multicast
Upstream assignment provides the necessary support for being able to send a multicast packet to multiple downstreams. It does not require the central coordination of global allocation.

c) Identifying the ingress of a multicast packet or a packet sent on a mp2p LSP.
This is one issue where there is the need for better solutions.
One practical approach is to use RFC3107. P routers can advertise their loopback to a single RR that modifies the route's next-hop; and use the received route advertisement from the RR as the label that identifies the source. This has a couple of problems that need to be solved: how to have multiple RRs for availability / resiliency and how to allow the domain to use multiple RRs. These are problems that can be solve... imho they should be addressed in the MPLS WG.

As a whole, it seems to me that this issues are unrelated to scale and that most of the proposals seem to be leading towards the path of removing the main feature of MPLS over other solutions: the flexibility provided by the fact that not all nodes in a network must have the same view of a LAN or a route.

My opinion is that there is no basis for a independent WG or BOF.
L3VPN control plane scaling can be address in the respective WG;
L2VPN control plane issues likewise;
The MPLS WG can discuss global label allocation; i believe that i'm not the only one that will suggest that it is misguided to try to adopt global labels and that instead there should be a solution focused on the ingress identification. A new mailing list / WG is not the right place for this discussion.

On Dec 1, 2013, at 8:59 AM, Loa Andersson <>; wrote:

> Folks,
> Lou and I have been editing the slides a bit. Please review and comment.
> Next step will be to start working on the problem statement and we will
> need help with that. If you are interested please get in contact with
> us.
> /Loa and Lou
> -- 
> Loa Andersson                        email:
> Senior MPLS Expert                
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
> <non-wg-forming-bof-pa8.pptx>_______________________________________________
> scale mailing list