RE: Comments on the L2 VPN framework and solutions documents

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
>
>-----Original Message-----
>From: Mick Seaman [mailto:[email protected]]
>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 protected]; [email protected]
>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
>
>-----Original Message-----
>From: Himanshu Shah [mailto:[email protected]]
>Sent: Wednesday, May 07, 2003 10:29 AM
>To: [email protected]; Norman Finn; Muneyoshi Suzuki; Tony Jeffree;
>Les Bell; Paul Congdon; Neil Jarvis
>Cc: [email protected]; [email protected]
>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
>
>
>-----Original Message-----
>From: Mick Seaman [mailto:[email protected]]
>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 protected]; [email protected]
>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
>
>-----Original Message-----
>From: Himanshu Shah [mailto:[email protected]]
>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 protected]; [email protected]
>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
>
>-----Original Message-----
>From: Norman Finn [mailto:[email protected]]
>Sent: Tuesday, May 06, 2003 8:14 PM
>To: Muneyoshi Suzuki; Mick Seaman; Tony Jeffree; Les Bell; Paul Congdon;
>Neil Jarvis
>Cc: [email protected]; [email protected]
>Subject: Re: Comments on the L2 VPN framework and solutions documents
>
>
>Muneyoshi,
>
>Muneyoshi Suzuki wrote:
> >
> > > 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