Subject: RE: FW: Single vs many solution(s)

From: [email-masked]
Date: Tue, 6 May 2003 23:58:12 +0100

Hi Mark.....in-line please.

regards, Neil

> Neil,
> 
> >> NH: Operators need *all* 3 mode....<<
> 
> Is there any publicly available information explaining
> the rationale for this statement? Not disputing it,
> just like to understand the details of the logic.
NH=> This is actually an excellent question.  My logic is based on what we
sell, what customers want, and what makes sense architecturally to cover a
diverse set of customer services (noting also the fact that MPLS (and even
GMPLS) found it necessary to come into existence even in IETF).  I am not
aware of any studies supporting this view (or any other view).....just a
'proof by existence'.  But I find it hard/impossible to imagine a networking
world where all 3 modes would not find a logical application.....just like I
find it hard to imagine a people/goods transport solution based only on
trains.
> 
> >> NH: Let's consider the VPN problem we are trying to
> address using MPLS as the common co pkt-sw core server
> layer technology and see if we can identify what is
> common and what is not common. <<
> 
> When you say "we" I assume you mean BT.
NH=> No I didn't here, I meant 'we' in the sense of 'the engineering
community at large'

> It is not
> clear to me that is a generally accepted truth.
> Forgetting about the IP option for a second, it would
> seem that the very presence of PWE suggests another
> server layer (as I think you have essentially stated).
NH=> How many PWE3 switches are you aware of?  This is a key
point....networking entities that only exist at 2 points are more like
'end-end applications or sessions'.  To qualify as a layer network implies
(amongst other things, esp addressing) that we have nodal switching.  PWE3
stuff is more of an adaptation function that has, unfortunately, started to
take on the characteristics of a layer network without actually being
one.....largely to proxy for missing/poor functional components of
technologies that are proper layer networks.
> 
> But more importantly, it is not clear that there is
> consenus that LDP provides a co pkt-sw capability, in
> fact I've seen many arguments to the contrary,
> certainly within the MPLS WG; and I know at some level
> you are yourself concerned that it does not, so seems
> some consensus on this issue is required if we go down
> the road of defining functional requirements.
NH=> How much space do I have to answer this?......I will try and be brief.

A co pkt-sw forwarding modes uses link-connection identifiers (aka labels,
DLCI, VPI/VCI, etc) that only have the requirement of link uniqueness, cue
FR, ATM, MPLS.  Such link-connection identifiers only have any networking
currency when associated with a parent trail entity......this is what
connects together 2 disjoint globally addressable access points in a layer
network.  If the parent trail does not exist then the link-connection
identifiers have no network currency....should be obvious I hope.  So some
form of signalling protocol is required to assign the link-connection
inter-nodal identifiers and bind them to their parent trail (when that trail
comes into existence, and remove when it is torn down).  None of this is
required in a cnls mode.

Note this has nothing to do with routing protocols......both cnls and co
pkt-sw (or even co cct-sw) modes may or may not use distributed routing
protocols.....this means absolutely nothing wrt the networking mode, only
the forwarding classification dictates the network mode.  In terms of
functional data-plane behaviour however, this means a cnls traffic pkt must
contain both globally significant source and destination addresses (and as
an aside it means each/every cnls pkt carries its own CV function).  This is
not true for a co pkt-sw mode (hopefully obvious)....so one can get defects
arising in a co pkt-sw mode that simply cannot exist in a cnls mode, eg
swaps, mismerging.

Now a cnls mode has no a priori trail connectivity by definition.  A co
pkt-sw mode does however.  If we 'merge' in a cnls mode it is not really
merging at all but simply multiplexing as each/every pkt is uniquely
identifiable in a 'merged' stream of such pkts by virtue of the SA/DA it
carries.  If we merge in a co pkt-sw mode then we lose sight of the
source....and which is why BTW, in all applications of LDP mp2p there is
always some level of LSP above this that identifies the *source* (the mp2p
LSPs only identify the *destination*) to allow 'demerging'.

So merging in a co pkt-sw mode is a bizarre topological thing to do.  The
native topologies that make sense (ie preserve source identification) in a
co pkt-sw mode are p2p and p2mp.  mp2p topologies in a co pkt-sw forwarding
mode *demand* higher level demerging p2p constructs above them.  However,
this does not mitigate against all the problems the mp2p topologies
create......such as their fault-management or the perceived need to run some
form of ECMP over them if they just track an IGP based on SPF (a sort-of TE
function).   There are a whole list of problems that mp2p co pkt-sw
constructs therefore create.  Do you really want me to list them all?

I don't see any real issue/argument here.  We simply have to accept MPLS
uses a co pkt-sw forwarding mode (because its just a fact) and that in such
a mode the only topological constructs that make any sense are p2p and p2mp.
Sure you can use mp2p.....you just pay for it in other ways.

Can we put that one to bed now please?

> 
> >> NH: 5. ethernet/VLANs.  The client is ethernet with
> or without VLAN identifiers.  Client layer address
> distribution is done directly in the client's
> data-plane based on broadcasting/learning/aging. There
> is no *forced* need for an operator to own this
> problem.....all the ethernet/VLAN/bridging/etc
> functionality can be done in the client layer and all
> the operator doing is providing a simple MPLS VPN
> (like ATM/FR today). <<
> 
> So I think I have argued one way or another that I am
> concerned about putting too much Ethernet client stuff
> in the network so keep that in mind as I make the
> following comments.
> 
> The problem with today's client/server model is that
> the server layer is a point-to-point trail,
NH=> This is not a 'problem' per se, in a co pkt-sw or a co cct-sw mode this
a *fact*.  If one wants a any-any cnls behaviour then use the right
networking mode for this.....which is cnls/IP, don't fudge the co modes to
do something IP does far better and arch correctly.

> that means
> if the operator wants to offer a switched service
> based on the client payload, then the PDU has to be
> popped out of the trail and switched by a different
> piece of equipment, i.e. there is a difference between
> a switched transport infrastructure and a switched
> service.
NH=> Not exactly sure what you mean here....but it sure read like 'terminate
the server layer and switch the (payload) PDU in the right client layer
which is appropriate to the mode in question'.

> Seems to me that the unspoken aim of VPLS is
> to avoid this.
NH=> Agreed about the 'unspoken' bit.....so far at least, though we are
asking the question 'why' should the SP (WA)network take on this role, in a
technology that, although having the hallmarks of cnls (ie each PDU carries
SA/DA pairs), does not have the 2 principle functional components to even
contemplete WA(network) scaling, ie addresses that carry the semantic of
'where' (as opposed to 'who'...which is a name) and therefore no aggregation
capability, and of course no routing capability.  Is that not why the
'network layer' was invented in the 1st place? 

>Now should we intermingle the client
> layer switching/briding solution together with the
> server layer solution - this is where I see potential
> for inter-standards body conflict and architectural
> conerns.
NH=> And that is precisely why I tried to suggest divorcing them, viz: there
is a common (across all VPN types) *server* layer problem of topology
discovery/construction, and a secondary problem that is client layer
specific wrt 'information' (routing/addressing/reachability...call it what
you will) distribution above this.  
> 
> Additionally, with point-to-point trails a mesh is
> required.
NH=> This is a red-herring and a source on continuous misinformation that
keeps cropping up.  If A wants to talk to B using a co mode then *something*
has to be configured p2p between A and B in the *data-plane*.....you simply
cannot avoid this.  Automating the process is key however.

> from the subscriber/access to inside the edge/core
> network. This is one incremental step in the right
> direction; and maybe an important first step to get to
> market etc.
NH=> For whom?  Don't hear many customers screaming for us to build ethernet
WANs....they ask for ethernet CPE interfaces yes.  How we deliver across the
WAN is not their concern.

> Ultimately though, the option of having a
> true multipoint server layer might be an interesting
> option to pursue - if it can be managed etc.
NH=> Not sure what you are looking for here....the right answer to your
quest has, I think, already been defined....its a cnls mode called IP and it
already does this.  Just stop looking for an answer in a co mode....it does
not exist.

> What some
> VPLS solutions are saying is that we have solved the
> mesh problem by automating the provisioning -
> excellent answer, and important.
NH=> Agreed, but this is the automating of the basic VPN (any) *server*
layer problem I previously mentioned.

> But another way of
> solving the problem would be to provide a multipoint
> server layer.
NH=> Please elborate.  AFAIK this problem is solved for scalable WAN
solutions...its called IP.

> That would leave three options for
> service providers to choose from:
> 
> 1. point-to-point transport to a client layer
> switching function
NH=> We must be able to provide this one as the default.

> 2. edge-to-edge mesh that emulates a client layer
> switching function
NH=> Not clear how this is different to the above case

> 3. multi-point server layer
NH=> This is cnls IP IMO.
> 
> So then the question I would ask the WG, chairs, and
> ADs is it acceptable to solve one problem along three
> different (network)architectural paradigms, where you
> have one solution per paradigm, or must we select one?
> (we are of course looking like getting 1) and 2)
> anyway so we will already have more than one); 
> 
> Why would we need both 2) and 3) well it may turn out
> that solving QoS, traffic engineering, and management
> problems are very complex to solve with 3) and
> therefore 3) may give some charateristics which are
> suitable for some service descriptions/operators but
> not others.
> 
> Mark
>

---

From: Mark Seery <[email-masked]>
Date: Tue, 6 May 2003 17:08:52 -0700 (PDT)

Thanks Neil,

Is MPLS co-pkt-sw or CNLS?
==========================

I won't take up space arguing this, my only point was
that I had not observed consensus, your good points
not withstanding. Perhaps I missed the consensus.

Multi-point co-pkt-sw
=====================

So I read from your reply that you believe, for
reasons stated, that a multipoint co-pkt-sw mode does
not exist, and would not be valid to exist.

BTW, what is your view on IP multicast. Is this a
different mode than normal IP CLNS, or is this the
same?

P2P as misinformation
=====================

So you don't agree that HVPLS et el have moved the
mesh from the CPE in to the network? Or just that no
subscriber cares?

Why do subscribers care? Well I will concede it may be
an artifact of business models (per-vc pricing).
Though touching each CPE everytime a new site is added
does create potential for error, and may actually
concern a subscriber - as opposed to an automated
model by whatever means. I'll also grant that some
operators have automated the process via management
plane, but some have not, and may prefer not to. I
will also grant that the tradeoff for when to use
control plane vs management plane is sometimes viewed
in the context of the time the circuit is alive for -
but not really wanting to go off on that particular
tangent.

But the working assumption is that there is a problem
to be solved; that much I can observe whether I agree
or not.

The value of Ethernet WANs
==========================

To argue that there is no value in switched Ethernet
WAN/MAN services is essentially to argue that this WG
has no reason to exist - I think? I'm not sure I want
to pursue this line of discussion, on this mailing
list ;-)

As to whether Ethernet lacks the capability to scale
as a WAN technology, this seems also to be an unspoken
assumption of this WG. The support for various VPLS
proposals would suggest that in the minds of a number
of people those problems are being addressed.

I agree with you as to the importance of Ethernet as a
subscriber interface. I agree Ethernet WAN services
can be offered in multiple ways preserving investment
in existing technology or leveraging investment in new
technology. But at the end of the day, the charter of
this particular WG is to solve the problem using a
bounded set of technologies - which is why the
discussion may be narrower than what you would like; I
certainly engage in broader technology discussions
when interacting with carriers, as I am sure many do
on this list, but do want to respect the mission of
this standards group, and this WG.

Some other responses to clips below.

Thanks again for the substantive responses.
Regards,
Mark

>> NH=> How many PWE3 switches are you aware of?  This
is a key point....networking entities that only exist
at 2 points are more like 'end-end applications or
sessions'. <<

Interesting point, and one well worth thinking about,
I would only observe, that VPLS is not an actual
switch - it is a distributed, emulated switch, based
on p2p connections; which is at some very abstract
level, just an explosion of what happens inside many
systems (where the "server" layer is managed by a
fabric header).

>> NH=> Not exactly sure what you mean here....but it
sure read like 'terminate the server layer and switch
the (payload) PDU in the right client layer which is
appropriate to the mode in question'. <<

Well apart from the value judgement ;-) yes, that is
what I said - I only tease here because there is a
valid discussion to be had about home many transport
layers one network needs - but let's not go there. 

So popping out to a client layer is a valid way of
solving the problem, VPLS is suggesting there is
another way; the unspoken assumption that the VPLS way
also allows for the delivery of other services on the
same "switching" network. Which would naturally lead
to a discussion of
pros/cons/tradeoffs/economics/feasibility (in the case
of Ethernet) that is perhaps beyond the scope of the
WG.