Subject: Re: On VPLS and Routing Protocols

From: Alex Zinin <[email-masked]>
Date: Wed, 6 Aug 2003 16:34:25 -0700

Sorry for the delay.

Eric:
> But this doesn't handle the case where  A and Z, for some reason, either (a)
> never find out about  each other, or (b) never succeed in  setting up PWs to
> each other in the first place.  Also,  if node Z happens to go down, doesn't
> this make all the PWs go down?  

> I really don't think this can be done based on local knowledge. 

You're right. Looks like without the PW status from others we can't
tell the cases where a PW corresponds to a node failure that we don't
need to worry about (because 2-way connectivity is disrupted for all
other nodes and VPN routing reconverges correctly) and a real PW
failure where we might need to either do a repair or ensure consistent
2-way connectivity by bringing some other PWs logically down.

Kireeti:

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

Per above, agreed that node-local decision wouldn't work. However, if
we go the route of degrading connectivity to the level of a node
failure in a PW failure scenario, then withdrawing the labels may not
be the way, as we may end up with catch-22, where I am trying to
decide if I should bring a PW up based on the state of other PWs, and
other PWs are not brought up, because other nodes are waiting on me. I
think we need logical status for a PW that the nodes would control
locally in addition to the actual PW status that they would exchange
with each other.

Cheng-Yin:

> Mick Seaman proposed a solution on IEEE 802.1
> (or PPVPN?) mailing list prior to this. My understanding of the proposal
> is - the VPLS entity shall disable the MAC port presented to the 802.1ad
> bridge if a PW fails. I think Himanshu has described a similar approach
> ("blocking" VPLS port) in this thread.

Doesn't this suffer from the same problem Eric pointed out--the whole
VPLS falling apart when a single node goes down and brings PWs with
all other PEs down too?

Alex

---

From: cylee <[email-masked]>
Date: Thu, 07 Aug 2003 22:56:10 -0400

Alex,

 >VPLS falling apart when a single node goes down and brings PWs with
Yes, I think all the proposals (whether the "LAN failure" emulation is
transparent to higher layer protocols, e.g. in the above proposals and
Vach's proposal, and in proposals which require routing protocols to
handle the PW "failure") need to solve a common problem i.e.

"... PEs may need to agree on which are the
currently participating PEs and ensure all other participating PEs have
connectivity to each other, i.e.  a protocol among PEs may be needed 
..." for each VPLS instance, essentially.

This is what I have referred to as a "LAN failure emulation protocol" in
past discussions.

 >failure
 >other PWs are not brought up, because other nodes are waiting on me.
 >
Withdrawing labels is an implicit indication, and hence issues like the 
one you brought up. In my response to Himanshu, "I still think A & Z 
need to tell (may need to be explicit to prevent ambiguity) other PEs 
that it is not participating in the VPLS anymore.".
Without an explicit PW status of a VPLS instance, I think there will 
also be similar issues initially when PWs are setup, and subsequent PW 
re-establishment after PW failure.

I think a "LAN failure emulation protocol" can be specified but it is 
difficult to get it to work. Some concerns I have with a LAN failure 
emulation protocol are timing (fast enough to be transparent to higher 
layer protocols but not so fast as to cause unnecessary failure 
emulation) and race conditions (real or perceived multiple PW failure).

Thanks,
Cheng-Yin