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

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

Hi Mark, please see in-line. regards, Neil
BTW - Going to be rather busy now for next week or so.....so if any further
questions to me on mail may not get an answer.
> 
> 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.
NH=> You won't get it.....its not PC to say this here in IETF.  It's got
nothing to do with the use or not of a distributed routing protocol
(atm/pnni can use this, for example), and all to do with the forwarding mode
behaviour.....and MPLS (any variety of such) is quite distinct to IP's
behaviour here.  I've seen/had some minor players try and argue its not true
(trying to deflect/defend the problems created by LDP mp2p) but not the
major players.  Arguing this just wastes time/energy.  Maybe the SDH and OTN
(GMPLS) data-plane also has cnls forwarding behaviour too ;-).
> 
> 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.
NH=> It can exist (and does), but my point is that it creates problems in
other dimensions....and in my view the problems outweigh any advantages.  If
one wants any-any connectivity a cnls mode (ie IP) is the right
(WA)networking solution (as this does not have the data-plane problems).
Merging using link-connection-only unique identifiers is not a 'good thing'
to do from a trite architectural analysis.....you lose sight of the source,
so if you use a mp2p mode you are forced to also run something p2p over this
to provide the source information. If people started to use the functional
models of G.805 this fact would become very obvious.  
> 
> BTW, what is your view on IP multicast. Is this a
> different mode than normal IP CLNS, or is this the
> same?
NH=> Don't confuse mp2p *merging* and p2mp broad/multi-cast....these are
*not* the same thing architecturally.  Note that there is no such thing as
mp2p/merging in a cnls mode......this is multiplexing as the
source/destination are identifiable in any 'merged' stream of cnls pkts.  A
p2mp topology is valid in a cnls, co pkt-sw mode and a co cct-sw mode.  The
source is constant/identifiable in the co modes and the only difference is
single vs multiple target locations.  Again, modelling using G.805 would
reveal the behaviour/validity.
> 
> 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?
NH=> I would not say it like this.  What is happening is that the bridging
functionality is being moved into the WAN, and one is asking/expecting the
SP to somehow (yet to be figured) use this functionality (in some shared
way) to advantage.  We are not, as yet, convinced this is a Good Thing.
> 
> Why do subscribers care? Well I will concede it may be
> an artifact of business models (per-vc pricing).
NH=> I don't believe customers care how *we* provide their ethernet
services.....and esp whether we build based WANs based on ethernet/VLANs.
Customers mainly care about $/bit and reliabilty/security.....and they only
care about QoS issues when they suffer unacceptable performance (in general
they expect things to 'work' at reducing prices).  Our job as a SP (and my
job specifically) is to make sure we deliver these aspects at min opex/capex
cost.

They have an ethernet interface on their CPE and want to use it.  How we
deliver the traffic from customer site A to customer site B is our problem.
If it can be shown that building ethernet based WANs and using VLAN
technology offers us some advanatges (esp cost) then great....but so far we
are not convinced.  So I don't believe it is customers who are driving this
view but (i) those wishing to sell boxes and (ii) those who 'believe' this
is the right solution from some philosophical standpoint.  From a pure
architectural perspective, ethernet as-is is simply not designed to
scale/work in the WAN environment.......that is just a fact.  If it can made
to work satisfactorily then fine.....but as I say we have yet to be
convinced.

> 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.
NH=> Its too early to make a call on this in our opinion.  In the meantime
we will use other means to deliver ethernet *interfaced* services.
> 
> 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.
NH=> Then let's wait and see what emerges.
> 
> 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.
NH=> That's fine.  However, taking such a stance is hardly in the best
interests of the customer and the wider operator community....all solutions
should be considered without prejudice.
> 
> 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=> If one started to use G.805 arch models to describe/define the networks
being discussed (rather than just lines/boxes) much of the issues would
become obvious.  BTW I was talking specifically about the PW entities that
are being created, not the 'higher' client layer implications that in the
VPLS case you raise and are related to ethernet behaviours.
> 
> >> 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.
NH=> Why not?  It's important.  I want to see the number of nested network
layers we have to manage reduced to a minimum......there are many reasons
for this (hopefully most are obvious).  However, this statement is *not* the
same as saying we can functionally crunch the cnls/co pkt-sw/co cct-sw into
some God-Box.....that approach is both technically flawed and commercially
flawed.   PWE3 is creating more things that can go wrong and need to be
managed....much of this is unnecessary, and being done to fix problems
created in (MPLS) server layer networks and the irrational view that X/IP
must 'be the same' as X/MPLS.
> 
> 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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

---

From: Mark Seery <[email-masked]>
Date: Wed, 7 May 2003 07:51:34 -0700 (PDT)

Neil,

>> NH: BTW - Going to be rather busy now for next week
or so.....so if any further questions to me on mail
may not get an answer. <<

Understood. You have been generous with your comments
already - so good luck with whatever it is that keeps
you busy.

>> NH: ....you lose sight of the source, so if you use
a mp2p mode you are forced to also run something p2p
over this.. <<

Fair enough. I'll do some more thinking about whether
I conclude PWE is another connection or just an
encapsulation [no need to respond]

>> NH=> That's fine.  However, taking such a stance is
hardly in the best interests of the customer and the
wider operator community....all solutions should be
considered without prejudice. <<

I will give your advise some more thought. In response
I would simply observe the charter: ".....while using
IP-based mechanisms in the provider infrastructure to
improve scalability and configurability over
traditional L2 networks)."

I don't think you can totally avoid being contextual.
While you are contributing to a WG you kind of have to
have some respect for the rules that have been agreed
to. You can always take that hat off, step outside of
the WG (as ADs often do) - indeed the IETF (in private
emails, of public comments in other forums), and make
another set of observations and comments. 

>> NH=> Why not?  It's important. I want to see the
number of nested network layers we have to manage
reduced to a minimum. <<

My response was very badly worded. What I meant to
communicate is that as a non-operator, you come to see
so many different networks, vary amounts of "legacy",
organizational structures, strategic initiatives,
etc....that at some point you begin to feel that it is
really arrogant to say that one approach meets
everyones needs - maybe it is just an illusion, but
things do seem to be different from operator to
operator. 

As I said in another post, I can see how a selection
of p2p, automated mesh, and multipoint (we can argue
about which type) server layers might enable a broad
range of operators to meet their needs. At the end of
the day the pragmatic issues of the boxes people have,
the boxes they could have, and how well they work
together and cost, tend to have a large influence on
decisions. 

Would it be nice if sometimes we slowed down and
considered the long-term implications of what we are
doing? You won't get an argument from me - but I also
understand that people/cultures will tend to
self-optimize for the period of time in which they
live - or endure the consequences; life in the jungle
101 ;-)

The IETF is becoming, or has become, a big tent. Big
tents are tough to manage - no question. 

Mark