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

From: Vishal Sharma <[email-masked]>
Date: Wed, 12 Apr 2000 13:14:06 -0400

Hi Bora,

Thanks very much for your detailed comments. Some of your questions that can be
answered immediately, we'll answer right away. For others, we'll defer to a bit
later, so that my co-authors and I have a chance to discuss and prepare a respone.

-Vishal

On Tuesday, April 11, 2000 8:53 PM, [email-masked] [SMTP:[email-masked]] wrote:
> I have read the draft and have the following comments:
>
>
>   1. It is unclear how the RNT mechanism with its FIS/FRS timers differs
>      from RSVP with TE extensions. Specifically, the timers and the RNT
>      mechanism resemble RSVP reservations with soft state but with
>      inverted logic. This should be explained.

We want to develop a general algorithm that can be used
by RSVP, CR-LDP or other mechanisms (e.g. layer
2). For the RSVP case, maybe there are some overlaps. But we need to check that.
Our initial reaction is that they are different.
Our algorithm requires each node to send their notifications actively while RSVP
will send error message as a response to refresh message. In other words, our approach may be 
viewed
as a trap while RSVP is a poll. However, we need to check these conclusioins.
Another point is that if the notification is through layer 2, it will be different from the RSVP 
approach.
Therefore,  our approach is more general.

Thus, I am not sure that the RNT mechanism can be folded into RSVP-TE, but
thanks for pointing this out. We will examine this more carefully, and provide
an explanation.

>   2. The text does not specify via what mechanism the FIS/FRS packets
>      are transmitted? Via UDP/TCP over IP, via the DCC in the SONET
>      overhead using ISO CLNS? It would be nice to have some packet
>      formats and outlines of transmission routines.

This is actually explained in Section 2.1 and in Section 3.2 paras 2 and 3 (for the Layer 2 and
hop-by-hop cases, respectively).  Essentially, our initial thought was to have the
FIS/FRS packets be either UDP packets (for the hop-by-hop case) or MPLS labeled
IP packets.

The point on the packet formats, however,  is well taken. We will try to include that in the
sequel. If you have any specific suggestions, please let us have them.

>   3. It is pointed in the text that MPLS protection reserves bandwidth
>      but the text fails to mention SONET also reserves bandwidth.
>      Moreover, in most current IP/MPLS LSRs, unused bandwidth is usually
>      used for lower traffic classes.

I'm a little unclear on why this is important to mention, since we make no assumptions
about how the protection bandwidth is used, and that does not affect the path protection
mechanism per se.  This is a good point though, and we have discussed some of this
in the first paragraph of section 3.3.

>   4. I found sect. 2.2.1 useful.

Thanks!

>   5. Are FIS and FRS defined somewhere?

Actually, these are defined in the MPLS recovery framework draft,
draft-makam-mpls-recovery-frmwrk-00.txt. We see your point though, and we'll repeat the definitions
in our draft for easy reference (like what we've done for the PSL, PML etc.).

>   6. Timers: There are way too many timers. I do understand that the RNT
>      cuts down on the amount of notifications, but on core routers with
>      large number of interfaces with large number of LSPs flowing
>      through them, 8 timers per RNT is a bit much. This is sort of
>      related to the question 1 above too.

Please note that timers for failure detection are on a per-link not a per-LSP basis.
Additionally, the timers for FIS and FRS will not exist simultaneously, this cuts the states in 
half.
Other timers such as the hold-off timer may also be shared on a per-node or per-link basis.
So the timers are not as many as may appear at first. Also,  the
states for the  FIS and FRS are deterministic (time-wise), and they only exist for a fixed
amount of time.

Also, a point to be noted is that we have defined timers that we think are useful.
However, not all timers need to be used in a specific implementation. Many of
these timers may have a default value of zero, if they introduce processing that
a particular LSR cannot handle, or if the network provider feels that they do not
need certain timers.

>   7. It seems to me that there is a lot of state associated with each
>      RNT especially when the inverse forking ratio (IFR) is high. It
>      would help to clearly specify exactly what state needs to be
>      maintained in a list.

We have tried to specify some of this in Section 3.1, and by saying what information
each of PSL, PML and intermediate LSRs need to maintain. However, this is a good
point, and we'll introduce a list with the needed state information in the revision.

Also, note that using a layer 2 approach will be better. And this is not covered in RSVP.

>   8. In general, people are not concerned with the volume (bw) of
>      signaling traffic but the overhead it costs in terms of processing.

Thanks for pointing this out. I think if we address some of the points you raised
earlier, it would be easier to see the amount of processing that might be needed.
We note, however, that any path protection scheme, by its very nature (due to the
need for notification, switchover, etc.), will entail some amount of processing.

> In general, I found the draft of some value, but I think the RNT
> mechanism should be either separated from the protection procedure or
> put in an appendix.

This is a little confusing to me. Essentially, the RNT mechanism is the heart
of the path protection procedure described in the draft. How could we separate
the two?

> RNT bears striking similarity to RSVP and there are already quite a
> number of fields defined in RSVP-TE for the purpose of protection
> switching signaling, so can we just add what is needed to RSVP-TE?

This goes back to my response to Question 1 above. We need to think
about this.

> The text also omits all discussion of how restoration paths are
> computed, what constraints need to be imposed, etc.

This was done on purpose. The goal of the draft is to specify a mechanism
to perform path protection. It is not a goal of this draft to discuss the specific
algorithms that are used to compute paths, incorporate network constraints
etc. First, the protection mechanism itself does not depend at all on how
paths are computed. Second, we expect those to be proprietary, but the
mechanism and its associated signaling to be standardized.

For instance, the alternate path computation may use one of several available choices.
For example, Slosiar and Latin's algorithm that appeared in Infocom'00
A Polynomial-Time Algorithm for the Establishment of Primary and Alternate
Paths in ATM Networks
Rasti Slosiar (Telstra Research Laboratories (now with Swisscom AG)),
David Latin (Telstra Research Laboratories)
http://comnet.technion.ac.il/infocom2000/

> There is also a lack of specificity in the text, which I hope will
> improve in a subsequent version. Ideally, an Internet draft should lend
> itself to being read and then implemented unlike a research paper.

As we receive more comments from the list and try to incorporate them in
subsequent revisions, I'm sure we'll more towards becoming more specific.
Please note, however, that it was not the objective of this draft to specify
particular formats (for instance we haven't specified here signaling extensions
to LDP/CR-LDP or RSVP-TE that would be required to implement this mechanism).
This was partly because the mechanism allows for flexibility in
how certain parts of it are implemented. Nonetheless, I agree that it would
be useful to specify some formats for some of the alternatives to help
implementation.

> Finally, a question to the audience, how does the proposed scheme
> interoperate with vendor proprieatry implementations of protection
> switching? Now that the cat is out of the bag, we may want to open up
> and agree on a standard.

Good one. I guess the audience is the best one to answer that!

---

From: "David Allan" <[email-masked]>
Date: Wed, 12 Apr 2000 13:15:21 -0400

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.

2.1 - What is an FIS and FRS?

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

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

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?

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

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

cheers
Dave

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 13 Apr 2000 13:28:07 -0400

Dave,

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

-Vishal

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

> if multiple simultaneous failures are to be minimized.

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

> An equally

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.

> opportunity for re-use for LSPs which have common routing between the PSL

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.

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

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

> 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

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.

> egress node from the network).

Correct. See response above.

> Realistically the useful functionality of an

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

---

From: "David Allan" <[email-masked]>
Date: Thu, 13 Apr 2000 13:15:21 -0500

Vishal:

	Embedded comments...

	<snip>

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

> paths merge), and for a particular LSPs, their PMLs could be the egress
	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.

> 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

---

From: Vishal Sharma <[email-masked]>
Date: Fri, 14 Apr 2000 18:53:05 -0400

David,

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

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

> 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

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.

> node at the edge of a protected domain. It would be rare that a PML occured

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.

> 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

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

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

---

From: "David Allan" <[email-masked]>
Date: Mon, 17 Apr 2000 11:40:25 -0400

Vishal:

	<snip>

> In general if the backup paths form trees, you get savings.
	My concern is not with the RNT mechanism. It is more with the
construction of useful working and protection paths that are:
	- physically diverse
	- optimal   
	That concern is not specific to your proposal.

	<snip>

> same as the one we use in our draft).
	Ultimately the problem I have is with the definition of protected
domain. It limits the protection domain to being a set of LSRs with an
explicitly identifed PSL and PML, which I take to mean it is a contiguous
MPLS cloud or some administrative subset which has single egress point
(which may be an artificial limitation). The statement that the PSL and PML
are identified during the setting up of an LSP also bounds the granularity
of the merge function to being that of the FEC that the LSP is set up to
forward. I find this limiting.

	So why is there an explicit merge function inside the MPLS cloud?
The whole network will not be MPLS, therefore merge can be deferred further
towards the edge of the network and increased reliability can be obtained if
the protection domain extends beyond MPLS domain. Where the merge function
occurs for a specific packet will not be known to the PSL at LSP setup as it
is a function of overall network state ands that's OK. How packets at some
point downstream end up back on a common routing to a host doesn't have to
happen at the granularity of the LSP originated at the PSL and may not
happen until a true single point of attachment to the network is reached
many hops beyond the edge of the MPLS cloud. 

	If such a thing as the PML existed, then the PML would have to
promiscuously accept packets from both the working and backup trees anyway
as not all failures in a tree would be propagated to all PSLs. So it is
really nothing more than an LSR which "by convention" stuff has to pass
through. It may anchor a RNT for livliness messaging for each tree that ends
there (which functionally can be disassociated from a promiscuous merge
function as there is no reason that fast failure detection needs common
state between working and protection paths either except at the PSL). What
that means to me is that there is a "single point of failure" (the "per LSP"
PML) which could be avoided "by convention" as well by allowing multiple
points of egress from the MPLS protected domain (which is a subset of the
network protected domain).

	As much as we would like a tidy, administrable and measurable
definition of how far protection extended, IMHO the network would be more
reliable if we didn't cap the definition of protected domain as being wholly
within MPLS. 

	regards
	Dave

---

From: Vishal Sharma <[email-masked]>
Date: Tue, 18 Apr 2000 11:30:09 -0400

David,

Thanks for the observations. Comments below.

-Vishal

> 	That concern is not specific to your proposal.

I'm glad you clarified that. As you rightly observe this is an issue with
any algorithm/intelligence that is used to compute the paths. However,
as I'd said earlier, we view the two as distinct problems. That is the
computation of the working and protection paths with the right characteristics
is independent of the mechanism used to perform fault detection, notification,
switchover, and switchback, and we are focusing on the latter.

> (which may be an artificial limitation).

No that is not how we have defined a protection domain. In our definition, a
"protection domain" is the union of the set of LSRs that lie on the working and
protection paths. This does not restrict them to lie in a single MPLS cloud,
or a single AS, or a single adminsitrative domain (or any subset of it). What
we are saying is that the working and protection paths must have a single
merge point (at some point along their path, possibly at the egress LSR), which
need not necessarily be in the same domain as the PSL.

As I stated earlier, although the most common interpretation of it might be
to refer to LSRs within a given AS or MPLS domain, the protection domain
is not restricted to lie within any such boundaries.

> The statement that the PSL and PML

Ok, this I agree with (although see my question three points later).
But do you have any suggestion about alternatives that
we can incorporate into our mechanism?

> the protection domain extends beyond MPLS domain.

Yes, absolutely right. As I've emphasized, nothing in the mechanism restricts
things to be within a single MPLS domain. If you could say what in our mechanism
makes you feel that the mechanism is restricted to a single MPLS cloud/domain, perhaps
we can try to rewrite that portion to correct this (since the mechanism, strictly speaking,
isn't restricted in that way).

> Where the merge function
> is a function of overall network state ands that's OK.

I don't agree with this. The intelligence/algorithm computing the working and alternate
paths will have to know where the traffic on the two paths merges (possibly based on
network topology and network state), but it will have to know that. If you don't know
where the protection path merges into the working path, how are you going to get
a viable protection scheme (unless one is doing merely local repair)?

> How packets at some

As before, I agree that the merge may not happen at the granularity of the LSP, and
as before, I'd like to know if you have any alternative to the proposal we have (merging
at the granularity of the LSP (which could be a tunnel, btw), was a workable choice
that we used, which seems reasonable to us). In fact, I have some difficulty seeing the
value of not merging at the granularity of the LSP, when it is the LSP that one is protecting.

About the MPLS cloud bit, I think you seem to be making the assumption that our
mechanism is somehow restricted to a cloud, when it is not.

> through.

Actually, it is an LSR that data gets merged at (and therefore, of course, it has to
accept packets from both the working and protection paths).

> It may anchor a RNT for livliness messaging for each tree that ends

Again, you seem to be drumming home the point about a single MPLS domain,
whereas as I've pointed out numerous times, the mechanism is not restricted
to a single domain, hence there is no "single point of failure" in your sense.
There is of course, a single point of failure at the point at which the working
and protection paths merge, and this is unaviodable (except perhaps by
redundancy within the LSR that is the merge point or PML).

> reliable if we didn't cap the definition of protected domain as being wholly

Agreed, but we aren't capping the definition that way! (As nearly as I can tell,
you're making that *assumption* about our mechanism! :-))

---

From: Vishal Sharma <[email-masked]>
Date: Tue, 18 Apr 2000 16:49:03 -0400

Hi Dave,

This is a follow-up to my earlier response to your email. After internally discussing
your point about the PML being an artificial restriction and the possibility
of multiple exit points out of an MPLS domain, we think
we understand what you were saying, but think that implementing that
may require stretching an MPLS-based solution (which was our goal)
a bit, since it may require information beyond what is easily available
to MPLS. This was one reason we had not expanded our initial solution
to include such cases.

However, your point is a valid one, and we'd like to explore to what extent
such alternatives can be incorporated into an MPLS-based recovery
mechanism such as ours. One of my colleagues, Ben Mack-Crane, who I believe
understands your point best, will be sending out an email explaining
what we think your point was, and we'd appreciate receving your feedback
on whether we've captured it right, and other follow-up thoughts.

Regards,
-Vishal

On Monday, April 17, 2000 11:40 AM, [email-masked] [SMTP:[email-masked]] 
wrote:
>  << File: ATT00000.html >>

---

From: Ben Mack-Crane <[email-masked]>
Date: Tue, 18 Apr 2000 17:44:59 -0500

Hi Dave,

You are correct in noting that the PML is limiting, as
a single egress point for the MPLS protection domain;
however, removing this limitation requires some knowledge
beyond that necessarily held by the MPLS layer.

There are two extensions that I can think of based on your
comments (please let me know if I have misunderstood your
comments).

1) The working and recovery paths never merge as LSPs.
Instead, the recovery path terminates at an LER that is an
acceptable alternative to the LER terminating the working
path for the purpose of forwarding the FEC represented by
the working path.

In this case, the protection domain is still within a
contiguous MPLS cloud (which BTW implies nothing in particular 
about administrative domains).  The protection mechanism
still works with information available at the MPLS layer
(fault detection, protection actions, etc.).  However, selection
of the recovery path (outside the scope of this ID) requires
L3 knowledge to determine that the LER terminating the 
recovery path is acceptable.

In practice this may be an attractive option, although
some thought may be required to apply this in an end-to-end 
recovery design for other than best effort traffic.

2) The protection domain spans both MPLS hops and L3 hops.

Here the protection domain is not within a contiguous MPLS
cloud, and recovery within such a protection domain may be
complex.  Since the protection domain includes both MPLS and
L3 hops, fault detection and recovery actions may be significantly
different depending on where a fault occurs (and the protection
mechanism would require L3 knowledge in some cases).  It may 
be difficult to guarantee uniform recovery performance across 
the entire protection domain.  

The advantage of this broader definition of protection domain
is that it is not necessary to merge the traffic at arbitrary
boundaries (e.g., at LSP terminations, AS boundaries, etc.).
The complexity, however, makes this definition more difficult
to characterize, and makes defining a coherent protection 
mechanism harder.

Both of these extensions require some L3 knowledge, but the 
second is the only one that requires L3 knowledge in the 
protection mechanism itself.  The original mechanism was
intended to work entirely within the MPLS layer.  These
potential extensions would broaden the scope beyond MPLS,
at the cost of additional complexity.

Perhaps it is better to live with some limitations so that
the mechanism is simpler (there is some value in a "tidy, 
administrable and measurable definition of how far protection 
extended").  Thoughts?

Regards,
Ben Mack-Crane

---

From: "David Allan" <[email-masked]>
Date: Thu, 20 Apr 2000 11:19:18 -0400

Ben:

Thanks for your comments. Rooting back through the other drafts, this
discussion should really be focused around the framework draft
<makam-mpls-recovery-frmwork-00>. To my mind the issue is whether MPLS is a
black box and the very worst manifestation of a failure is a 'x' msec.
interruption of packet flow out of a particular interface, OR whether we
allow "less specific" box behaviors such as the packets keep flowing out of
the box, but it may be a different interface. Seems to me that there are
cases for both.

	<snip>

> beyond that necessarily held by the MPLS layer.
Yes, there would have to be a path diversity test combined with some
link-state knowledge of the over all network to ensure that the alternate
egress point was appropriate. 

> contiguous MPLS cloud 
	Effectively yes. We have not discussed fast failure detection,
propagation, and pre-planned alternate route mechanisms outside the MPLS
space. 

> (which BTW implies nothing in particular 
> about administrative domains).  
> 
	Agreed, however such things MAY exist, such as intercarrier
boundaries inside a contiguous MPLS space. That would be my only
observation. The boundary MAY not be technical and in the real world that is
what frequently happens. If there is some form of pre-emption, then it is
also useful to constrain the space to minimize the amount of traffic
distrupted.

> The protection mechanism
	I would broaden the definition as selection suggests to me explicit
routing, whereas increasing the reliabilty of implicit path construction
would imply intelligent pruning of options. To a certain extent,
conservative label retention in an implicit case implies some knowledge of
which LSPs would be more optimal than others, and sufficient information
should be available at the overall L3 layer (not just MPLS topolocy) to make
that determination.

> recovery design for other than best effort traffic.
	Yes, bang on!, to my mind there is two goals to this effort in
general. First is providing explicit recovery mechanisms for specific flows
that require specific service guaratees, and second is raising the
reliability bar overall. You're correct in identifying best effort, as e2e
RSVP reservations carried through such an "LSP tunnel" require explicit
black box behaviour to avoid the interruption of re-routing on a protection
switch (or establishing a new "deaggregator"). That is NOT the scenario that
I think a non-PML solution adds value to.

> 2) The protection domain spans both MPLS hops and L3 hops.
	Not sure how this really differs from '1' except the suggestion that
there are fast non-MPLS restoration mechanisms which require some overall
coordination.

> the entire protection domain.  
	I think in general it is easiest to think of this as concatenated
protection domains with redundancy at the domain boundary. Ultimately it is
a form of "Per-Hop Protection" ;-)  as the lack of uniformity of mechanisms
makes explicit guarantees difficult but the performance is the best the
overall network can do. If we stick to that definition then there is really
no difference between 1 and 2. 

> at the cost of additional complexity.
	If I get your inference, you assume that a non-MPLS protection
mechanism requires some type of resource reservation.

> administrable and measurable definition of how far protection 
	My summary would be:

	1) We need to clarify overall the goals of MPLS restoration. Is it
explicit black box behavior or are we seeking a broader base of solutions
that dovetail into the overall network. If we are discussing a broader base,
then a 1:1 or n:1 non-"lsp merging" solution has applicability. If we are
"black box" only as it works for all style of protections (1+1, n:1, 1:1),
all styles of traffic (best effort, diffserv and RSVP pinnned route) and is
measuable, then we'll have to tolerate less optimal e2e routing and topology
to get that. Personally, I'd like a bigger toolbox.

	2) I don't think we need to overload the recovery space by expanding
the protected domain beyond MPLS, only acknowledge that we may concatenate
protection mechanisms, they function autonomously, and may have multiple
points of attachment. Coordination of protection across multiple transport
technologies is out of scope if we are to make progress.

	cheers
	Dave

---

From: Ben Mack-Crane <[email-masked]>
Date: Thu, 20 Apr 2000 14:45:45 -0500

Dave,

I like your view.  Some comments/questions below.

Regards,
Ben

> the box, but it may be a different interface. Seems to me that there are

In the intiial framework we had focused on "MPLS Path Recovery," and since 
a path has fixed endpoints...  Well, there's where the blind spot came from.  
The current position of the framework, "MPLS Based Recovery," admits a 
broader interpretation and so it makes sense to incorporate an option to 
have diverse egress points for working and recovery paths.  

Any comments from other framework authors?

> should be available at the overall L3 layer (not just MPLS topolocy) to make

Selection, in this case, was meant generically (not intended to imply explicit
routing); however, the path protection mechanism draft does not address
reroute recovery (this is covered in other IDs) and so the broadening
you suggest may be out of scope for that ID.  Is there a need to address this 
in the framework (I don' think the framework says anything in particular about 
recovery path selection options)?

> I think a non-PML solution adds value to.

I agree.  The diverse egress case may be paricularly useful for improving the 
reliability of best effort traffic.

> no difference between 1 and 2.

I was concerned that the broader defintion of protection domain being proposed 
implied that ONE recovery action (e.g., PSL switch) would be able
to recover from any fault in the protection domain.  I had trouble seeing
how a fault on an L3 link could be correlated with the working LSP, and the 
PSL informed.  The concept of concatenated protection domains is much
simpler, and I think this allows a narrower definition of protection
domain (uniform mechanism).  Redundancy/diversity/coordination at protection 
domain boundaries is then the interesting problem.

> mechanism requires some type of resource reservation.

Well... I wasn't trying to say anything about non-MPLS mechanisms.
We are trying to further clarify the framework terminology (a summary
has been posted to the mail list by Vas Makam) and "protection
switching" implies resource reservation.  This is not to say that
there are not recovery mechanisms that work otherwise (e.g., reroute
recovery).  The path protection mechanism ID is aimed at protection
switching, so resource reservation is assumed there, and this leads
to some desire to have a mechanism that operates simply at the MPLS 
layer.

> to get that. Personally, I'd like a bigger toolbox.

It makes sense to have a bigger toolbox, as long as we have a reasonable 
understanding of the tools and their appropriate use.  You have pointed out
a useful alternative to be added, and we should try to develop a clear
description for the affected IDs.

> technologies is out of scope if we are to make progress.

This seems reasonable.

> 
>      cheers
>      Dave
> 
>   --------------------------------------------------------------------------------
>                   Name: att1.htm
>    att1.htm       Type: Hypertext Markup Language (text/html)
>               Encoding: 8bit
>            Description: Internet HTML

---

From: Vishal Sharma <[email-masked]>
Date: Thu, 20 Apr 2000 16:38:56 -0400

Dave,

I concur with Ben. Good thoughts all!
Please see my comments below (unneeded text deleted below).

-Vishal

> the box, but it may be a different interface. Seems to me that there are

I think what you mean above is different than what Ben alluded to in his reply
to you. If I understand you, you are asking that the MPLS recovery cover the
case not only of those problems where there is an actual break in traffic
(treating LSR as a black box), but also those cases where there is no
break in traffic, but things at the MPLS layer are messed up. My response
is: absolutely!
(In fact, Neil Harrison of BT in a response on the list a couple of days ago had made a very
good characterization of the types of errors that may require protection/recovery,
which I would recommend.
If you haven't seen that one or cannot find it, pl. let me know. I'll forward it.)

And, the framework document does allow for both these possibilities.
In fact, a look at the types of errors (enumerated in the framework document)
that could occur at the MPLS layer shows that they allow for
things like misbranching, errored packets, misdirected packets, etc.
If you feel there is something missing in the framework as it stands, please
let us know.

> also useful to constrain the space to minimize the amount of traffic

I got lost on the last sentence here. By pre-emption do you mean the
usual --- pre-emption of low priority traffic on the protection path by
working traffic once the protection path is brought into use?

> should be available at the overall L3 layer (not just MPLS topolocy) to make

Again, I have a question. Why do you say that conservative label retention implies
a knowledge of which LSPs are more optimal?

> I think a non-PML solution adds value to.

Absolutely. Agreed.

> no difference between 1 and 2.

I like the concatenated protection idea. This is sort of what I had alluded
to in an earlier email where I'd said that one may do protection of
a multi-domain LSP (ie, an LSP that spans multiple MPLS domains
one after another) on a segment by segment basis. Of course, the
implication above is more general than that.

<snip>

> that dovetail into the overall network.

I think the recovery framework document encompasses the broader definition.
As before, if you feel something more is needed, let us know.

> If we are discussing a broader base,

I'd say that we are indeed discussing the broader base. And yes (now that I
understand it more clearly), the non-LSP merging solution has applicability
and should be mentioned in the mechanism draft. (The framework draft
in any case does not refer to any particular solution(s).)

> technologies is out of scope if we are to make progress.

Agreed. I would like to add, however, that with the recent on-going activity in
the MPLS + crossconnects area, we might have to think about coordination
at least across the MPLS and optical transport networks (since that may be
an important case in practice).

---

From: "David Allan" <[email-masked]>
Date: Thu, 20 Apr 2000 15:58:52 -0500

Ben:

	<snip>

> recovery path selection options)?
	I'll admit, I've lumped the recovery mechanisms together where
protection switching with resource reservation (and the corollary effect,
pre-emption) is a superset of reroute recovery. To my mind, where reroute
recovery and protection switching collide head on is in every way but the
timely allocation of resources on the backup path (where specific resource
allocation is required and we're out to be frugal). The livliness
mechanisms, path routing, revertive protection etc. have common
requirements. Such as timliness, path diversity, minimal disruption of
ordering etc.  

	<snip>

> domain boundaries is then the interesting problem.
	Agreed, some of this is addressed by redundant egress LERs, as a
failure of the egress LER can be addressed in the MPLS domain, a failure
downstream of the egress LER is handed by the egress LER or a downstream
node in the network. (it wears two hats). If I'm into another MPLS domain, I
may have redundant trees, one anchored on the working egress LER and one on
the protection egress LER, (I'd probably have that anyway), and if it is
some other technology, it presumably would be non-MPLS re-route and may not
be as fast, but then thats what you get.

	<snip>

> to some desire to have a mechanism that operates simply at the MPLS 
	I'm not out to re-invent the rest of the network either...

	<snip>

> description for the affected IDs.
	Agreed.

> > technologies is out of scope if we are to make progress.
	Good,

	regards
	Dave

---

From: "David Allan" <[email-masked]>
Date: Thu, 20 Apr 2000 17:17:45 -0400

Vishal:

comments imbedded, and extraneous stuff removed...

<snip>

> working traffic once the protection path is brought into use?
Yes, and segmenting the recovery space usually means that the disruption of
pre-empted traffic can be localized and minimized, I do not preempt the
traffic along the entire backup path.

	<snip>

> a knowledge of which LSPs are more optimal?
I have to assume that for it to be useful. Some intelligent filtering of
implicit advertisments is required when doing the topology, even if simple,
"this LSR advertisment came in on the optimal interface for this FEC
according to my tables, so I'll keep this one". However I have not done
enough "I-D archeology" in order to substantiate this in detail. This is an
area I would like to understand better.

> implication above is more general than that.
Good.

> As before, if you feel something more is needed, let us know.
I'll review it accordingly. But I'm timing out for this week ;-)

	<snip>

> I would like to add, however, that with the recent on-going activity in
I think there is applicability and common requirements. But this is one I
need to think about as there are differences in the space.

regards
Dave