Subject: RE: Comments on the L2 VPN framework and solutions documents

From: [email-masked]
Date: Sat, 26 Apr 2003 08:32:06 +0100

Norman...I'd go further than saying that.....it's proposing reinventing cnls
networking (data-plane aspects too).   There is a massive difference in
recognising the importance of ethernet as a key CPE *interface* and then
(somehow) making the (wrong) extrapolation that this means ethernet is a
great WAN technology.  All *scalable* WAN networking modes (of which there
are only 3, viz cnls, co pkt-sw and co cct-sw) must have at least 2
functional components:
-	addressing:  from a space that is large enough, and carries
semantics of 'where' (not 'who'...that is a name) and thus aggregatable;
-	consistent topological network map:  whether centralised or
distributed, to allow consistent route calculation.

They must also have other functional components to make make them
'operationally viable', but addressing/routing are the min set.  Ethernet as
a technology does not have addressing/routing functional components that
meet the WAN/scalability criteria.

{Aside:  As an aim (to stop doing stovepipes, ie 'technology==service' and
to minimise problematic gateways for data/control-plane functions) we
operators (or at least BT) are seeking functional convergence *within* each
of the networking modes but not *across* them (that one makes no technical
or commercial sense).  So we agree with you that to try and turn ethernet
into a next generation cnls network is a 'bad idea'....we have IP for that
job.}

Therefore, short of fundamentally re-working what ethernet is today, the
only pragmatic way to handle ethernet services in the WAN is to accept that
a proper WAN technology must act as a server layer to proxy for the missing
functions.  SDH/GFP is a good solution.  MPLS *could* be a good
solution.....but it would need recognition that:
-	it is a layer network in its own right, eg it needs its own
addressing regime (actually it subconsciously(?) gets this, but its
different for each signalling type used and that is not a good idea);
-	it belongs to the co pkt-sw mode (not the cnls mode, that is IP) and
thus does *not* have to be constrained by the limitations of a cnls mode, eg
in a client/server sense X/MPLS is *not* the same as X/IP.....and it saddens
me to see PWE3 try to treat them like this as though this is a 'good idea'
when its just dogma;
-	it needs proper OAM solutions......but the only topological
constructs that make networking sense in a co pkt-sw mode are p2p and
p2mp......mp2p constructs just create problems for no benefit (if one wants
this sort of behaviour, use a proper IP/cnls mode which is designed for this
behaviour and where these problems don't exist).  Further, given X/MPLS and
X/IP are different animals, then we want to see as much functional
independence between the client (X) and the server layers (MPLS or
IP).......and we don't want to see lots of in-between layer functions being
created (like PW OAM) that we also have to manage (noting that we still have
to manage the MPLS and IP layers anyway....so at least get these right in
their own right).

regards, Neil

> -----Original Message-----
> From: Norman Finn [mailto:[email-masked]]
> Sent: 25 April 2003 17:31
> To: Muneyoshi Suzuki
> Cc: [email-masked]; [email-masked]
> Subject: Re: Comments on the L2 VPN framework and solutions documents
> 
> 
> Muneyoshi,
> 
> I think that adding a TTL field to the MAC frame is an attractive
> idea.  I also think that it is an extraordinarily bad idea.  If I
> may paraphrase your argument, it is:  (Forgive me, please, for putting
> words in your mouth.)
> 
>  1. Routing is not reliable enough to establish the connections
>     that we need.  Bridge A might be able to talk to Bridge B, but
>     not to Bridge C.
> 
>  2. Spanning trees and full meshes, which don't require TTL, are
>     not good enough, for the reasons thoroughly discussed.  (By
>     the way, I very much agree with you that, for large N, a full
>     mesh will not be reliable.  My solution is to keep N fairly
>     small.)
> 
>  3. Therefore, we'll add TTL and use OSPF to route the MAC frames.
> 
> What I don't understand is how you have solved the problem that
> Bridge A could not talk to Bridge C!  Why is your toy routing system
> going to be any more robust than the existing routing system?
> 
> This approach is not flawed because it is reinventing bridging.  It
> is flawed because it is reinventing routing.
> 
> -- Norm
> 
> Muneyoshi Suzuki wrote:
> > 
> > Joris,
> > 
> > Thanks for clarification.
> > 
> > First, needless to say, I aware link block problem of STP/RSTP. We
> > definitely need a solution. However, the solution must be robust.
> > To enable large scale deployment, it must not force the operators
> > and users to reboot boxes even if the worst case. The full mesh
> > approach is a fragility solution that has loop, blackhole 
> or unreliable
> > flaky PEs problems, so we have no choice other than the 
> conventional scheme.
> > 
> > Second, if we regard xSTP as routing protocols, obviously 
> there are less
> > efficient than OSPF/BGP. However, if we regard xSTP as protocols for
> > protection, these are not bad. If we reserve paths for fast 
> protection
> > for the mesh, there are active and standby meshes. I think 
> this problem
> > is not much different form xSTP link block problem.
> > 
> > Finally, as far as I know, currently providers don't use 
> STP due to long
> > recovery time; instead manually configure a single tree 
> topology. However,
> > a single tree topology is not bad. Please image 
> conventional telephone
> > network architecture; it is a tree. A tree is one of 
> fundamental network
> > architecture. However, needless to say, topology free is 
> much better than
> > a tree. Therefore, I proposed OSPF or BGP-4 extension for 
> MAC routing
> > in Atlanta meeting (please see my slides in the last 
> November). I think
> > it is not easy to progress this work in the IETF, but I 
> believe we need
> > this kind of work in the near future.
> > 
> > Thanks,
> > 
> > Muneyoshi Suzuki
> > Nippon Telegraph and Telephone Corp.
> 
> 
>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Tue, 29 Apr 2003 16:05:55 -0400

Neil,
> There is a massive difference in
> > great WAN technology.
I think this is an important point.
The next question then is what should end-customers with multiple sites
but a single Ethernet interface to provider do?

Thanks
Cheng-Yin.