[RTG TA hat on]

I'd like to comment on the issue of routing protocol operations under
the condition of a PW failure in a VPLS.

First, let me note that both ISIS and OSPF protocols already know how
to deal with NBMA clouds that exhibit the same behavior as VPLS as far
as connectivity is concerned.

ISIS takes the simplest approach--assumes any-to-any connectivity
(essentially full mesh of VCs) and treats the cloud as broadcast
media--DIS is elected, and the cloud itself is abstracted as a
pseudo-node with all routers attached to it. The broadcast service
itself is provided by the interface driver that replicates the
multicast packets for multiple VCs. The same approach is used in
OSPF's NBMA mode. The catch here is in potentially nasty problems that
show up when connectivity between non-DR/DIS routers changes. Here's
an example:

               10.2/16
                   |
              ...[R2]...
             .   /  \   .
   10.1/16--[R1]+----+[R3]--10.3./16
             .          .
              ..........

Assume that R2 is elected as the DIS on the segment/cloud.

R1 will establish an adjacency with R2, but not with R3, because both
R1 and R3 are non-DIS routers. This means that the RP will be actively
checking connectivity of the R1-R2 and R2-R3 VCs only, and if the
R1-R3 VC goes down, the RP will not notice it. However, connectivity
between R1 and R3 is still assumed by the protocol, and R1, for
example, will install a route to 10.3/16 as follows:

  10.3/16 -> FrameRelay0/0, R3

That is, R1 will try to route directly to R3, not through R2. So if
R1-R3 VC is down, traffic will be black-holed.

In the case of VPLS, the situation is essentially the same-- there is
a risk of traffic black-holing when one PW goes down.

Another risk is inconsistency in the DIS/DR calculations among the
attached routers because of the differences in the sets of visible
neighbors. This one leads to problems with adjacency establishment,
which is a bit better, since they are visible at the RP level and
should be reported to the admin.

There are no additional and already existing mechanisms in ISIS that
could help us address the problem. The operational model is to monitor
the status of each VC/PW and troubleshoot when an alarm is received.
OSPF is a little different.

What we would like to have in the VPLS case is awareness of the PW
topology and ability of the RP to reroute around a failure (R1
rerouting through R2 in the example above.) As only fully established
adjacencies are used to abstract the network topology, we essentially
need any-to-any adjacency establishment (vs DR/BDR to others in the
normal NBMA case). We also need the RP to abstract connectivity over
an emulated LAN as a set of p2p links, rather than a pseudo-node with
all routers connected to it.

What's described above is the point-to-multipoint mode in OSPF. It is
normally used for NBMA clouds, but can be reused for the VPLS case.
There's one subtle detail though--neighbor discovery.

Normally, in the p2mp mode, neighbors are assumed to be configured
manually. However, we don't want to require that VPLS customers have
to configure them, so we need hello-broadcast neighbor discovery
combined with p2mp OSPF network type. I know at least one major vendor
that supports it, but others may not, so it is worth spelling out.

Note that the choice of treating an emulated LAN as a broadcast
network with DR/DIS vs a p2mp one, is not straight-forward. It is
about the balance between protocol scalability and network
availability. With the p2mp network approach, the number of
adjacencies is O(N^2) (vs O(N) in the broadcast network case), which
affects complexity of the protocol operation, most notably flooding
and SPF computation. On the other hand, it gives us better
connectivity in PW failure scenarios.

Hope this sheds some light on this issue.

If there's interest within the WG, these considerations could
be captured in a short document.

Regards

-- 
Alex
http://www.psg.com/~zinin/