Re: [scale] new updated slides

Loa Andersson <> Fri, 06 December 2013 05:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B5A11AE2C6 for <>; Thu, 5 Dec 2013 21:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id csvUSfM9LXae for <>; Thu, 5 Dec 2013 21:35:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C6D911AE1BB for <>; Thu, 5 Dec 2013 21:35:07 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3CB0C18015C4; Fri, 6 Dec 2013 06:35:01 +0100 (CET)
Message-ID: <>
Date: Fri, 06 Dec 2013 13:34:58 +0800
From: Loa Andersson <>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Pedro Roque Marques <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 06 Dec 2013 05:35:10 -0000


I'd like to make one or to things clear when it comes to the listed

- we kind of inherited the draft list, and have chosen to be careful
   removing drafts without being very sure that it does not belong in
   the list
- I've have not read the info around the list of drafts as "this is the
   drafts that will give us the solution of the MPLS VPN Scaling Problem"
   I've seen i more like "these drafts might contain information that is
   relevant when we try to figure out what the critical scaling issues
   are"; i.e. the draft does not have to be "about scaling", but it might
   have "an impact on scaling"!
- having said that I do not claim that this "the list", only that it is
   a zero order approximation; if we find it useful let us refine the
   list, if not let us start to write a problem statement and see if
   some/all/more drafts can be used as references.

The discussin on whether central allocation (in all cases) of labels are
not closed for me. Even if I believe I no the answer I willing to listen
some more.


On 2013-12-03 16:11, Pedro Roque Marques wrote:
> Loa,
> 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.
>    Pedro.
> 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
> _______________________________________________
> scale mailing list


Loa Andersson                        email:
Senior MPLS Expert                
Huawei Technologies (consultant)     phone: +46 739 81 21 64