Subject: clns vs co as underlying model for VPN services

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 6 May 2003 17:31:47 -0700 (PDT)

Neil,
You bring up a set of very interesting questions. I confess i've a
fair ammount of dificulty following your terminology so it is likely
that i'm misinterpreting what you are saying.

If i understand what you are saying, you suggest that one of the first
things to keep in mind in designing a VPN service is that it basically
consists of a co pkt-sw service.

It seems to me that while that is one possible model it is not the
only possible model and that a comparisson is worthwhile.

So what is the clns model for VPNs ? (I believe most people understand
better than myself so the following is mostly to validate my
assumptions).

Consider a network that contains core only nodes (P-nodes) and edge
nodes (PE-nodes).

PE-nodes have the capability to allocate a forwarding equivalence
class (FEC) indentifier (for lack of better term). This FEC identifies
the forwaring nexthop of the traffic on this node. FEC-IDs are the
equivalent of 'destination addresses' on IP packets as far as
forwarding is concerned. As Neil mentions these are effectivly mp2p
identifiers.

P-nodes on the other hand do not know anything about this service
specific FECs. Their concern is to provide forwarding services to
PEs. This services can be p2p, p2mp or mp2p (merging is typically
used).

So why do this ? It is all the nice properties that Neil dislikes :-)

The core network (P-nodes) deals only w/ aggregated flows. This flows
can be p2p (eg: rsvp-te), mp2p (via merging either by LDP or inter-as
BGP MPLS signaling) and hopefully in the future they will be p2mp
also. The idea being that using aggregated flows you can control your
traffic as you see fit and then appropriatly map service-FECs to these
aggregated flows.

So what is the advantage w/ the service FECs being mp2p. When your
service definition does not require you to identify the source, using
mp2p FEC(labels) allows you to allocate 1 inner label that identifies
the forwarding nexthop regardless of the ingress.

When your service definition requires you to identify the source, then
you must allocate N mp2p labels in order to achieve a 1-to-1 mapping.

But using the same architectural pieces you can express both
models (source and no source identification). And do so while
optimizing it for the worse case in terms of state. Also you can
decouple the service-FEC from the PE-PE transit layer.

The latter is imho one of the key pieces missing at this point. It
would be nice to be able to map N services into M tunnel technologies
without using N*M mechanisms. That requires layering and a definition
of what your interfaces should be.

Note that there are also services which i would classify as L2 which
don't require source identification and are effectivly mp2p. The
example i have in mind is when a SP provides a carrier-of-carriers
service to its customers in which the 'routes' are limited to /32s
representing remote attachement points. This can effectivly be used to
provide a service that can run on top of any media and that provides
an mp2p LSP to any other customer attachement point to the VPN.

For people running clns traffic on top, mp2p is a good service
model.

Maybe the rest of the WG members can correct my misunderstandings and
mischaracterizations.

And maybe the folks that are more knowledgeble of co mechanisms can
explain in what way that model is superior.

  Pedro.

---

From: [email-masked]
Date: Wed, 7 May 2003 09:00:13 +0100

> that i'm misinterpreting what you are saying.
NH=> Reading what you wrote I'd say 'yes' we have a communication
issue.....so rather than sending lots of mail and going over old ground on
this I'll send you my TEl No in a separate mail and we can discuss off-line.

regards, Neil