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

From: [email-masked]
Date: Fri, 14 Feb 2014 10:54:00 -0800

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-seamless-mpls-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 16 Feb 2014 21:23:22 -0500

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 <[email-masked]>
[email-masked] 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.
>  
[... etc ...]