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

From: Mark Seery <[email-masked]>
Date: Fri, 25 Apr 2003 23:04:25 -0700 (PDT)

Yakov,

<Yakov: Moreover, doing MAC lookup  on border routers
(aka VPLS gateways) would also require the service
provider to run STP on a per VPLS customer to make
sure that there is no looping when either (a) a pair
of ASs have more than one interconnect...>

There have been switched Ethernet networks implemented
where dual links to a common entity (for example the
subscriber) did not require STP. These architectures
depended on non-Standard features in the Ethernet
switches (e.g. layer 2 equivalent of HSRP/VRRP) + MAC
address learning at the other end. Whether a
non-standard approach is a solution or not....Whether
this is better or worse than STP......

<Yakov: How do you know that for most VPLSs "the
customer is not multi-homed" ?>

A valid question. There is no clarity in my crystal
ball as to whether subscribers (in the majority) will
find this option attractive, but SPs will (and do)
offer it. Once again this problem can be solved
without STP, but it does require additional mechanisms
at the (virtual) switch.

In addition to "multi-honing" by whatever definition,
the history of transparent LAN service includes real
world experience with subscribers inadvertently
creating back door loops through a non-TLS service
interface, this has led to the use of per-subscriber
STP. 

Mark

---

From: [email-masked]
Date: Wed, 30 Apr 2003 00:45:45 +0100

Cheng-Yin.....well, our current view is that VLANs live in the
customer/corporate domain, and that the safest solution at this time is to
use hard BW partitioning at L1/2 to isolate them.

regards, Neil 

> -----Original Message-----
> From: Cheng-Yin Lee [mailto:[email-masked]]
> Sent: 29 April 2003 21:06
> To: Harrison,N,Neil,IKL2 R
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Comments on the L2 VPN framework and solutions documents
> 
> 
> Neil,
> > 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.
> 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.
> 
> [email-masked] wrote:
> > 
> > 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.
> > >
> > >
> > >
>