The MPLS WG Archive

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

Title: RE: draft-chang-mpls-path-protection Comments

Vishal:

Embedded comments...

<snip>





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

One of my concerns is that if backup paths do not form trees, then we have a big scalability hit, we have order (n+1)**2 meshing for protection. Order 'n' for working, order n**2 for protection. So much for the "ounce of prevention..." maxim ;-).

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

In some ways it is an artificial requirement. The existence of a PML suggests that there is by definition only one egress point from:

        - an MPLS domain OR
        - a protected domain
where in reality there may be multiple points of attachments between domains (and in fact is DESIRABLE to have multiple points of attachment), and the contruction of LSPs for the working and protection paths may end up with diverse egress points once the need for true path diversity is factored in. At some point in the network, packets for a particular destination originating from working and protected paths in the protected domain MAY merge, but it is not necessary that this happen within the protected domain, nor is it a requirement that it happen at the granularity of the FEC. The only scenario whereby I can imagine a common PML for both working and protection is where the FEC is for a stub network (single point of attachment). If the PML is somthing which only exists occasionally, it is confusing to explicitly identify it.

The reality is that what is proposed is that the PSL has a plurality of paths (typically 2) for which one is a primary and one or more is a backup. The RNT failure notification mechanism is unique for each path. The root of an RNT is either the root node of the specific LSP at the edge of the MPLS domain, or administratively constrained as being some intermediate node at the edge of a protected domain. It would be rare that a PML occured at the same node.




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

Multiple PMLs on the RNT scares me, as the granularity of repair and the number of "single points of failure" goes up. This also poses the interesting question which is are the information flows up the RNT sufficient to localize the failure. I have to admit that to me, by definition, an RNT is scoped to providing protection to a single LSP tree within a single domain. Otherwise the plurality of failure scenarios is overwhelming.




In general I still see no reason for the RNT root to also be a PML. I just don't see the PML as an explicit entity that is tied to the granularity of the FEC, nor explicitly localized at the egress point of the protected domain. It is somthing that will happen naturally regardless....

regards
Dave