Subject: [mpls] Forwarding discussion in ldp-multi-topology draft

From: Eric Rosen <[email-masked]>
Date: Mon, 17 Oct 2011 11:22:23 -0400

I'd like to make a comment on the discussion of forwarding in
draft-ietf-mpls-ldp-multi-topology-00.txt.

The draft is about the control plane mechanism used to bind a label to a
<MT-id, address prefix> pair.  The label is downstream-assigned.  The
interpretation of the label is thus a local matter for the downstream LDP
peer that assigns it.

The draft mentions the possibility of binding  a stack of labels to a
<MT-id, address prefix> pair.  One could also consider the possibility of
binding a stack of labels to an "ordinary" address prefix in a
single-topology environment.  There are two separate issues:

1. defining a signaling mechanism for binding more than one label to a FEC
   element of some sort.

2. defining the encoding of a FEC element that represents a <MT-id, prefix>
   pair

These two issues are orthogonal, and the draft is about issue 2, NOT about
issue 1.  

Note that if we have the mechanism of 1, it could be combined with the
encoding of 2.  But as long as all the assigned labels are
downstream-assigned, their interpretation would be a local matter for the
assigner, and it would not be appropriate to require, e.g., that the top
label be a context label.

Thus I would suggest removing the following paragraph from section 2:

   "There are two possible solutions to support MT awared MPLS network
   from MPLS forwarding point of view.  The first one is to map label to
   both ip address and the corresponding topology.  The alternative one
   is to use label stacks.  The upper label maps to the topology, the
   lower label maps to the ip address.  The first option does not
   require change to data plane, and it could use multiple labels for
   the same address on different topologies.  The second option requires
   two lookups on data forwarding plane, and it can use the same label"

It suggests that if a two-label solution is ever used, the top label would
be a" context label" (RFC 5331) specifying the table in which the second
label is looked up.  There is no particular reason to say this.   The
paragraph also suggests that if a context label is not used, the
platform-specific label space must be used.  There's no particular reason to
say that either; one could imagine an environment in which an
interface-specific label space could be used (e.g., each link in only one
topology).  These issues are outside the scope of this draft, and I think
any discussion of them here will only cause confusion in the future.

It would be okay to say just that this draft does not require or presuppose
any changes to the MPLS data plane.

Similarly, I would suggest omitting section 10 entirely.  The section even
pronounces itself to be outside the scope of the document.  It also has a
few inaccuracies.

   In MT based MPLS network, forwarding will be based not only on label, but
   also on MT-ID associsted with the label.

This is not true as stated.  I think what is meant is that forwarding is
still based only on the label, but the label is associated with an
<MD-id,prefix> pair.

   It also resolves the
   forwarding issue that exists in IGP multi-topology forwarding when
   multiple topologies share an interface with overlay address space.

"overlay" --> "overlapping", I think.

When this draft gets reviewed outside the MPLS group, the term "the issue
that exists in IGP multi-topology forwarding" will attract unwanted
attention, as it is not completely clear what that issue is, why it is such
a big problem, or why it needs to be mentioned in this context.

> in this mechanism, label space is not allowed to be overlapping
> among different MTs

I think the most you can say is that: 

- the specified signaling mechanisms allow all the topologies to share the
  platform-specific label space; this is the feature that allows the
  existing data plane techniques to be used;  and

- the specified signaling mechanisms do not provide any way for the data
  plane to associate a given packet with a context-specific label space.

I also have some comments on the applicability section.
  
Section 3.1 "Simplified Data-plane" is pretty standard "MPLS is good" stuff.
But I'd have thought that the problem with non-MPLS multi-topology is not so
much the fact that it needs multiple FIBs as that there has to be some way
of associating a received packet with a particular topology.

Section 3.5, "Simplified inter-AS VPN solution", suggests that
multi-topology LDP allows inter-AS VPNs to be set up without using options
A, B or C.  I don't really understand what is being proposed here.