Subject: RE: On VPLS and Routing Protocols

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 25 Jul 2003 23:04:24 +0200

Eric and all,
Thank you for the clarification,
Please see a couple of comments inline.

----------------------------------------------------------------------------
--------
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: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, July 25, 2003 8:07 PM
> To: Alex Zinin; Sasha Vainshtein
> Cc: Vach Kompella; [email-masked]
> Subject: Re: On VPLS and Routing Protocols 
> 
... snipped ...

> Having  said all  that,  this  probably isn't  really  a 
> workable  solution,
> because it  may not  always be apparent  to a  router that a  
> particular LAN
> interface leads to a VPLS rather than a native LAN.  
>
Exactly.  
On the other hand, there are other cases where such a distinction
seems necessary, e.g., see the discussion of operation of OSPF over
an IP PW in draft-shah-arp-mediation-02.txt.
>
> Sasha> The current VPLS  approach seems to strongly 
> Sasha> discourage  using of SPT between  virtual LAN  switches
> Sasha> interconnected  over the  Ethernet PWs
> Sasha> (there  is  a parallel  email  thread running  on  
> Sasha> this  list at  the moment).  IMO  you have made a  
> Sasha> very good case for  or revising this
> Sasha> position. 
> 
> I don't think  so.  Using SPT between the virtual LAN  
> switches has a number
> of problems as well: 
> 
> - Every PE has  to be able to serve as a transit  point for 
> traffic from any second PE  to any  third PE.  
> (This  in itself  probably makes the  idea a non-starter.)
> 
> - Highly suboptimal routing in the backbone. 
> 
> - The  usual spanning tree issues, e.g.,  all traffic is 
> carried  on a small set of links  while other links remain 
> idle, need  to manage spanning tree within backbone, no 
> inter-provider support, etc. 
> 
> Not to mention that one of the  reasons for this whole effort 
> is to keep the spanning tree out of the backbone. 
>
This is an interesting point. I have probably missed it altogether
when I have been reading the VPLS requirements documents.
> 
> A better approach would be to see if  there is a way to 
> detect that the full mesh has failed  (say, by having each  
> PE tell all the others "here are the other PEs I  can talk to in 
> the specified VPLS  instance"), and to determine
> what action to take when the full mesh does fail. 
> 
This really looks like a much better approach. I do not remember
that it has been actively discussed in the existing VPLS proposals.
Did I miss something?

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Jul 2003 11:40:13 -0400

Well that may be desirable but wouldn't it be more
than what today's interconnected LANs offer?
For instance, if a Ethernet switch port goes down,
the switch doesn't notify all other switches that
its port has gone down. 

Something to think about....

/himanshu

> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Thursday, July 31, 2003 11:18 AM
> To: Alex Zinin
> Cc: [email-masked]
> On Wed, 30 Jul 2003, Alex Zinin wrote:
> 
> > Monday, July 28, 2003, 4:05:22 PM, Alex Zinin wrote:
> > [...]
> > >  3. When node A looses the PW to node Z, make sure nodes B..Y
> > >     simulate loss of connectivity to A and Z too, so all CEs
> > >     have a consistent view and VPN routing converges properly.
> > >     I.e. PW failure triggers simulation of 2 node failures.
> >
> > IF we decide to go this route, the simplest way to do this is for A
> > and Z to logically put all other PWs they have logically down (stop
> > sending outgoing and drop incoming traffic on them) when 
> they see a PW
> > failure. This way, the two-way connectivity of all other CEs with
> > those attached to A and Z will be broken and VPN routing will
> > reconverge properly. No extra message exchange, no additional
> > signaling--everything is a node-local decision.
> 
> This might be simpler, but it is a hack.  It is cleaner for A and/or Z
> to withdraw their labels so that B..Y all know that their connections
> to A and/or Z are down.  The "extra message exchange" ensures
> a) all nodes are in sync about what's going on;
> b) B..Y can, on learning of the loss of connectivity, signal 
> this change
>    to their CEs, (in the fullness of time, when Ethernet OAM/UNI is
>    defined);
> c) traffic doesn't transit the PSN only to get dropped at A or Z.
> 
> Just as a reminder, this was what Norm Finn suggested (Norm, correct
> me if I misrepresented you.)
> 
> Kireeti.
> 
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 31 Jul 2003 13:44:16 -0400

you are right that these cases have similar effect.
but I don't know if we should entertain a separate mechanism
to handle that case.

For instance,
in case a) if there is misconfiguration or problem in 
auto-discovery where one or more PE has different
VPLS member record set, we have a problem. And only
the mechanism you described about synchronizing
membership info would work (but perhaps not something 
easy to accomplish).

in case of b) unsuccessful establishment of PW can be
treated same as PW present and gone bad.

/himanshu

> Sent: Thursday, July 31, 2003 12:53 PM
> To: Shah, Himanshu
> Cc: Alex Zinin; [email-masked]
> Eric> But  this doesn't  handle the  case where  A and  Z, 
> for  some reason,
> Eric> either (a)  never find out about  each other, or (b)  
> never succeed in
> Eric> setting up PWs to each other in the first place. 
> 
> Himanshu> I don't know if we need  to cover those cases.  
> There is a problem
> Himanshu> only when CEs behind  a PE can talk to one sets  of 
> CEs and not to
> Himanshu> others for a given VPLS instance.
> 
> It seems to me that that will happen in these cases. 
> 
> Eric> Also, if node Z  happens to go down, doesn't this make  
> all the PWs go
> Eric> down? 
> 
> I'll keep  saying this  until someone explains  to me  why it 
> isn't  a fatal
> flaw. 
> 
> 
> 
>