Subject: Re: Comments draft-ietf-mpls-recovery-frmwork-00.txt

From: [email-masked]
Date: Sun, 1 Oct 2000 16:17:36 -0500

Hi Sergey,

I apologize for the delayed response. Our company email server
was having some problems the week you sent this email, so 
I never received a copy of it directly. It was only this
weekend, while reviewing the MPLS list archives, that I came
across it, so I am responding at the first opportunity.

Anyway, thanks very much for your comments and observations.
Please see my comments below.

Regards,

-Vishal

> -----Original Message-----

> Comments: draft-ietf-mpls-recovery-frmwork-00.txt
> 
>      From: Porotsky Sergey <[email-masked]> 
>      Date: Thu, 21 Sep 2000 15:58:25 +0300 
> 
> 
> Hello, Vishal. 
> Thanks for this draft, it gets us very good initial point to create
> protection/restoration schemes. 
> I have a few comments and questions.
> 
>         1. In section 1.3 you have wrote : 
> "I. MPLS-based recovery mechanisms should facilitate fast (10?s of ms)
> recovery times."
> I agree, that it is necessary and it is possible to support 
> for protection
> mechanisms. But is it really to support for rerouting 
> schemes, in which the
> recovery path is not pre-established ?   

If I understand your question, you are asking whether the 10s of ms
objective holds also for the case where one uses reroute recovery.
Please note that we specify the 10s of ms as an _objective or goal_
for protection/recovery schemes, as opposed to making it a requirement. 
Not all of the schemes may meet
this goal. In particular, reroute recovery schemes, where the
recovery path is not pre-established may take longer to recover
the working traffic.
 
> 
>         2. In section 2.1.1 is written :
> "In terms of the principles defined in section 3, reroute 
> recovery employs
> paths established-on-demand with resources reserved-on-demand."
> I think, that for pre-planned rerouting techniques we can use two
> alternatives:
> *       Only recovery route is selected, resource reservation 
> is absent;
> *       Recovery route is selected and resources are 
> semi-dedicated (e.g.,
> bandwidth is pre-planned assigned and shared for several 
> recovery paths). 

You are correct. This is something we realized before the last
IETF but did not incorporate into the draft yet. In fact, the latter
case is particularly important in the case of generalized MPLS (GMPLS),
where resources for protection paths in a SONET or an optical 
cross-connect may be
reserved, but the actual cross-connections may not be made until
a fault occurs, and it becomes known which of the working paths sharing
the protection resources actually has the fault.

We will incorporate this in the next revision. 

>         3. In section 2.3.1 is written:
> "Rerouting - a recovery mechanism in which the recovery path or path
> segments are created dynamically after the detection of a fault on the
> working path."
> Notion "rerouting" usually is used not only for recovery. For example,
> ATMForum uses both notions hard-rerouting 
> (break-before-make)for recovery
> and soft-rerouting (make-before-break)for re-arrangement. 

The draft, as written, does not, strictly speaking, have a notion of
"soft rerouting" in it, since we felt that that is not a notion that 
is related
to protection or recovery. We were using "rerouting" always in the 
context
of "hard rerouting." The notion of optimizing a path is partially 
addressed in the draft under "dynamic re-routing cycle" in Section 
2.2.3.
Do you think that we need to talk about "soft rerouting" in the draft?
 
>         4.In section 3.3 is written:
> "Reserved-on-Demand:This option may apply either to rerouting or to
> protection switching. Here a recovery path reserves the 
> required resources
> after a failure..."
> Is it really for protection scheme to reserve resources after 
> failure? If I
> understand right, for this scheme the aim of the recovery LSP 
> establishment
> before failure is only label assignments. In this case after 
> failure  for
> early established recovery LSP it is necessary once more to 
> perform Setup by
> means of LDP/RSVP signalling, isn't it? Moreover -  this 
> scheme, in differ
> of pre-reserved protection, can't guarantee success of this 
> second Setup.
> What is significant difference and advantage of this scheme 
> from re-routing ?

The scheme referred to above is what you have earlier called:
>*       Only recovery route is selected, resource reservation 
> is absent;

The advantage of such a scheme over rerouting is that the recovery
route can be selected a priori by on-line or off-line algorithms
and, as you observe, label allocation can be also done along the 
recovery
route (although it may not be), which would not be possible in a pure 
rerouting scenario.

Also, in the above scheme, since the backup route is selected before
hand, it can be done more carefully than might be possible in a 
rerouting scenario. The only thing that remains upon the occurrence
of a fault is to use signaling to reserve resources along the path.
If the backup route calculation is a time consuming exercise (which
it can be in a mesh network) this scheme can be faster than pure
rerouting. In fact, pure rerouting may be forced, due to time
constraints, to simply resort to using hop-by-hop routing to find
the protection path, which may not be good or optimal.

Of course, if one argues that in the "rerouting" case also, one will
run the same path computation algorithms as in the protection switching
case, and make a resource reservation along an optimal backup path, then
the first scheme may not offer any advantage over the reroute case.

> 
>         5. In section 3.6 is written:
> "Fault Notification: Protection switching relies...the node 
> should send out
> a notification of the fault by transmitting a FIS to those of 
> its upstream
> LSRs..."
> What we have to use for notification on the Rerouting Scheme 
> - also FIS or
> other mechanisms?

The implicit assumption in our description of the reroute scheme was
that the nodes affected by the fault learn of the fault via changes
to the routing updates. I suppose it is possible, even in the
reroute case, to have the affected nodes (PSLs) be notified
by some means other than routing. In that case, an FIS message
would be one way to do so.

---

From: Porotsky Sergey <[email-masked]>
Date: Thu, 5 Oct 2000 14:09:13 +0300

[Porotsky Sergey]  Vishal Hi, and thanks for your answer. See my
comments below. Regards, Sergey.

> [Vishal]
> I mentioned the FIS as one possibility to intimate the affected 
> source(s) of a
> failure that requires their intervention. It does not mean that the 
> source(s) will 
> begin recovery immediately on receipt of the message. They will, as you 
> observe,
> take care of planned rerouting before initiating reroute recovery. In 
> fact for 
> the reroute recovery to be reliable, they would have to wait for the 
> routing tables
> to converge. (Otherwise, an alternate route picked by the source might 
> need to be
> changed again once the tables converge.)
> 
> As regards the explosion of the RNT tables, that would depend on the 
> number and
> granularity of the LSPs in the network. In fact, that is why, our 
> assumption
> was that re-route recovery works in conjunction with IP routing 
> protocols, and
> has to wait for them to converge. In that case, no special notification 
> to
> the sources is needed. They learn all they need to via the routing 
> updates.
> 
> The RSVP Tear-Down message itself may not reach the desired source, if 
> the
> routing tables haven't converged, so I am not sure that that would be a 
> useful way to intimate the source. (Note that the FIS message uses 
> a preconfigured reverse path, that does not depend on L3 routing 
> tables.)
> 
	[Porotsky Sergey]  OK. You are correct, for re-routing based on
IP/OSPF routing protocol it isn't necessary to use both FIS and Tear-Down.
But why do you want to use IP routing and don't use Explicit Path Selection
for re-rerouting? I think, that for pre-planned re-routing we MUST to use
Explicit Route (pre-defined before failure) and also for on-demand
re-rerouting we SHOULD use Explicit Routing - at least for Traffic
Engineering Goals.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Oct 2000 08:57:07 -0700

Hi Sergey,
 
I think when Vishal says "the source waits for the IP routing to converge,
he does not necessarily mean normal OSPF/IS-IS, rather the TE extended
OSPF/IS-IS, which could then be used for explicit routing.

Regards,
-Shahram

-----Original Message-----
From: Porotsky Sergey [mailto:[email-masked]]
Sent: Thursday, October 05, 2000 7:09 AM
To: [email-masked]'; [email-masked]; Porotsky Sergey
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments draft-ietf-mpls-recovery-frmwork-00.txt

	[Vishal] 

number and 

	The RSVP Tear-Down message itself may not reach the desired source,
if 
the 
routing tables haven't converged, so I am not sure that that would be a 
useful way to intimate the source. (Note that the FIS message uses 
a preconfigured reverse path, that does not depend on L3 routing 
tables.)