The MPLS WG Archive

[Vishal Sharma <Vishal.Sharma@tellabs.com>]

Dave,

Thanks for your comments and observations. Please see our responses below.

-Vishal

On Wednesday, April 12, 2000 1:15 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] 
wrote:
> A few comments:
>
> 1.0 - The discussion of the limits of SONET protection I find a bit
> contentious. I'd suggest the difference between protection at various layers
> is when the degree or style of protection is being used as a product or
> class of service differentiator and one is trying to bundle that
> differentiation into a specific layer. Otherwise everyone gets the same
> treatment that the underlying layer provides.

We are a little unclear on exactly which portion of 1.0 you are objecting to.
We feel that we tried to say things similar to what you say above.

> 2.1 - What is an FIS and FRS?

Failure Information Signal and Failure Recovery Signal (defined in 
draft-makam-mpls-recovery-frmwrk-00.txt).
Same comment as to Bora, we'll include definitions in our draft in the next revision.


> 2.1 - I'd like to see a better definition of "PSLs affected by a fault".

Essentially, it means those PSLs that have LSPs going through the faulty link or node. When
we have merged working paths, a fault on a particular branch of the mp-p tree may affect
only a subset of all PSLs whose traffic is being merged on that tree. We'll make this more
precise in the revision.


> 3.1 - discussion of establishing the path suggests that the only properties
> required is that the path transit the PML and the PSL. Ideally it transits
> nothing in common between those two entities (nodes, fibers, conduits etc.)
> if multiple simultaneous failures are to be minimized.

That is correct. We could add that to the text.

> An equally
> interesting problem is nodal redundancy on the boundaries of protected
> domains to protect against catastrophic nodal failure (like an LSR
> crashing... or being crashed into ;-).

Yes, but not one we are trying to solve or address in this draft. We recognize
in our draft that the PSL and PML can be points of failure.


> 3.3 - I'm missing somthing in the discussion of bandwidth reuse in the
> protection path. Are we discussing linear protection where the only
> opportunity for re-use for LSPs which have common routing between the PSL
> and the PML?

Actually, I think we implicitly assumed this. However, as you point out,
this assumption isn't necessary. We will make this clearer in the revision.

> 3.3 - 1:1 is the only protection mode discussed. n+1 is a possibility. and
> 1+1 may be derided for bandwidth ineffeciency, but it does not require the
> establishment of an RNT, simple forward livliness messages are sufficient
> for a PML to select an appropriate source.

1+1 was not covered in our draft, for several reasons:
(i) In the 1+1 case, what is the criterion a PML uses to select the traffic from
a particular path? Does it make a decision on a packet-by-packet case? How?
How does that work if the paths have quite different delays.
(ii) 1+1 also introduces complications because 1+1 does not easily allow for merging
of working paths (which is the main case we address in our draft).
Also, if one does allow for merging of working paths *and* tries to
do 1+1 protection, the situation gets fairly complicated.
For example, consider the figure in our draft, and assume that the paths 1-2-3-4-6-7
and 8-9-3-4-6-7, are both 1+1 protected. Node 7 now has to select between traffic
coming on link 6-7 or that coming on links 5-7 *and* 10-7. Moreover, a fault on
link 2-3, which affects only the first path, will require 7 to switch to selecting traffic
from the backup paths impinging on it via link 5-7 and via link 6-7.

It appears that the simplest way to implement 1+1 protection is to not allow any traffic
using 1+1 protection to merge with any other traffic.

BTW, even assuming that one does 1+1 protection as described above, the liveness message
alone will not be enough to inform the PML, since it is a hop-by-hop mechanism. If a fault
occurs more than one link away from the PML, you need another message to let the
PML know about that.
What we will need in that case is a FIS that propagates in the upstream direction.

I assume you mean 1:n (1 for n) in the message above. Yes, that can certainly be done.
Again, that pertains to how the path selection algorithm does its job (of course signaling
support to indicate 1:n protection is also needed).

> At some point in the future,
> bandwidth for administrative time/simplicity may be a worthwhile tradeoff.
> This would suggest common livliness mechanisms are required, and this should
> be acknowledged by attempting to encompass the whole problem/solution space.

We could still try to formulate requirements for the 1+1 case, and see if a common
FIS mechanism can be propsed.

> Ultimately I'm skeptical about the ability to construct parallel mp2p trees
> that are usefully diverse and for which the backup is remotely near optimal
> due to the constraint of having common PSLs and PML.

There is no "requirement" to construct mp2p trees. Rather, it is a natural outcome
of the desire or need to merge working traffic. The backup paths may form
a tree or they may not. And of course, some intelligence needs to calculate
them in accordance with appropriate constraints.

> The apparent
> requirement to have both working and protection paths converge on the PML
> seems artificial and unnecessary (if I am understanding this correctly???).

Again, this is not a requirement, but rather an outcome of where the working
and protection paths are desired to be merged (selected by the algorithm that
selects these paths). The PML is whatever LSR these paths (for a given
working path) merge at. Thus, the working and protection paths naturally
converge on the PML, by definition, not by any artificial requirement.

Also, there could be different PMLs for different working paths (even if these
paths merge), and for a particular LSPs, their PMLs could be the egress LSRs
for those LSPs.

> All a PSL needs to know is that a path has failed, and have a viable
> alternative to switch to. For that RNT may be a viable solution, but simply
> each protected mp2p LSP has an RNT associated with it so the PSL can make
> reasonable and timely decisions and there may be no topological entities in
> common between the working path and the protection path (other than the
> egress node from the network).

Correct. See response above.

> Realistically the useful functionality of an
> RNT can be distributed across all intermediate LSRs and the concept of an
> PML should be capped as simply an administrative concept defining a point
> past which an RNT will not propagate (for whatever reason).

Indeed that is what it pretty much is. Except that a PML is the LSR at which
a working and protection path merge, and not an administrative concept
beyond which an RNT will not propagate, since you can have multiple PMLs
on the same RNT. (There needs to be a slight correction in our draft, because
we say the PML sources the RNT. We need to clarify, that the last PML
on a merged working path is the one that sources the RNT.)