Subject: RE: On VPLS and Routing Protocols

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 23 Jul 2003 10:48:18 +0200

Alex,
It has been always my impression that a VPLS is a set of (virtual) LAN
switches interconnected by Ethernet (pseudo)-wires, and hence its behavior
wrt the routing protocols it should behave just like a set of
native LAN switches interconnected by (native) Ethernet wires.
In particular, it is capable of delivering LAN broadcasts, hence
I do not understand your reference to the "NBMA clouds. "

If you treat a VPLS as a LAN, the L2 network view would be 
slightly different  from your diagram:

                       10.2/16
                          |
                     ...[R2]...
                          |
                        [Sw2]
                    .   /   \  
                       /     \ 
                      /       \
     10.1/16--[R1]-[Sw1]+---+[Sw3]-[R3]--10.3./16
             .          .
              ..........
where Sw1/2/3 are native or virtual LAN switches interconnected by
native or pseudo-wires.

IMO the problem you've raised does not exist in the native LAN case 
because failure of a native wire between Sw1 and Sw3 would be 
detected by the SPT running between the native bridges and, 
as the result, Sw1 would start forwarding frames addressed 
to R3 via Sw2. This process would not be noticed by R1, R2 or R3
since they would still treat themselves as interconnected over a
LAN.

The current VPLS approach seems to strongly discourage using of SPT
between vrtual LAN switches interconnected over the Ethernet PWs 
(there is a parallel email thread running on this list at the moment). 
IMO you have made a very good case for for revising this position.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Tuesday, July 22, 2003 8:56 PM
> To: [email-masked]
> Subject: On VPLS and Routing Protocols
> 
> 
> [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/
> 
>

---

From: Alex Zinin <[email-masked]>
Date: Thu, 24 Jul 2003 18:27:20 -0700

Sasha,

> native LAN switches interconnected by (native) Ethernet wires.

It is certainly possible to treat a VPLS as a normal LAN in a steady
state. The considerations I brought are applicable to the situations
where any-to-any connectivity assumption is not true anymore because
of PW failures.

> I do not understand your reference to the "NBMA clouds. "

The analogy is along the lines of the connectivity model, topology
abstraction and route calculation. The difference in broadcast
capabilities of the L2 technology itself is not extremely important
here, as lack of it in the NBMA case is worked around either at
the interface driver level or through manual configuration of the
neighbors and sending unicast hellos at the RP level.

[skip]

> IMO the problem you've raised does not exist in the native LAN case

sure

> IMO you have made a very good case for for revising this position.

the intent was not to revise that part, but given the realities of
VPLS discuss the routing aspects.

Alex