The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

At 09:41 AM 3/21/2002 -0500, David Allan wrote:

> George, 
>
> If the network is ER-LSPs because I needed to engineer some
> applications or require high availability, I may also provide recovery
> paths for the service that the PW layer does not know about, and the MPLS
> layer is expected to take some proactive action to restore service on
> failure (e.g. protection switching, re-balancing multilink...whatever)
> and this may frequently be in the form of the LSP ingress needing to do
> somthing while the rest of the network does not. In these recovery
> scenarios, the end point controls it's MPLS destiny. This is a different
> application of the e2e principle and has similar validity. Recovery takes
> place at a layer that can do somthing about it. Availablity measurement
> is not the only function enabled here.

When we say that were concerned about the implications of Y.1711 on IETF
protocols, it's exactly the above
scenario that worries me.  If all it were, was a matter of letting
the endpoints know whether MPLS-OAM were
being used or not then I wouldn't be too concerned.  Where my
concern comes in is in the binding required 
(or at least implied by your FDI/RDI stuff) between various things that
currently run quite idependently.  

Suppose I'm using LDP to set up a PW app.  Initially it's running
over LDP in the core which (for scalablity
reasons) does do MPLS-OAM.  At some later time I set up a TE tunnel
which can support MPLS-OAM and 
routing sends the PW app packets over this.  Is some signalling
needed at this point?

When the tunnel is created do I have to go look at what might be carried
over it and figure out if they want me
to suppress or enable alarms.   If routing changes do I have to
revisit all of this?

What's the impact on things like fast reroute? 

Do you need additions to BGP for RFC2547 VPNs? 

...George