Re: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-06.txt

Curtis Villamizar <curtis@ipv6.occnc.com> Mon, 17 February 2014 02:23 UTC

Return-Path: <curtis@ipv6.occnc.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 73A4D1A030F for <mpls@ietfa.amsl.com>; Sun, 16 Feb 2014 18:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 3DLdV4tWZR-O for <mpls@ietfa.amsl.com>; Sun, 16 Feb 2014 18:23:25 -0800 (PST)
Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3F1A030C for <mpls@ietf.org>; Sun, 16 Feb 2014 18:23:25 -0800 (PST)
Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s1H2NMh1017509 for <mpls@ietf.org>; Sun, 16 Feb 2014 21:23:22 -0500 (EST) (envelope-from curtis@ipv6.occnc.com)
Message-Id: <201402170223.s1H2NMh1017509@maildrop2.v6ds.occnc.com>
To: mpls@ietf.org
From: Curtis Villamizar <curtis@ipv6.occnc.com>
In-reply-to: Your message of "Fri, 14 Feb 2014 10:54:00 -0800." <20140214185400.3376.12133.idtracker@ietfa.amsl.com>
Date: Sun, 16 Feb 2014 21:23:22 -0500
Archived-At: http://mailarchive.ietf.org/arch/msg/mpls/Jh2KjN1OznA_IsxjTvuVCx7gfC8
Subject: Re: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-06.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: curtis@ipv6.occnc.com
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: Mon, 17 Feb 2014 02:23:28 -0000

The LFIB/LIB/ILM/NHLFE terminology isn't quite right yet.

In your earlier document I suggested that you just s/#LFIB/#ILM/g and
things would be right (or close enough).  If you interpret #ILM to be
number of ILM entries per interface with platform label space or worst
case number of ILM entries per interface with interface label space,
then all is fine.  This is the number most people are concerned about
(how big does the ILM table on a given interface need to be).

<aside>
Note that since #ILM/interface always >= #NHLFE/interface (except P2MP
and MP2MP where fanout makes #NHLFE larger than for PTP and P2MP) and
generally #ILM/interface alway >= #NHLFE/interface (again for PTP and
P2MP), the ILM table size is what is of concern.  If PTP and MP2P
dominate, then this remains true when some P2MP and MP2MP are added.
</aside>

I'm really not sure why you put in #ILM, #LIB, #NHLFE and kept #LFIB.
The prior suggestion was simpler but maybe I worded it wrong.
	 
The draft has a few tables like this:

                  +--------------------+---------------+
                  | Parameter          | Typical Value |
                  +--------------------+---------------+
                  | IGP RIB Entries    | 2             |
                  | IP FIB Entries     | 2             |
                  | LDP LIB Entries    | 200           |
                  | MPLS NHLFE Entries | 200           |
                  | MPLS ILM Entries   | 0             |
                  | BGP RIB Entries    | 0             |
                  | BGP FIB Entries    | 0             |
                  +--------------------+---------------+

It makes sense if the access LER never sees and incoming packet with a
label (no ILM) because in one direction traffic is not MPLS (yet) but
the NHLFE entries are used to add labels and on the other side PHP has
removed all the labels before the packet arrived.

You have this table:

                  +--------------------+---------------+
                  | Parameter          | Typical Value |
                  +--------------------+---------------+
                  | IGP RIB Entries    | 2             |
                  | IP FIB Entries     | 2             |
                  | LDP LIB Entries    | 1,400         |
                  | MPLS NHLFE Entries | 1,400         |
                  | MPLS ILM Entries   | 1,400         |
                  +--------------------+---------------+

This makes sense for platform label space if you means #LIB/platform =
1400, #NHLFE/platform = 1400, #ILM/interface = 1400.  Note that if the
packets go out a lot of different interfaces then #NHLFE/interface <<
1400.  You are recommending DoD to reduce label bindings.  DoD goes
well with interface label space, further reducing ILM size on any
given interface.  There is no advantage to interface label space with
DU so in that case platform label space is often used.  If interface
label space was used then #ILM/interface <= 1400 (generally "<").

Perhaps you should state that you are assuming platform label space
and change the above table to #LIB/platform, #NHLFE/platform,
#ILM/interface which would all be equal in that case (with
#NHLFE/interface <= these numbers and #LIB being in the RP/RE).  If
you want to then state that the case where platform label space is
used and #LIB/platform == #NHLFE/platform == #ILM/interface is what
you mean by #LFIB (or "MPLS ILM (LFIB)" as you've written it), then
all the places where the draft has "MPLS ILM (LFIB)" would now make
some sense to someone actually carefully reading this.

Curtis


In message <20140214185400.3376.12133.idtracker@ietfa.amsl.com>
internet-drafts@ietf.org writes:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.  This draft is a work item of the Multiprotocol Label
> Switching Working Group of the IETF.
>  
>         Title           : Seamless MPLS Architecture
>         Authors         : Nicolai Leymann
>                           Bruno Decraene
>                           Clarence Filsfils
>                           Maciek Konstantynowicz
>                           Dirk Steinberg
> 	Filename        : draft-ietf-mpls-seamless-mpls-06.txt
> 	Pages           : 40
> 	Date            : 2014-02-14
>  
> Abstract:
>    This documents describes an architecture which can be used to extend
>    MPLS networks to integrate access and aggregation networks into a
>    single MPLS domain ("Seamless MPLS").  The Seamless MPLS approach is
>    based on existing and well known protocols.  It provides a highly
>    flexible and a scalable architecture and the possibility to integrate
>    100.000 of nodes.  The separation of the service and transport plane
>    is one of the key elements; Seamless MPLS provides end to end service
>    independent transport.  Therefore it removes the need for service
>    specific configurations in network transport nodes (without end to
>    end transport MPLS, some additional services nodes/configurations
>    would be required to glue each transport domain).  This draft defines
>    a routing architecture using existing standardized protocols.  It
>    does not invent any new protocols or defines extensions to existing
>    protocols.
>  
[... etc ...]