RE: Comments on the L2 VPN framework and solutions documents

At 11:03 AM 5/9/2003 +0200, Mourad BERKANE wrote:

>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)

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.


>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?

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)?
>
>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 protected]>mailto:[email protected]]
>Envoyé : vendredi 9 mai 2003 01:03
>À : Himanshu Shah; [email protected]; Norman Finn; Muneyoshi Suzuki;
>Tony Jeffree; Les Bell; Paul Congdon; Neil Jarvis
>Cc : [email protected]; [email protected]
>Objet : 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]>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]>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]>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]>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]>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