Subject: [mpls] MVPN in the "seamless MPLS" environment

From: Eric Rosen <[email-masked]>
Date: Wed, 25 May 2011 08:53:35 -0400

Draft-raggarwa-mpls-seamless-mcast covers a lot of topics, and I have a lot
of comments on it, but I want to focus in this message on whether the
proposed control plane model is really appropriate for a "seamless MPLS"
environment.  It seems to me that the proposed control plane model violates
the requirements for "seamlessness", because it intermixes the
service layer and the transport layers, and requires service-specific state
and processing at the border routers of the transport layer.

One of the basic concepts of the proposal is that of the "P2MP FEC" or
service LSP" (these terms seem to be used more or less equivalently).  For
MVPN, the proposal identifies a P2MP FEC with a PMSI (i.e, with the entity
that is identified by the NLRI of an I-PMSI or S-PMSI A-D route).  To make
the proposal fit into the seamless MPLS environment, the P2MP FEC really has
to identify its P2MP FEC with a P-tunnel.  I'll try to show that this change
would result in a simpler and more scalable scheme.

The "seamless MPLS" model is described in draft-leymann-mpls-seamless-mpls.
This draft does not actually give a definition of "seamless MPLS", but it
does specify a number of characteristics that a seamless MPLS system will
have.  One of the major characteristics of a seamless MPLS environment seems
to be that there is a fairly strict demarcation between "service" and
"transport".  The environment is hierarchical, with service nodes at the
lowest level of the hierarchy and transport nodes at the higher levels.  The
transport nodes are not to have any service-specific configuration, any
service-specific procedures, or, presumably, to run any service-specific
protocols.   The service nodes run service-specific protocols with each
other, and run transport-specific protocols with the transport nodes at the
next level of hierarchy.

For example, to support a pseudowire service in a seamless MPLS environment,
the service node at the edge would run the pseudowire setup protocol with
each other.  The transport nodes would run "ordinary" MPLS with each other
and with the service nodes.  The transport nodes would not maintain per-pw
state. 

An example of a non-seamless model would be the multi-segment pseudowire
model, where some of the nodes at higher levels of the hierarchy actually
talk pseudowire setup protocol to the service nodes, and do
pseudowire-specific procedures.

Although the "seamless-mcast" draft claims to specify the way to do MPLS
multicast in the seamless MPLS model, the procedures it specifies are much
more like the multi-segment pseudowire model than like the seamless model.
For the MVPN service, the draft has the service nodes and the border
transport nodes exchanging MVPN-specific control messages and performing
MVPN-specific functions.  The border routers at the upper level of the
hierarchy have to maintain MVPN-specific state, and the amount of state
maintained is proportional to the number of MVPN states maintained by the
service nodes, not proportional to the number of transport tunnels that are
needed.

For example, a PE might send 100 S-PMSI A-D routes, each one binding a
customer flow (C-S,C-G) to a P-tunnel.  But these 100 S-PMSI A-D routes
might all have the same PMSI Tunnel Attribute (PTA); that is, the PE might
bind each of these 100 C-flows to the same P-tunnel.  In seamless MPLS, the
transport border nodes should have one state for the P-tunnel, not 100
states for the C-flows.  The transport border routers do not care what the
P-tunnel is being used for.  And since the border routers do not perform
MVPN-specific functions, they will not be deaggregating and reaggregating
the C-flows.  The border routers may decide to aggregate the P-tunnels in
some way, but they should not deal with anything more finely grained than a
P-tunnel; to do so would be to perform service-specific functions.

I think it is possible to provide MVPN support in the seamless MPLS
environment in a more seamless manner, keeping MVPN-specific functionality
off the transport nodes, while still gaining the advantages of LSP hierarchy
that the seamless MPLS model tries to provide.  

The MVPN specifications really provide three and a half "levels" of
signaling:

1. The C-multicast signaling, which conveys the customer multicast states
   from one PE to another.  This level of signaling should involve only the
   PE routers (the service nodes).

2. The A-D signaling, which assigns sets of customer multicast flows
   (C-flows) to P-tunnels.  The A-D signaling also distributes the
   information that the PE routers need in order to determine which
   P-tunnels they need to join, as well as the information needed by the
   third level of signaling.  This level of signaling is done via BGP.

3. The P-tunnel setup signaling.

   For unsegmented P-tunnels, and for individual segments of segmented
   P-tunnels, this level of signaling is done via mLDP, RSVP-TE, or other
   multicast tunnel setup protocol.

   For segmented P-tunnels, there is a "level 3.5" of signaling, that
   carries information among the segment endpoints.  (When ingress
   replication is used to instantiate the P-tunnels, level 3 signaling is
   not needed, though level 3.5 signaling might still be needed.)

In a seamless MPLS environment, I think the A-D signaling should, like the
C-multicast signaling, should only involve the service nodes.  It should be
PE-PE signaling, most likely through service-specific route reflectors.

The P-tunnel setup signaling (levels 3 and 3.5) should involve the transport
nodes, of course, but in the seamless model, this level of signaling should
be service-independent.  The basic concept of this level of signaling should
be the P-tunnel.

The proposal in the seamless-mcast draft uses the MVPN A-D signaling for the
level 3.5 signaling.  As a result, the "P2MP FEC" used by the level 3.5
signaling is the NLRI of the A-D routes, rather than the P-tunnel.  

If we don't try to piggyback the level 3.5 signaling on the level 2
signaling messages, and we do the level 3.5 signaling on a per-P-tunnel
basis, we can provide the following control flow model:

   PE2-- ... ---ABR2-- ... ---ABR1-- ... ---PE1

   Let's suppose, e.g, that we want to create a three-segment P-tunnel, with
   each segment created by RSVP-TE.  IMHO, the desired flow of control is:

   1. PE1 sends MVPN-specific signaling to PE2 (using MVPN standard BGP).
      E.g., PE1 might send S-PMSI A-D routes binding (C-S1,C-G1),
      (C-S2,C-G2) and (C-S3,C-G3) to a particular P-tunnel.  For this
      example, let's say that the PMSI Tunnel Attribute (PTA) identifies the
      P-tunnel using an mLDP P2MP FEC element: <root=PE1, opaque value = X>.

   2. PE2 receives this S-PMSI A-D route.

   3. PE2 needs to receive, say, <C-S2,C-G2> traffic, and so needs to join
      the <root=PE1, opaque value = X> P-tunnel.

   4. PE2 sends a "P-tunnel Join Request" message to ABR2, specifying the
      <root=PE1, opaque value = X> P-tunnel.

   5. ABR2 adds PE2 to an RSVP-TE P2MP LSP tunnel of which ABR2 is the
      headend.

   6. ABR2 send a "P-tunnel Join Response" to PE2, telling it that the
      <root=PE1, opaque value = X> tunnel is being carried within an
      identified RSVP-TE P2MP LSP.  If the RSVP-TE P2MP LSP is aggregating
      other P-tunnels, PE2 would include an upstream-assigned label.

   7. ABR2 sends ABR1 a "P-tunnel Join Request" message.

   ....
   
   etc.

The "P-tunnel Join Request/Response" messages are the level 3.5 signaling.
Note that although the PE-PE P-tunnel is identified using an mLDP P2MP FEC,
there is no presumption that mLDP will be used to build the segments.  The
FEC is used as an identifier for the end-end (PE-PE) P-tunnel, not
necessarily as an identifier for any of its segments.

Let me suggest a couple of ways in which this control flow model can be
provided.

Proposal 1: this proposal follows the seamless-mcast draft in using BGP for
setting up the segmented P-tunnels.  It does so as follows:

- New AFI/SAFI for BGP-based level 3.5 P-tunnel setup signaling.

- NLRI of this AFI/SAFI is a "P2MP FEC", as defined, say, in the mLDP spec.
  (So the NLRI identifies a P-tunnel rather than a "service LSP".)

- P-tunnel setup is initiated from the leaf nodes, using a new route type,
  "P-tunnel Join Request" routes.  These are sort of like the "Leaf Info A-D
  routes", except that:

  * the NLRI encodes the P2MP FEC identifying the PE-PE P-tunnel

  * the ability of a PE to send one of these routes to an ABR does not
    depend on the PE's having first received any other P-tunnel route from
    the ABR.

  * Route distribution constrained to specific upstream LSR by the usual
    extended community methods from the MVPN specs.

  * Semantics are that the originator wants to join the specified P-tunnel.

- When an upstream LSR receives one of these routes from downstream, it:

  * Responds by sending a P-tunnel Join Request upstream, same NLRI.

  * Responds by sending a P-tunnel Join Response downstream, same NLRI.  A
    PTA may be included.  This attribute identifies the tunnel and tunnel
    type of the particular segment connecting the upstream LSR to the
    downstream LSR.  This segment may be carrying several end-to-end
    P-tunnels; if so the MPLS label in the PTA is used for demultiplexing.

  * If the segment is an RSVP-TE P2MP LSP, the upstream node initiates the
    signaling to add the downstream node.

- When a downstream LSR receives a Join Response after having sent a
  corresponding Join Request, if further signaling is required to join the
  segment (e.g., if the segment is created by mLDP), the downstream node
  initiates the necessary signaling, based on the information in the PTA of
  the Join Response.

This proposal uses BGP for the level 3.5 signaling, but keeps it separate
from levels 1 and 2 of signaling.  I believe this has the following
advantages:

- Non-PEs have state per P-tunnel, rather than state per C-flow or per-PMSI.

  If PE has originated 100 S-PMSI A-D routes, all with the same PTA, the
  transport border router will get only one route (for the P-tunnel) from
  that PE, rather than getting the 100 S-PMSI A-D routes.

- Non-PEs have no MVPN-specific knowledge or state, and do not even have to
  know how to parse the "MCAST-VPN" SAFI messages.  

- Using a different AFI/SAFI than the service-specific C-multicast and A-D
  routes results in a simpler scheme.  It eliminates the need to invent new
  attributes or communities for the A-D routes to carry, as we no longer
  need to have some attributes for the "level 2 signaling" and some for the
  "level 3.5 signaling".

  Another advantage of using a different AFI/SAFI is that it becomes much
  easier to set up the BGP sessions properly.  Note that the C-multicast
  routes and A-D routes, as defined in the MVPN specs, share the same
  AFI/SAFI.  If one wants to forward the C-multicast routes via a RR but
  send the A-D routes directly to the border routers, one has to filter on
  the "route type", which is encoded in the first octet of the NLRI.  And if
  any new route types are invented, these filters would have to be modified.
  By using a separate AFI/SAFI for the level 3.5 signaling, it becomes much
  easier to set up the BGP sessions properly.

- This signalling can be used to create segmented P-tunnels even if the
  service nodes are not using BGP A-D routes.

  For example, if one has existing MVPNs using PIM/GRE P-tunnels, one may
  want to migrate the "core" area to MPLS multicast, witout having to first
  migrate the existing PE routers.  In this case, a transport border router
  receiving a PIM Join can "translate" it into a BGP P-tunnel Join
  Request. This sort of migration cannot be done with BGP A-D routes,
  because a Leaf Info A-D route cannot be originated as the result of
  receiving a PIM Join.  (Per the MVPN/BGP spec, Leaf Info A-D routes can
  only be sent in response to S-PMSI A-D routes.)

Proposal 2: use Targeted mLDP for the level 3.5 signaling, as specified in
the following two drafts:

     draft-napierala-mpls-targeted-mldp
     draft-rosen-l3vpn-mvpn-segments

However, the issue I want to focus on in this message is not whether mLDP is
a better protocol to use than BGP, but whether we have the proper model for
control flow in the seamless MPLS environment.  Either protocol can be used
to provide a seamless model without bringing service-specific processing or
state into the transport nodes.

Discussion?

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 27 May 2011 09:20:32 -0700

Eric,

> Although the "seamless-mcast" draft claims to specify the way to
> do MPLS multicast in the seamless MPLS model, the procedures it
> specifies are much more like the multi-segment pseudowire model
> than like the seamless model.  For the MVPN service, the draft has
> the service nodes and the border transport nodes exchanging
> MVPN-specific control messages and performing MVPN-specific functions.
> The border routers at the upper level of the hierarchy have to
> maintain MVPN-specific state, and the amount of state maintained
> is proportional to the number of MVPN states maintained by the
> service nodes, not proportional to the number of transport tunnels
> that are needed.

Please note that the MVPN states at the border routers is the control
plane states only, as the data plane state is determined by the
number of transport tunnels that are needed.

> For example, a PE might send 100 S-PMSI A-D routes, each one binding
> a customer flow (C-S,C-G) to a P-tunnel.  But these 100 S-PMSI A-D
> routes might all have the same PMSI Tunnel Attribute (PTA); that
> is, the PE might bind each of these 100 C-flows to the same P-tunnel.
> In seamless MPLS, the transport border nodes should have one state
> for the P-tunnel, not 100 states for the C-flows.  The transport
> border routers do not care what the P-tunnel is being used for.
> And since the border routers do not perform MVPN-specific functions,
> they will not be deaggregating and reaggregating the C-flows.  The
> border routers may decide to aggregate the P-tunnels in some way,
> but they should not deal with anything more finely grained than a

In the case where all these 100 S-PMSI A-D routes are for the same
C-G, and C-G is in the ASM range, all one needs to do is to use a
single (C-*, C-G) S-PMSI A-D route (instead of 100 S-PMSI A-D
routes).  The seamless-mcast draft does apply to this case, as it
does support (C-*, C-G) S-PMSI A-D routes.

Now let's consider the scenario where these 100 flows are for
different C-Gs. The example that you described above *implicitly*
assumes that the (ingress) PE performs aggregation at the granularity
of the whole (inter-area) p2mp LSP (as all these 100 flows are
aggregated into the same P-tunnel). That is, *in addition* to
whatever aggregation one could perform at the granularity of the
intra-area segments, the example also assumes that the aggregation
is performed at the granularity of the inter-area p2mp LSPs.

When one can perform aggregation at the granularity of intra-area
segments, there are good reasons *not* to perform aggregation at
the granularity of inter-area p2mp LSPs. This is because when
aggregating p2mp LSPs, to reduce b/w inefficiency, one need to
perform leaf tracking. The overhead of leaf tracking, when aggregation
is performed at the level of inter-area p2mp LSPs, is higher than
when aggregation is done at the level of the intra-area segments.
Furthermore, aggregation at the level of inter-area p2mp LSPs reduces
the choices that could be applied at the level of intra-area segments,
which has adverse impact on the ability to reduce b/w inefficiency
(b/w inefficiency is due to partial congruence).

And if for the reasons mentioned above one does not perform aggregation
at the granularity of inter-area p2mp LSPs, then your example above
does *not* apply in the context of seamless-mcast (as seamless-mcast
provides aggregation at the granularity of intra-area segments).

> environment in a more seamless manner, keeping MVPN-specific
> functionality off the transport nodes, while still gaining the
> advantages of LSP hierarchy that the seamless MPLS model tries to
> provide.
> 
> The MVPN specifications really provide three and a half "levels"
> of signaling:
> 
>    from one PE to another.  This level of signaling should involve
>    only the PE routers (the service nodes).
> 
>    P-tunnels they need to join, as well as the information needed
>    by the third level of signaling.  This level of signaling is
>    done via BGP.
> 
>    P-tunnels, this level of signaling is done via mLDP, RSVP-TE,
>    or other multicast tunnel setup protocol.
> 
>    For segmented P-tunnels, there is a "level 3.5" of signaling,
>    that carries information among the segment endpoints.  (When
>    ingress replication is used to instantiate the P-tunnels, level
>    3 signaling is not needed, though level 3.5 signaling might still
>    be needed.)
> 
> In a seamless MPLS environment, I think the A-D signaling should,
> like the C-multicast signaling, should only involve the service
> nodes.  It should be PE-PE signaling, most likely through
> service-specific route reflectors.
> 
> The P-tunnel setup signaling (levels 3 and 3.5) should involve the
> transport nodes, of course, but in the seamless model, this level
> of signaling should be service-independent.  The basic concept of
> this level of signaling should be the P-tunnel.
> 
> The proposal in the seamless-mcast draft uses the MVPN A-D signaling
> for the level 3.5 signaling.  As a result, the "P2MP FEC" used by
> the level 3.5 signaling is the NLRI of the A-D routes, rather than
> the P-tunnel.
> 
> If we don't try to piggyback the level 3.5 signaling on the level
> 2 signaling messages, and we do the level 3.5 signaling on a
> per-P-tunnel basis, we can provide the following control flow model:
> 
>    Let's suppose, e.g, that we want to create a three-segment
>    P-tunnel, with each segment created by RSVP-TE.  IMHO, the desired
>    flow of control is:
> 
>       (C-S2,C-G2) and (C-S3,C-G3) to a particular P-tunnel.  For
>       this example, let's say that the PMSI Tunnel Attribute (PTA)
>       identifies the P-tunnel using an mLDP P2MP FEC element:
>       <root=PE1, opaque value = X>.
> 
>       <root=PE1, opaque value = X> tunnel is being carried within
>       an identified RSVP-TE P2MP LSP.  If the RSVP-TE P2MP LSP is
>       aggregating other P-tunnels, PE2 would include an upstream-assigned
>       label.
> 

Please note that what you outlined above follows pretty close to
the Internet multicast for PIM-SM in SSM mode procedures specified
in the seamless-mcast draft.  E.g., with these procedures the ability
of a PE to send a Leaf A-D route to another ABR does not depend on
the PE's having first receive any A-D route from that ABR.

While in the current seamless-mcast spec on the egress PEs these
procedures are triggered by receiving PIM or IGMP message from their
CEs, the trigger could be augmented by receiving S-PMSI A-D routes
with a particular Tunnel Type in the PMSI Tunnel attribute. From
that point on, one would just follow the currently specified
seamless-mcast procedures for Internet multicast for PIM-SM in SSM
mode.

There is no need to invent a new "P-tunnel Join Request" message -
the existing Leaf A-D route is sufficient. Likewise, there is no
need to invent a new "P-tunnel Join Response" message - the existing
MVPN S-PMSI A-D route is sufficient.

So, the control flow model that you asked above could be provided
within the framework of the current seamless-mcast draft.

Yakov.

---

From: "NAPIERALA, MARIA H (ATTSI)" <[email-masked]>
Date: Fri, 27 May 2011 17:38:36 -0400

> (b/w inefficiency is due to partial congruence).

The problem with the aggregation done only at the intra-area level is
that the ABRs need to participate in leaf tracking for specific customer
(*,G) or (S,G) states. 
It is not desirable from SP core network stability/scalability
standpoint to have such "service" visibility on ABRs.  It goes against a
design principle stated in the seamless-mpls, in 2.1. "Why Seamless
MPLS": "The Seamless MPLS architecture [...] decuples the service and
transport layer".
In addition, the "aggregation" at the inter-area level is not only used
in conjunction with leaf tracking but it also allow to control the
number of P-tunnels that need to be signaled across SP network. This is
possible only when PMSI A-D routes are exchanged between service
nodes/PEs out-of-band.

_______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls