The MPLS WG Archive

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

David,

Thanks for the comments. Please see the responses below.
-Vishal

On Thursday, April 13, 2000 2:15 PM, dallan@nortelnetworks.com [SMTP:dallan@nortelnetworks.com] 
wrote:
> > > 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 ;-).

I am not sure why you call it a "scalability hit". The RNT mechanism cannot
be any worse than having one backup LSP per working LSP.
Also, how do you get (n+1)^2 meshing (and what is "n")?
In general if the backup paths form trees, you get savings.

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


First, I am not sure how you define a protection domain (and whether that definition is the
same as the one we use in our draft).

Nonetheless, you seem to be making an implicit assumption that our mechanism must be
confined to a particular IGP or MPLS domain. Why is that necessary? I don't think anything
that we have said confines the PML to be in the same domain as the PSL.
If that is so, the diversity of egress points at a domain boundary does not
really play a role in the assumption that the working and protection paths
must merge at some point, which we call the PML.

(One objection to the statement I just made might
be that we said earlier that some intelligence will be used to compute the
primary and alternate paths through a domain, and that it will know about the
PSL and the PML. However, if it is true that the working and protection
paths are diversely routed through a domain and actually merge in a different
domain, just knowledge of  a particular domain will not be sufficient to identify
the PML. Clearly, there then has to be some way of coordinating the path selection algorithms
in the two domains so that the combined intelligence may identify
the PSL and PML.)

Having said that, it may be that the most useful case will probably be one where the
PML is kept in the same domain as the PSL. If an LSP transits many domains, and
needs to be protected, it might be desirable to provide protection to segments of
it independently within each domain, rather than have one protection path spanning
multiple domains. (Arguably, this may not be the most bandwidth efficient way of
doing things, but it may be simpler.) This also allows for different domains to use
different protection methods if they so desire, without requiring them to know about
each other's protection mechanisms.

> If the PML is somthing which only exists occasionally, it is
> confusing to explicitly identify it.

I am not sure what you mean by "occasionally." An LSR is deemed to be
a PML for a particular LSP, for as long as the working path
and the protection path, which merges into the working path at the PML, both exist.

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

I agree that it is indeed possible that in some cases it may be desirable to have a
certain node as the root of the RNT, which may not be a PML. (For example,
in the figure in our draft, if link 6-7 was very reliable, LSR 6 might be designated
as the root of the RNT, instead of LSR 7).

I guess the figure in our draft suggests that the two are the same, which isn't required.
We'll modify our figure (or add a new one), and also add some text clarifying this in
the revision.

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

In support of your point earlier, I had agreed that multiple PMLs per RNT are
certainly possible in our scheme. It  may be that one would try to
minimize the number of PMLs on an RNT for reasons you mention, but that may
not always be possible (just because of the topology of the network).
Also, I  am not sure that you need fault isolation simply because you have multiple
PMLs on a given RNT. In any case, the RNT does allow for only those PSLs
affected by a fault to be informed, so in that sense, there is "fault isolation."

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

Certainly, confining the RNT mechanism to a single domain makes things
simpler. Although, nothing in the mechanism precludes it from spanning
multiple domains.

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

I agree, and add that I don't think there was an implication that the PML be
explicitly localized at the egress point of an IGP or MPLS domain (I am
not sure what you mean by the protected domain. Note that our definition
of a protection domain is something entirely different.)