Subject: [Fwd: RE: PWE3 question]

From: Maarten Vissers <[email-masked]>
Date: Fri, 31 May 2002 15:12:13 +0200

Zheng,

-------- Original Message --------
Subject: RE: [PWE3] PWE3 question
   Date: Thu, 30 May 2002 12:10:30 -0700
   From: "Zheng Wang" <[email-masked]>
     To: <[email-masked]>, <[email-masked]>,
         <[email-masked]>
     CC: <[email-masked]>

     Zheng...I'd be happy to agree with you provided it broke nothing
     else.  But I have explained on the list several times that it is no
     good saying something is scalable in 1-dimension if it is broken in
     others.  mp2p LSPs create very hard fault management problems and they
     are not good constructs on which to offer VPN services IMO.  VPN
     services need more than isolation wrt addressing, they also need
     strong fault/performance isolation from each other.  Like-DS-class
     merging across VPNs on mp2p E-LSPs does not provide this per VPN
     fault/performance isolation.

Neil
I dont disagree with you. To quote a paragraph from my previous message:
> Of course, when you merge, you lose control over individual paths. It is a
tardeoff.

You indeed lose control over individual paths from a switching granualarity
perspective. But you should never loose control over individual paths from a
fault management perspective.

Merging in a connection monitored network reduces the number of [input,output]
tuples in a fabric, it must never break the AIS/FDI chain. I.e. if an ingress
tunnel at a merge node fails, MPLS-FDI OAM packets must be inserted for each of
the path signals in that tunnel. Only then we can prevent an alarm storm to
occur in a MPLS connection monitored network.

A tunnel is a higher order path trail and terminates at the ingress of a merging
node. The tunnels payload is forwarded and merged/muxed with other tunnel's
payloads into a new higher order path trail. This latter higher order path trail
terminates again at the ingress of the next merging node, etc.

Regards,

Maarten

Cheers
Zheng