|
|
Hi Lionel,
At 09:20 AM 1/12/2005 +0200, Lionel.Silman@xxxxxxxxxxx wrote:
Hi Ali,
This response mentions diagrams on page 7 of your IETF
presentation. The presentation does not appear to have been posted. Where
can it be found?
Here is the pointer to it.
http://www1.ietf.org/proceedings_new/04nov/slides/l2vpn-9.pdf
I found Section 9.2 of
draft-ietf-l2vpn-vpls-ldp-05 to be so telegraphically written that I
could not follow the details (and I think many other readers are in the
same position). Your responses to Peter and Interoperability Draft
fill in some of these details.
I agree with you. The couple of paragraph in the section 9.2 is neither
enough nor does Justices to treat this topic in reasonable details. As
soon as I get a chance, I will incorporate some of the stuff that I
discussed previously into either this draft or a new draft.
The draft states "On a per
P-VLAN basis, the MSTP will designate a single PE-rs to be used for
carrying the traffic across the core". Does your diagram help
explain that statement?
Not quite but Figure-7 may help somewhat. It shows the model for the
PE-rs with bridging component and you can think of one those VPLS
instances shown in the model is for carrying service provider BPDUs among
the PE-rs devices of the same island. Furthermore, this BPDU VPLS is
mapped into BPDU untagged traffic of the virtual bridge port. From there
on, MSTP operates as it should among the provider's PE-rs devices of a
given island (e.g., it is limited to that island only).
As a nit,
draft-ietf-l2vpn-vpls-ldp-05 should refer to S-VLAN instead of P-VLAN in
accordance with the 802.1ad terminology (and
draft-sajassi-l2vpn-vpls-bridge-interop-00).
Agree.
I am hoping that your diagrams
will clarify some points which still are not clear on these important
issues. Expanded drafts are needed.
I agree that we need more detailed description and I will work on
it.
-Ali
----------------------------------------------------------------------------------------------------
Lionel Silman, System, Optical Networks Division, ECI Telecom
Tel Work: +972 (3) 9266007; Home: +972 (3)
6417464
Ali Sajassi <sajassi@xxxxxxxxx>
Sent by: l2vpn-bounces@xxxxxxxx
18/11/2004 08:38
To: "Busschbach, Peter B
(Peter)" <busschbach@xxxxxxxxxx>, "'Ali Sajassi'"
<sajassi@xxxxxxxxx>, l2vpn@xxxxxxxx
cc:
Subject: RE: Questions about
draft-sajassi-l2vpn-vpls-bridge-interop-00
Hi Peter,
Please refer to my comments below ...
[snipped]
>Unfortunately, I don't fully understand section 9.2 of the vpls-ldp
draft.
>Perhaps you could shed your light on that as well :-)
Section 9.2 mentions:
>
>"If an island has more than one PE-rs, then a dedicated
full-mesh of
>pseudowires is used among these PE-rs devices for carrying the SP
BPDU
>packets for that island."
>
>What is meant by "dedicated"? Since the PE-rs devices are
part of the VPLS
>network, there is by definition a full mesh of PWs between them. Are
the
>dedicated PWs for SP BDPU packets different PWs than the ones that
carry
>the data traffic?
Exactly. These full-mesh of PWs are dedicated to carry the service
providers BPDUs only and this full-mesh is for the PE-rs devices of that
island only and not the whole network. So if the whole network consists
of
5 access islands each of which having three PE-rs devices, then each
island
has a full-mesh of three PWs for its BPDU traffic. And if a VPLS instance
(for a given customer) spans across all the five islands, then that VPLS
instance needs a full-mesh of 105 PWs (15*7). The idea of having a
separate
full-mesh of PWs for each island's BPDU traffic is to make each island
STP
independent from every other islands.
>Also, would it not be possible that as a result of running MSTP in
the
>P-VPLAN, the VPLS network itself is blocked? E.g. if an MTU-s is
connected
>to both PE1 and PE2 and the resulting spanning tree is such that the
link
>between PE1 and PE2 is blocked (i.e. the MTU-s is the root), then
MTU-s
>will forward packets with unknown MAC address received from PE1 to
PE2 and
>vice versa. Now, if PE1 and PE2 both block all traffic from the VPLS
>network, the P-VPLAN is isolated from all remote nodes. On the other
hand,
>if PE1 and PE2 both forward traffic over the VPLS network, there is a
loop.
This won't happen. The full-mesh of PWs for that islands BPDUs is for the
virtual bridge port that I draw in the PE model in page 7 of my IETF
presentation (I have sent my preso to the chairs to be posted). So if you
take a look at that figure, hopefully things become more clear. When that
virtual port gets blocked, then all the VPLS instances (or provider
VLANs)
over that port gets blocked as well and therefore, only a single PE-rs
will
be active for any given VPLS instance. Even if there is another link
between the two PE-rs devices, the MSTP will take care of blocking this
additional link.
>Does a single PW failure in a full-mesh of PWs cause a total
interruption
>of BPDUs? I would think that in a bridge world, every site that
>participates in a VPLS instance would generate BPDUs. If PE1 stops
>receiving BDPUs from PE2 due to a PW failure, but if it continues
>receiving BPDUs from PE3, PE4, etc., why would it change the
forwarding state?
There are scenarios with dual-homing of a customer site or redundant
connection via another network, where a unidirectional failure of PW can
result in a loop - it would be easier to show these scenarios via
figures.
Also in the scenario that you describe above, because the CE1 connected
to
PE1 doesn't receive BPDUs directly from the CE2 (connected to PE2), then
it
can miscalculate its path to the root and block its link and open up an
alternative link through another network which is not desirable.
> > Now in case of a
> > uni-directional failure
> > of a PW, if the detection & recovery time for a PW failure
is
> > greater than
> > twice the BPDU hello time,
>
>What is the BPDU hello time?
typically 2 seconds.
> > Let me give you another example: if three customer CEs
are
> > connected via 10
> > provider bridges (e.g., there are ten bridges in the path
of
> > these three
> > CEs), then only a single bridge needs to do MAC address
learning.
>
>
>I still don't understand. If three CEs are connected to three PEs,
don't
>all three PEs need to participate in MAC address learning?
>
>You can avoid any MAC learning in PEs by establishing point-to-point
PWs
>between CEs. However, in a regular VPLS architecture, each PE needs
to do
>MAC learning, right?
Typically yes, all the PEs need to learn MAC addresses but what I am
talking about is that the MAC address learning can be optimized (per
802.1ad) such that only the PEs that need to learn MAC addresses, then
learn MAC addresses. Let me give you another example, if a customer has
only two CEs connected via a VPLS network, then we can optimized our
network such that no MAC address learning is needed because the path
between the two CEs through the network is basically a PtP path. Now if
you
consider three CEs, then there can be only a single Y branch along the
path
between the three CEs and therefore, only the PE with Y branch needs to
learn MAC address. With this optimization, the question is not if a PE
can
learn customer MAC addresses but whether a PE needs to learn customer MAC
addresses.
-Ali
> >
>[snipped to the end]
|
|