The MPLS WG Archive

["David Allan"<dallan@nortelnetworks.com>]

Title: RE: Clarification on today discussions

George:

Apologies for the relatively long post, you had a lot of questions to answer...I've snipped out my original comments.

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

But things like fast re-route imply similar bindings. 'x' is broken so the box may be pre-configured to then do 'y'. Currently 'x' is notified by signalling or some form of adjacency failure, in the future we'll have added a user plane mechanism for notification. This enables global repair, as we have eliminated the control plane latency bottleneck.

Global protection schemes are in the recovery framework, emerging in GMPLS yadda, yadda, yadda. The signalling extensions for such protection schemes are happening independently of this work because they are required for GMPLS. If the actual concern here is that applications that lever OAM stuff to add to the suite of reliability constructs may result in extra protocol changes, then I don't buy it. If anything, we're just hitting an overall commonality of toolkits.

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

Does or does not?, not quite parsing this....

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

If I understand the question correctly, is the OAM for the LDP layer and the OAM for a TE tunnel that the LDP layer may ride over decoupled? If so the answer is yes. The OAM is specific to the MPLS level.

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

Not fully parsing the comment, are you suggeesting alarm generation is a function of the application?

I simply have an extra tool for determining tunnel failure. To contrast it with LSP PING, the tunnel egress detects the failure, rather than the ingress. The egress can more easily to an authoritative determination. I hate to compare apples, but I am not sure that the overall implications are any different between the solutions beyond the complexity of fault detection.

> What's the impact on things like fast reroute?

I presume the actual discussion here is if I use global repair and/or local repair and I run OAM. IMHO I use 'a' or I use 'b', this is the network operator decision.

If the suggestion is that we are stochastically employing recovery techniques, then I'll offer the following. If it is detours, this is signalled by the ingress, and I can determine if there is a conflict in repair styles. If it is bypass tunnels and this is somthing the ingress has no knowledge of , then presumably the repair takes place faster than the OAM would detect failure (or at leeast that's the claimm) and OAM would then only measure availability or failures that the bypass tunnels could not correct. If i am using 1:1 or 1+1 in a network where I am also using detours/bypass tunnels...well no comment there. If I am stacking repair techniques, there are issues, but then that is true across the board and independent of this particular application.

> Do you need additions to BGP for RFC2547 VPNs?

As the VRF layer and the transport layer are both typically mp2p, not clear to me that there is a simple applicability of the OAM stuff in this scenario. IMHO if I was using OAM, it would be easier and mjore scalable to measure availability of the transport layer (PE-PE connectivity) and let the VRFs inherit that information locally rather than measuring each VRF adjacency uniquely. Besides, I am not going to try to signal recovery over BGP. It is not useful and similar to the comment on the PW end to end argument.

hope this helps
Dave