Subject: Follow up: draft-decnodder-mpls-ero-rro-fastreroute-00.txt

From: [email-masked]
Date: Tue, 19 Mar 2002 22:36:19 +0100

As regards draft: draft-decnodder-mpls-ero-rro-fastreroute-00.txt
presented today in the MPLS WG
we definitely believe this falls under the MPLS WG charter Point 6
"6. Specify MPLS-specific recovery mechanisms to allow one label-switched
path to be used as backup for a set of other label-switched paths,
including cases which permit local repair. What constitutes the necessary
set of MPLS-specific recovery mechanism should be ascertained through
cooperation with the CCAMP and TE working groups."

So just like the fast reroute I-D
(draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt),
draft-decnodder-mpls-ero-rro-fastreroute-00.txt is an extension to it.

Please also mention that the draft suggests the use of optional
RSVP objects and as such it is *fully backward compatible* with
the current proposal for fast reroute
(draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt).

We believe that this solution improves both bandwidth reservation
for detour LSPs and the scalability by providing a more deterministic
approach implying that detour LSPs merge faster with each-other
(consequently RSVP signalling refreshes are reduced as a result of
reducing the number of detour LSPs).

We kindly ask the MPLS WG community to provide their feedback
(be it positive or negative) on this effort to the list. The draft is
available from:

http://search.ietf.org/internet-drafts/draft-decnodder-mpls-ero-rro-fastreroute-00.txt

S. De Cnodder & O. Elloumi

---

From: Alia Atlas <[email-masked]>
Date: Tue, 19 Mar 2002 20:02:35 -0500

I have a few comments on the BERO and BRRO suggested.

First, the idea of a Backup Record Route Object seems appealing from a 
manageability perspective, but how/why is the information actually required 
at the ingress?  I know that the way the proposed MIB is designed, each 
detour is assigned an arbitrary index, unrelated to the PLR - but that 
assumption seems like it could be removed.

You suggested that the BRRO could be used to verify whether the BEROs were 
followed.  To what purpose would the ingress due this verification?  Would 
it decide to use a different primary path instead?  Would it not bother to 
compute the BERO for any LSPs going through the PLR which didn't follow the 
BERO?  How would it correlate such decisions with potential failures upon 
the recommended BERO between the time the Path message was sent and the 
backup path computed?

Basically, I agree with what George said in the meeting.  It'd be 
theoretically nice to have all the information in one place (ingress), but 
it is a lot of data to haul around.

Incidentally, related to that detail of "a lot of data to haul around", I 
also have some comments/questions about the format, for instance of the BRRO.
Specifically, the length field in the SubObjects for the BRRO are both 8 
bits long (for IPv4 and IPv6).  I don't have the exact byte count for an 
RRO's sub-object... but I don't think that you're going to fit very many 
into the BRRO's sub-object, particularly for the IPv6 case.   How much data 
are we discussing sending back to the ingress here?

A related detail is which sub-objects in the RRO should be copied into the 
BRRO.  Do you need to keep a label record sub-object, if it was 
included?  Presumably, the bandwidth sub-object wouldn't appear, but what 
criteria for future sub-objects would be applied?  The draft simply says 
that unknown ones should be ignored and passed on...

For the Backup Explicit Route Object, what function is served that couldn't 
be served by a Path Computation Server?  This seems to have shifted 
substantial load to the ingress and created extra.  Not only must the PLR 
keep track of whether the detour it has set up goes down, so it can 
immediately set up a new detour path, but the ingress must ALSO do so, so 
it can compute and send an alternate path to maintain whatever "goodness" 
it is adding by doing the computation at one location.

Additionally, the BERO requires a sub-object for each PLR which is to set 
up a detour.  Even if the ingress were to decide that whatever BERO it 
suggests would be ignored by the PLR, the ingress must still include that 
PLR in the BERO....

I do like the idea of imposing more control over the backup paths, but I'm 
not convinced that this is the way to do so, or that any requirements to do 
so have solidified sufficiently based upon experience with the current 
fast-reroute draft.

Alia

At 10:36 PM 3/19/02 +0100, [email-masked] wrote:
>we definitely
>  believe this falls under the MPLS WG charter Point 6