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

From: "Cheng-Yin Lee" <[email-masked]>
Date: Thu, 01 May 2003 11:44:11 -0400

Neil,
Could you elaborate a little on how to use L1/2 to isolate the p2p
Ethernet to different sites pls?
If the end customer has an Ethernet interface to the provider, and needs
to connect to multiple sites, what equipment is required at the customer
site?

Thanks,
Cheng-Yin

[email-masked] wrote:
> 
> 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.
> > > >
> > > >
> > > >
> >

---

From: [email-masked]
Date: Fri, 2 May 2003 09:44:50 +0100

Cheng-Yin,

We will provide such services via either SDH or ATM networks using
enhancements to the equipment that terminate these networks in a customer
facing direction.  Just think about it....we have shed-loads of SDH/ATM
equipment and it would be barking mad not to leverage it (same must be true
of many other large operators)......but its not simply that rather obvious
fact, we also have technical reservations about both MPLS and the usuage of
VLAN technology in a core/WAN network (esp if these 2 technologies are
related).

For example, just considering MPLS per se.......we would like to use MPLS as
a convergent common core co pkt-sw technology.....so this refers to the
'stovepipe' + gateway problem I have raised on mails previously, and the
need for functional convergence *within* each network mode but not *across*
them.  Each mode (ie cnls, co pkt-sw and co cct-sw) do different jobs, we
need them all, and they require different behaviours.  But if MPLS is going
to assume this mantle it needs to become 'fit for purpose' and a proper
layer network in its own right.  This is actually very simple to do as its
largely about 'removing' bad stuff, not trying to keep adding kludges to fix
the errors....specifically we don't want the arch monstronsities that PWE3
are creating to expedite the 'errors' and the incorrect arch view that X/IP
and X/MPLS must have the same treatment.

As I noted earlier:  there is a big difference in noting the *importance* of
ethernet as a CPE interface and then (wrongly) interpolating that to mean we
(operators) have to provide a WAN network with bridging/VLAN
capabilities.....this simply does not follow.  Ethernet does not scale as a
WAN technology because it does not have proper addressing
attributes/semantics and it has no routing ability.....other functionality
is missing too, but these are the 2 most elemental functional requirements
for *any* WAN technology (belonging to any network mode, be it cnls, co
pkt-sw or co cct-sw) to scale/work, esp for arbitrary topologies.

So we won't run with the herd if we don't agree with it.  Check out what we
recently bought at L1 and specifically the signalling protocol chosen.

BTW - If I can find time over the next week I may post some observations on
the 'my protocol is better than yours' debate wrt VPLS......they are all
missing the key point...which is all tied up in addressing, and the fact
that a L3 VPN is not the same as the VPLS/ethernet problem at all, and
neither is it the same as providing an arbitrary L2 VPN.  These are all
quite different issues, commonly related by a lack of proper MPLS layer
addressing.

regards, Neil

> Sent: 01 May 2003 16:44

---

From: Norman Finn <[email-masked]>
Date: Tue, 06 May 2003 15:51:30 -0700

Ching-Yin,

I have no objection at all to using something less than a full mesh
where the topology used is known to match the underlying data flow.
At the same time, I don't want to limit the solution offered by
L2VPN to those cases.

-- Norm

Cheng-Yin Lee wrote:
> 
> Norm, Muneyoshi,
> Norman Finn wrote:
> >
> > Muneyoshi,
> >
> > If you use spanning tree among the pseudowires connecting Islands,
> > as in:
> >                        pw A
> >      island 1 --------------------- island 2
> >            \                         /
> >        pw B \_______       _________/ pw C
> >                     \     /
> >                     island 3
> >
> > then one of pw A, pw B, or pw C must be blocked.  Let's suppose it's
> > pw C.  Then, all traffic from island 2 to island 3 must be relayed
> > by island 1.
> >
> > In other words, since wires are almost "free" in this space, one
> > tends to have a lot of them.  It the extreme case that you have a
> > full mesh of connections among all the participants in a net, spanning
> > tree is a particularly wasteful approach; it guarantees to block all
> > but N of the N*(N-1)/2 pseudowires!  (: Yes, a bridge-bigot is saying
> > that spanning tree is not optimal for all interconnect plans. :)
> If in the problem we are trying to solve, the islands are end customers
> LAN, and the traffic are mostly flowing to/from one or few hubs to a
> larger number of spokes, then there is no need to have a full-mesh of PW
> (partial mesh is sufficient), and the case where traffic flow is not
> optimal is infrequent then.
> I think it's fine to solve 80% of the problem well and optimize for the
> remaining 20%. A full-meshed with split-horizon seems to be optimized
> for the minority of requirements, but not solving the majority of the
> problem well (issues already being discussed and acknowledged on this
> list).
> 
> If the problem we are trying to solve is building very large LANs, then
> I think it's worth considering Neil Harrison point that "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."
> 
> > If you configure a relatively sparse interconnect plan, using just
> > a few pseudowires, and if those pseudowires approximate physical
> > reality, then spanning tree becomes more viable.  The scaling
> > problem for 3000 VPLS instances at 10 pseudowires each becomes 3000
> > VPLS instances at 2-3 pseudowires each, reducing the BPDU load from
> > 20,000 to 7,500.  I would remark that our best bridges top out at
> > somewhere on the order of 1,000 - 2,000 BPDUs per second, at this
> > time.  I need to think a bit more before I agree that this solution
> > "simple and robust".
> If we keep bridging to the furthest edge possible (e.g. in CLE or MTU if
> need be), then the number of VPLS instances is drastically reduced.
> 
> Perhaps until we agree on the problem we are trying to solve, it's hard
> to scope VPLS problem space.
> 
> Regards,
> Cheng-Yin
> 
> >
> > -- Norm
> >
> > Muneyoshi Suzuki wrote:
> > >
> > > Joris,
> > >
> > > > My question is: how do you deal with (portions of) the network, for which a
> > > > spanning tree would be a very inefficient forwarding means, because the
> > > > physical topology does not approximate a tree?
> > >
> > > Could you clarify this? What is spanning tree in the above context?
> > > 802.1D STP, or STP/RSTP/MSTP?
> > >
> > > If you are claiming STP topology change time is inefficient, the use of
> > > RSTP/MSTP should be considered.
> > >
> > > If you are claiming all STP/RSTP/MSTP are inefficient, could you clarify
> > > the issues?

---

From: Ali Sajassi <[email-masked]>
Date: Thu, 08 May 2003 16:02:38 -0700

At 05:46 PM 5/8/2003 -0400, Himanshu Shah wrote:
>I understand this approach. Its a simple approach.
>And if you want to run M-STP (1 instance) across PWs
>you may want to use this approach.
>
>However, the VPLS drafts in IETF explicitly
>talks about not having to run the P-STP across PWs.
>Dual-homing/external loop in Provider's network
>is handled without using P-STP.
>
>There seems to be some disconnect in understanding
>between these two groups that needs to be worked
>out.

I don't think there is a disconnect. When you talk about P-STP, you need to 
consider both intra-island and inter-island. P-STP is NOT used for 
inter-island - for that we use full-mesh with split horizon. However, for 
intra-island where you can have an arbitrary topology of bridges within an 
access domain, then P-STP is the only viable solution (refer to section 
11.2 of draft-lasserre-vkompella). Also keep in mind that P-STP is 
suggested for Ethernet access domain and not MPLS access domain.

-Ali

>/himanshu
>From: Mick Seaman [mailto:[email-masked]]
>Sent: Wednesday, May 07, 2003 6:42 PM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: [email-masked]; [email-masked]
>Subject: RE: Comments on the L2 VPN framework and solutions documents
>
>
>
>Himanshu,
>
>In (1) I think you have your layering a little mixed up. From the point of 
>view of control connectivity the pseudo-wires have to establish a full 
>mesh that is never perceived by layer 2 protocols as being less than 
>complete. STP is running across the service that runs on top of the 
>mechanisms that make the service LAN like. If you wish to provide subset 
>LANs to be configured then of course you can have subsets each of which 
>has full connectivity in itself. Just never try to pretend to layer 2 that 
>two non equal subsets are the same LAN.
>
>In (2) I think you are further into the same pit.
>
>It is trivial to get into BPDU scaleability issues along the path you 
>suggest. A much more attractive alternative is to maintain a single full 
>mesh for control connectivity which then prunes that mesh per VPLS (each 
>VPLS doesn't have to touch certain mesh nodes) and then uses that pruning 
>to delete VPLS specific pseudowires to the unwanted mesh nodes. Only one 
>instance of the topology determining protocol and the pruning protocol are 
>then required for all VPLSs. The trick here is to put provider 
>provisioning in at the right level in the architecture (i.e. not at the 
>pseudowire level,but higher up so that it can drive the pseudowire level 
>in the context of the actually available resources).
>
>Mick
>
>From: Himanshu Shah [mailto:[email-masked]]
>Sent: Wednesday, May 07, 2003 10:29 AM
>To: [email-masked]; Norman Finn; Muneyoshi Suzuki; Tony Jeffree;
>Les Bell; Paul Congdon; Neil Jarvis
>Cc: [email-masked]; [email-masked]
>Subject: RE: Comments on the L2 VPN framework and solutions documents
>
>
>This digresses from earlier thinking (at least mine)
>that P-STP would not span across pseudowires.
>
>There are several implications to running STP
>across PWs that may need to be clarified/worked out.
>
>1) "fully-meshed" attribute of the PWs only applied
>    within a context of a VPLS instance. That is, if
>    PE1 and PE2 participated in VPLS instance 1 than
>    there was no pseudowire to PE3 which did not
>    participate in VPLS instance 1. However, with this
>    scheme, each PE would have pseudowire to every
>    other VPLS capable PE irrespective of its VPLS
>    instance membership
>
>2) Assuming that 1 MSTP instance covers entire provider's
>    network, a backdoor link from ProvBridge1 to ProvBridge2
>    of VPLS instance 1, may cause 802.1ad's emulated LAN ports
>    to all VPLS instances (i.e. all PWs from that PE are
>    in blocked state irrespective of its VPLS instance
>    membership). Doesn't this block other VPLS instances's
>    traffic across PWs?
>
>    Perhaps my assumption is wrong and there is in fact
>    P-STP instance for each VPLS instance. However, if that
>    is true, PE would run into BPDU scalability issues.
>
>
>/himanshu
>
>
>From: Mick Seaman [mailto:[email-masked]]
>Sent: Wednesday, May 07, 2003 10:42 AM
>To: Himanshu Shah; 'Norman Finn'; 'Muneyoshi Suzuki'; 'Tony Jeffree';
>'Les Bell'; 'Paul Congdon'; 'Neil Jarvis'
>Cc: [email-masked]; [email-masked]
>Subject: RE: Comments on the L2 VPN framework and solutions documents
>
>
>
>If the fully meshed pseudowires (and the attached equipment/functions at 
>their ends) provide a LAN Service (stictly the Internal Sublayer Service 
>as defined in 802.1D and 802.1Q Clause 6.5 (same number clause in both 
>documents) then RSTP/MSTP will work just fine.
>
>To be more specific P802.1ad does specify the operation of a single 
>instance of MSTP within a Provider Network, how that travels over 
>pseduowires is of course how any LAN traffic travels over psedudowires 
>(i.e. the pseudowire protocol looks after making sure the configuration of 
>the pseudo wires correctly provides the fully connected LAN service, that 
>not being either MSTPs design goal or the desire of P802.1ad to specify 
>the simulation of LANs over non-LAN media, particularly where the non-LAN 
>media have native protocols that are to be used as part of the solution - 
>MPLS for example).
>
>Mick
>
>From: Himanshu Shah [mailto:[email-masked]]
>Sent: Wednesday, May 07, 2003 6:01 AM
>To: Norman Finn; Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell;
>Paul Congdon; Neil Jarvis
>Cc: [email-masked]; [email-masked]
>Subject: RE: Comments on the L2 VPN framework and solutions documents
>
>
>Norm,
>
>You have to excuse me for jumping in at the
>tail end and not following the thread.
>
>I would like a clarification.
>
>Are you implying that 802.1ad is contemplating on
>running one or more (Provider's) instances of R/M/STP
>on fully-meshed pseudowires?
>
>/himanshu
>Wavesmith Networks
>
>Sent: Tuesday, May 06, 2003 8:14 PM
>To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon;
>Neil Jarvis
>Cc: [email-masked]; [email-masked]
> > > I don't think we're referring to the same model.  The correct model
> > > for how a bridge interacts with full-meshes, one full-mesh per VPLS
> > > instance, is:
> >
> > The discussion is in the context of WG last call of the L2 FW doc and
> > how to progress related solution drafts. So, I'm referring Eric's model
> > describe in the FW doc. The following model completely differ from Eric's,
> > so the following is disagreement to the FW doc, isn't it?
>
>My abrupt answer:  The FW doc is misleading, because it disagrees
>with the way bridges are both defined and built.
>
>Another way to put it:  My diagram is the only way that a standard
>bridge CAN interface to the full meshes within the layering model
>shared by IEEE 802 and IETF.  I should be more careful in my claims:
>It's the only way that has been presented, to date, to IEEE 802.1,
>and has received a lot of support.
>
>The problem with the model in the L2 FW doc (rev 3) is that it
>clings to the idea, discarded by IEEE 802 in 1996, that separate
>VLANs are handled by separate, independent, virtual bridges.  IEEE
>802.1Q chose a model in which one bridge handles all of the VLANs
>using individual physical ports, through which each of the VLANs
>pass.
>
>There is little point in arguing over which model is better.  I
>favored the IETF model when 802.1Q was making its decision, but I lost.
>The models, diagrams, and protocols employed by 802.1Q, and hence the
>actual bridges built today, conform to the IEEE model.  There is
>every reason to argue over which model is more relevant; the one to
>which bridges are actually built should be of considerably more
>interest than it seems to be on this mailing list.
>
>The diagram, below, brings the IEEE model, in which all VLANs pass
>through a single port, in line with VPLS full meshes, which exist one
>per (Provider VLAN | Customer Service Instance | Forwarding Function).
>
>Rather than rail against the L2 FW doc rev 3, let me suggest this:
>Provider Bridges exist, are making money for their (several) builders,
>and hopefully, are making money for their purchasers.  IEEE 802.1AD
>will standardize them.  IEEE 802.1AD will be based on the 802.1Q model.
>Deployed pseudowire full meshes will, of market-driven necessity, be
>compatible with this 802.1AD provider bridge model.  The only questions
>are whether or not the 802.1AD-compatible implementations will conform
>to the IETF documentation, and if not, whether their will exist naive
>implementations of the incorrect IETF documents that confuse the market.
>(Incorrect by definition, if they disagree with bridge implementations.)
>
> > >             |===========================================--------+
> > >             |                   |          | forwarding |       |
> > >             |                   |          |  function  +---    |
> > >    E  i   --+                   | untagged +  VPLS 100  |       |
> > >    t  n     |      Provider     |          | for BPDUs  +---    |  P  r
> > >    h  t     |       Bridge      |          |------------|       |  s  o
> > >    e  e     |                   |          |            +---    |  e  u
> > >    r  r   --+                   |          | forwarding |       |  u  t
> > >    n  f     |     Each "+" in   |  VLAN 26 +  function  +---    |  d  i
> > >    e  a     |    the border of  |          |  VPLS 200  |       |  o  n
> > >    t  c     |     this block    |   mux-   |            +---    |  w  g
> > >       e   --+   represents one  +  demux   |------------|       |  i
> > >       s     |     bridge port   | function |            +---    |  r  f
> > >             |                   |          |            |       |  e  u
> > >             |                   |          |            +---    |  s  n
> > >           --+                   |          | forwarding |       |     c
> > >             |                   | VLAN 589 +  function  +---    |  i  t
> > >             |                   |          |  VPLS 300  |       |  n  i
> > >             |                   |          |            +---    |     o
> > >           --+                   |          |            |       |     n
> > >             |===========================================--------+
> > >                                 A          B            C
> > >
> > > The single interface above the "A" label at the bottom is the Provider
> > > Bridge's bridge port that opens to the L3 world.  The three interfaces
> > > above the "B" label are the interfaces between the forwarding functions
> > > and the mux-demux unit that translates between the Provider Bridge's
> > > P-VLAN space and the VPLS VCID space.  The "C" ports are the mouths of
> > > the pseudowires.  The physical ports on the routed side are of no
> > > interest to the bridge.  :)
> > >
> > > In my last note, I was pointing out that the each forwarding function
> > > MUST control its "B" interface so that it provides 1) full service, or
> > > 2) no service.  (Let's be honest -- my last note was a little confused
> > > between the "A" interface and the "B" interfaces.)
> > >
> > > Since VPLS meshes have one characteristic that physical LANs don't --
> > > one VLAN can be disconnected, while another is working -- IEEE 802.1
> > > needs to examine this situation, and figure out how to deal with it.
> > >
> > > Finally, let me note that only one VPLS -- the one used for BPDUs --
> > > is absolutely required to prevent a meltdown of the Provider's network.
> > > A failure of one of the other VPLSs affects only that customer's traffic.
> >
> > (1) It seems to me, in the above model, PEs are interconnected with per
> > customer meshes, where the PEs attached to the customer are interconnected
> > with a full mesh. Therefore, in the worst case, there 2000 full meshes
> > between PEs, if number of customers are 2000. Originally, full mesh has the
> > O(N^2) problem, so the proposed scheme has O(#ofCustomers * N^2) problem.
> > Furthermore, if fast protection is supported to avoid the protection
> > racing problem and partial mesh, there are double meshes between the PEs.
> > So, I don't feel any reality from the above model.
>
>For N PEs, the number of LSPs is exactly N, because each LSP is a
>multipiont-to-point tree terminating at the destination PE.  The number
>of "branches" on all LSP trees is far less than O(N^2), because there is
>(probably) no single VPLS that spans all of the PEs.  The VPLS that
>touches the largest number of PEs determines the largest n^2 full mesh
>of LSP "branches".  In a typical network with a very large number of
>PEs, the actual number of LSP "branches" will be far less than N^2.
>
>Within that partial mesh of LSPs, for each VPLS, there is a full mesh
>of pseudowires.  The cost of setting up a pseudowire is trivial,
>compared to the cost of an LSP, because it does not involve the
>intervening routers.  The number of pseudowires required is O(m^2),
>where m is not the total number of PEs, but some smaller number,
>related to the typical number of PEs attached to each VPLS.
>
> > (2) Frankly, I don't well understand the above model, because it
> > illustrates some implementation, but is not a protocol architecture.
>
>I disagree completely that it is not a protocol architecture.  I would
>not implement the above diagram in one of my switches, because it would
>be horribly inefficient, there.  This is precisely a protocol
>architecture, because it illustrates exactly where the existing
>standardized interfaces and standardized functions go, and exactly
>where new protocol and/or functional elements are required.  Specifically,
>the "mux/demux function", which is trivial, and the "Forwarding Function",
>which L2VPN is defining.
>
> > In the Bridge architecture defined in a series of the IEEE standards,
> > a Bridge consists of MAC entities, a MAC relay entity, and a Higher
> > layer entity. Could you clarify where these entities are located in
> > the above figure? Where are MSAPs defined in ISO/IEC 15802-1 is located?
> > If the provider Bridge is a VLAN aware Bridge, where are the E-ISSs 
> located?
> > What is VLAN mux-demux function? According to the standards, the VLAN ID
> > value is effective only inside the MAC relay entity, so it does not
> > identify MSAP. I'm not sure whether this conforms with the standards or 
> not,
> > but I think to realize this architecture big changes are needed to the
> > current standards.
>
>All of the standard IEEE bridge functions are contained in the "Provider
>Bridge" block.  I did not break it out into its components, because there
>is no need to do so; their existing functions are unchanged.  The VLAN
>mux-demux function merely translates between the Provider's VLAN tags and
>the Forwarding Function world.
>
>The IEEE P802.1 Working Group writes the bridging standards.  All of the
>members of IEEE 802.1, with whom I have discussed this diagram, and that is
>most of them, believe the above diagram to be conformant to the IEEE 802
>standards.  It's a shame I cannot explain it better, and I invite
>those members of 802.1 who read this mailing list to respond, and either
>argue with me, or hopefully, explain it better.  :)
>
>-- Norm

---

From: Mourad BERKANE <[email-masked]>
Date: Fri, 9 May 2003 11:03:07 +0200

Ali,

Enabling P-STP on a intra-island afraid me a little bit :-)
(a LER is not a ethernet switch, a LSR should never directly interact in a
STP process)

A short example here:
What will happen during a LSP failure in the backbone?

Will P-STP instance on the affected PE will wait for the reconstruction of
this LSP (rsvp fast-reroute for example) 

or

Will this PE deducted that the Ethernet switches loop is broken and will
change the status of his acces port (or on the remote PEs) from Blocking to
Forwarding?

The difficulty here will be to synchronise all P-STP process in the backbone
with MPLS signaling if you don't want that a STP message become quicly
useless.

Have you an idea of the P-STP convergence (what you want to do and what you
can)?

I would like to be optimist on this topic but i can't, look like a hard
issue here.

Mourad

-----Message d'origine-----
De : Ali Sajassi [mailto:[email-masked]]
Envoyé : vendredi 9 mai 2003 01:03
À : Himanshu Shah; [email-masked]; Norman Finn; Muneyoshi Suzuki;
Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis
Cc : [email-masked]; [email-masked]
Objet : RE: Comments on the L2 VPN framework and solutions documents

-Ali

> > >    e  e     |                   |          |            +---    |  e
u
> > >             |                   |          |            |       |  e
u
> > >             |                   |          |            +---    |  s
n
> > >           --+                   |          | forwarding |       |
c
> > >             |                   |          |  VPLS 300  |       |  n
i
> > >             |                   |          |            +---    |
o
> > >           --+                   |          |            |       |
n

---

From: "Himanshu Shah" <[email-masked]>
Date: Fri, 9 May 2003 08:29:14 -0400

May be an example will clear up some confusion... :-)

Lets suppose there is PE-x which is connected to island A
and island B. There is PE-y that is connected to island A
and island C. and there is PE-z that is connected to
island B and island C.

Based on what I understand from Mick's explanation is that
there is 

1. (using your terminology) network-facing (i.e. PW
   based) emulated Vlan ports (one for each island) and 
   1 emulated LAN port (for P-STP, 1 instance MSTP) 
   in each PE. 
2. There is P-STP BPDUs generation/propagation on emulated
   LAN port to determine its forwarding state.
3. The state of the emulated LAN port also determines the
   state of each emulated VLAN port in a PE.

Please let me know if above understanding is correct.

Now further suppose,

1. there is 10GB backdoor connection between island A
  (behind PE-x and PE-y).
2. Emulated LAN port in PE-x blocks thus causing emulated
   VLAN port blocking for island A and island B.

How does the traffic from island B behind PE-z reaches to
island B behind PE-x?
   
Now let me guess to what you and/or Mick are saying,

1. 802.1ad does not participate in P-STP. It simply
   takes a received P-BPDU from island facing port
   and forwards it out to respective emulated 
   VLAN port (something like what you are suggesting 
   in your response but not the impression I got from 
   Mick's explanation)
or

1a. 802.1ad does not participate in P-STP. It drops
   any P-BPDU received from its island facing port.

or

2. 802.1ad does participate in P-STP but only on
   island/access facing ports. P-BPDU received from
   island facing ports is processed for that port
   state and forwarded to respective emulated VLAN port.
   
or 

3. 802.1ad participates in P-STP on emulated LAN port
   to determine the states of all emulated VLAN ports
   (my impression from Mick's explanation)

or 

4. Each PW is treated as separate emulated port (I
   don't think anybody is saying this, including me. 
   This is what old bridges used to do for WAN  
   ports but does not make sense for VPLS model at all)

I think option 1 or 1a makes sense but
has implications of how STP is built and where the 
root gets selected (possibility of having traffic
passing through cloud twice).

/himanshu

-----Original Message-----
From: Ali Sajassi [mailto:[email-masked]]
Sent: Thursday, May 08, 2003 7:03 PM
To: Himanshu Shah; [email-masked]; Norman Finn; Muneyoshi Suzuki;

-Ali

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 12 May 2003 14:09:27 -0700

>(a LER is not a ethernet switch, a LSR should never directly interact in a 

PE has a bridge module and if it interfaces with an Ethernet access network 
(e.g., 802.1ad network), then the PE needs to be IEEE 802.1ad compliant.

>change the status of his acces port (or on the remote PEs) from Blocking 
>to Forwarding?

We have had a detailed discuss on this same topic before. Please review the 
archive.

>The difficulty here will be to synchronise all P-STP process in the 
>backbone with MPLS signaling if you don't want that a STP message become 
>quicly useless.

Again we had this discussion before. P-STP is not used in the backbone for 
inter-island and for intra-island, the P-STP failure detection time needs 
to be longer than PW failure recovery time.

-Ali

>Have you an idea of the P-STP convergence (what you want to do and what 
>you can)?
>
>De : Ali Sajassi [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Mick Seaman 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Himanshu Shah 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Mick Seaman 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Himanshu Shah 
> [<mailto:[email-masked]>mailto:[email-masked]]
> >From: Norman Finn [<mailto:[email-masked]>mailto:[email-masked]]
> > > >    e  e     |                   |          |            +---    | 
> e  u
> > > >             |                   |          |            |       | 
> e  u
> s  n
> > > >           --+                   |          | forwarding 
> |       |     c
> > > >             |                   |          |  VPLS 
> 300  |       |  n  i

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 12 May 2003 14:52:03 -0700

>Please let me know if above understanding is correct.

PE-x, y, and z should be considered as part of their corresponding islands. 
Also if there is a single PE in each island, then there is no need to run 
STP over the big emulated LAN ports between the PEs because if that big 
emulated LAN ports fails, then there is no other PE to connect the island 
into the backbone. However, STP is run within an island to take care of 
loop within among different Etherent nodes in that island. Now if you have 
more than one PE in an island, then you run STP between the emulated LAN 
port of different PE within that island so if one fails, you can connect to 
the core through another PE.

-Ali