Subject: RE: On VPLS and Routing Protocols

From: Ali Sajassi <[email-masked]>
Date: Mon, 04 Aug 2003 13:12:43 -0700

I am catching up with my emails on this thread and after going over them, I 
have the following input/comment.

The discussion so far has been focused on the fault recovery and either a) 
how to fix a partial-mesh in case of a node/link or PW failure or b) how to 
make the end-points accommodate such failures (via NBMA). However, another 
important piece in here is the fault detection mechanism and this detection 
& recovery need to happen within the time constraint set forth by IEEE 
802.1 for proper operation of emulated LAN segment with the existing IEEE 
bridges.

Given that the failure can be either hard or soft/silent failure, the 
detection mechanism needs to cover both cases. Also given that a VPLS 
service instance can span across different network types (e.g., QinQ access 
network with MPLS/IP core network), the fault detection mechanism needs to 
operate over different network types.

Within the MPLS/IP core network, where a full-mesh with split horizon is 
run, then one of the following factors can result in a partial mesh 
connectivity:
- link failure
- node failure
- PW failure due to soft/silent failure

The failure that can affect a large number of customers / VPLS instances 
need to be quickly detected and appropriate action to be taken; whereas, 
the failure that only affects a single VPLS instance may not have the same 
urgency. Therefore, one can use TE tunnels between the PEs to ensure that 
all the PWs between a pair of PEs take the same path and have a rapid 
failure detection mechanism that operate at the tunnel level and upon 
detection of a failure an alternate tunnel using FRR can be exercised.

Using TE PtP tunnels in the MPLS/IP core, can help with rapid fault 
detection and recovery mechanism in the core network to take care of 
failure such as link and node failures (both PE and P).

Another advantage of using TE tunnel is that it will take care of ECMP 
problem for provider's BPDUs packets that need to travel the same path as 
the VLANs that they protect for an intra-island (and not inter-islannd) 
scenario.

The use of TE tunnels can bring about the scalability concern; however, the 
use of hierarchical topology (e.g., HVPLS) would/should alleviate such 
concern since the TE tunnels are among n-PEs (and not u-PEs).

Also for the failures that only affect the PW(s) of a given VPLS instance, 
then the Ethernet OAM mechanisms that are being discussed in IEEE and ITU, 
can help with fault detection, verification, notification, and isolation at 
the service instance level.

-Ali

---

From: [email-masked]
Date: Mon, 4 Aug 2003 22:15:56 +0100

Ali,

Really nice to meet you (and Stewart B) at SG13 last week and good comments
here.  However, I have few concerns:

Tunnels.  I really think its time we stopped playing footloose with these
architectural terms and introducered some hard G.805/809 funnctional
modelling descriptions.  MPLS uses LSPs which are a *server* layer below
whatever client we are considering.  IP tunnels, say L2TPv3 or GRE on the
other hand, are *client* layers to IP, ie IP is the server layer here.  So,
in a layered architecture sense IP tunnels are in fact just the opposite (ie
'bridges' in a litteral sense) whereas MPLS LSPs are truly *below* (ie
server) to whatever client they serve.  The key point here, if not
blindingly obvious by now, is that we *cannot* equate XoverIP and
XoverMPLS.....they are simply *not* the same.  And hence my basic problem as
I explained to you/Stewart at SG13 with the PWE3 stuff....IP is a cnls mode
and MPLS is a co-ps mode.  This should be embraced with rejoicing (ie it is
*useful*) and not deprecated as some 'mistakenly' see this.

Did you see my earlier posting, to Eric R, on the need for MPLS LSPs to have
their own access points addressing?  This is part of the same issue as I
tried to explain to you/Stewart at SG13.

We can be so much smarter/useful in what we are doing here.....however, is
there the political/commercial will (in IETF) to eventually state IP and
MPLS are different networking modes and cannot be subject to the same
misguided PWE3 treatment to date?  I hope so, but I am also realistic to
recognise this may not happen anytime soon.

regards, Neil

> -----Original Message-----
> From: Ali Sajassi [mailto:[email-masked]]
> Sent: 04 August 2003 21:13
> To: Shah, Himanshu; [email-masked]'
> Cc: Alex Zinin; [email-masked]
> Subject: RE: On VPLS and Routing Protocols 
> 
> 
>

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 04 Aug 2003 15:42:04 -0700

>here.  However, I have few concerns:

It was also very nice meeting you during SG13 meetings and I enjoyed our 
conversation and discussions.

>*useful*) and not deprecated as some 'mistakenly' see this.

When I talked about tunnel and PW, I was referring to PSN tunnel (inside 
which one or more PW is carried) as described in the PWE3 arch document. 
Although sometimes, some people use the term tunnel and PW interchangeably 
in the context of L2TP which can be the source of confusion. Also, I think 
we all agree that an MPLS TE tunnel is a co-ps mode but again not all MPLS 
applications are TE tunnels :-)

I hope, the terms PSN tunnels and PWs as defined in PW arch. document are 
clear enough to everyone and whenever I use these terms, I use them in 
context of PWE3.

>tried to explain to you/Stewart at SG13.

No, but I will go over it when I get a chance.

>recognise this may not happen anytime soon.

I guess if we recognize that MPLS has two modes of operation (one as 
clns-ps and the other one as co-ps), then we can appreciate the commonality 
and differences between IP and MPLS.

Regards,
Ali

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 8 Aug 2003 16:56:31 -0400

Correction in my earlier response.....

>In my example PE A would block emulated LAN port to
> VPLS instance x. PE Z or for that matter any PE in VPLS
> instance x would know that PE A has blocked emulated LAN
> port.

This should have read.....

>In my example PE A would block emulated LAN port to
> VPLS instance x. PE Z or for that matter any PE in VPLS
> instance x would NOT know that PE A has blocked emulated LAN port
                                  ^^^^^
/himanshu

> From: Shah, Himanshu 
> Sent: Friday, August 08, 2003 2:36 PM
> To: [email-masked]'
> Cc: 'Alex Zinin'; [email-masked]
> Not true.
> Using  your example, if PW data plane fails, PE Z would block
> emulated LAN port for VPLS instance x only.. No other PEs
> participating in VPLS instance x would know that PE Z has
> blocked his emulated LAN port for VPLS instance x.  And
> neither would PE Z block emulated LAN port for VPLS
> instance other than x.  
> 
> Isn't this somewhat similar to what bridges do today?
> Blocking of a Bridge port is not notified to anybody. It is local
> decision based on information received from the BPDU.
> 
> /himanshu
> 
> 
> > From: Eric Rosen [mailto:[email-masked]]
> > Sent: Friday, August 08, 2003 1:13 PM
> > To: Shah, Himanshu
> > Cc: 'Alex Zinin'; [email-masked]
> > Subject: Re: On VPLS and Routing Protocols 
> > 
> > 
> > 
> > Himanshu> If a PW from PE A to PE Z fails for VPLS instance x,
> > Himanshu> PE A simply blocks bridge port to VPLS instance x. 
> > 
> > So if the pseudowire data plane fails  entirely at PE Z, this 
> > means that all
> > other PEs block  their Emulated LAN ports for VPLS  instance 
> > x.  I.e., every
> > VPLS instance supported by PE Z is 100% down. 
> > 
> > 
> > 
>

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: Fri, 8 Aug 2003 16:59:17 -0400

Himanshu,

I believe the case Alex is referring to is when a PE node fails. 

For e.g. if PE Z fails, other PEs with PWs to PE Z will block its VPLS port for VPLS instance x, i.e. the whole VPLS instance x is down, even though PE A and other PEs could still participate in the VPLS instance.

Regards

Cheng-Yin

Himanshu Shah wrote:

What I mean by VPLS port blocking is this. 

If a PW from PE A to PE Z fails for VPLS instance x, 
PE A simply blocks bridge port to VPLS instance x. 
It does not send PW status to Z or to any other PEs. 
No traffic for VPLS instance x would be forwarded 
to/from any PW by PE A. Thus, isolating all the CEs behind 
PE A of VPLS instance x from the rest. 

I don't believe this has domino effect because no PE 
finds out about bridge port blocking on PE A. 

/himanshu 

Alex Zinin wrote: 
---- stuff deleted --- 
> 
> 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: "Shah, Himanshu" <[email-masked]>
Date: Fri, 8 Aug 2003 17:40:06 -0400

Got it. I was referring to the case for PW going down due to transport
tunnel carrying the PW going down. Node failure is definitely different case
and Alex and Eric are right that this scheme would not work.
 
/himanshu

-----Original Message-----
From: Cheng-Yin Lee [mailto:[email-masked]]
Sent: Friday, August 08, 2003 4:59 PM
To: Shah, Himanshu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: On VPLS and Routing Protocols

Himanshu,

Regards

Cheng-Yin

Himanshu Shah wrote:

/himanshu 

Alex Zinin wrote: