The MPLS WG Archive

[Omar.Elloumi@alcatel.fr]

Hi Alia,

some comments inline...

regards,

stefaan



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

     From: Alia Atlas <aatlas@avici.com>
     Date: Tue, 19 Mar 2002 20:02:35 -0500
     Cc: mpls@UU.NET, Scott Bradner <sob@harvard.edu>, George Swallow
<swallow@cisco.com>
     In-Reply-To:
<OF0E3D8343.E25CD357-ONC1256B81.00725873@netfr.alcatel.fr>
     X-Sender: aatlas@localhost


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?

[stefaan] Then you immediately see all the paths, how much labels are used,
how much bandwidth is reserved in the network without going to each PLR.
Without the BRRO/RRO you even do not see at each PLR how far the detour
goes before it merges.

 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.


[stefaan] In the DetourPathtable (which is only used at ingress), the first
entry of a list represting one detour is the address of the PLR. This means
that you see the PLR together with its detour/bypass. In the DetourTable,
each index for a detour is indeed just a number but that table is not
correlated to the BRRO.


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?


[stefaan] In this scenario, you see with the BRRO that the BERO was not
followed. BRRO is just for information purposes. Ingress LSR will not
take a particular action if it sees that BRRO and BERO does not match.
The primary path is also not modified in this case. In case of failures,
BERO
cannot be used, and the PLR will ignore the advise of the BERO. The ingress
could also take a 'corrective' action by specifying a better path for that
particular hop only. We will add some guidelines how to use these objects.



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.


[stefaan] In the SESSION_ATTRIBUTE, a flag is defined to indicate whether
or
not the BRRO should be used. It is recommended that the flag is switched
off as
soon as all PLRs have established their detour. Then the problem could be
that
the ingress does not see later reroutes of detours anymore (except if it
sets
the flag again from time to time). Maybe in a next version of the draft we
have to add a flag in the RRO that can be set by the PLR to inform the
ingress
that its detour has rerouted and then only changes in the routing are
advertized to the ingress without repeating everyting.
Note also that the BRRO only travels upstream such that there is only a lot
of
data in the PLRs close to the ingress.


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?


[stefaan] Good point. The length field of the BRRO subobject is indeed 1
byte
which is too short. We could either increase it to two bytes and remove the
prefix length and flags, or redefine the length to indicate the number of
subobjects. An alternative could be instead of using 1 big object
containing
the paths of all detour LSPs, it is better to define an object containing
the path of 1 detour and each PLR inserts such an object in the RESV
message. This results in multiple shorter objects. This results in the
following processing at the PLRs: the RRO of the detour at the PLR is put
into the RESV message of the protected LSP but then with the class number
set to the BRRO number + adding the PLRs address and removing unnecessary
RRO subobjects. I am wondering whether we still need the prefix length
(always 32 for Ipv4), length (always 8 for IPv4), flags,...
in the BRRO. By removing them, the size of the BRRO is divided by 2.



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


[stefaan] only the path has to be put in the BRRO (no label, bandwidth
ratio,..)
All other subobjects in the RRO may not be put in the BRRO. The draft
says in section 5.2 something about unrecognized BRRO subobjects. This
section
disappears when a BRRO contains only the path of a single detour as
described above.


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.

[stefaan] The use of a PCS is a possibility but it has some problems: if
each PLR contacts the PCS, there must be some mechanism to correlate all
these request from the PLR, and in addition when there are multiple PCSs,
all the PLRs must choose the same PCS. And of course, the PCS has to handle
multiple requests instead of 1 request.

Thanks for your comments,

Regards,

Stefaan






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, Omar.Elloumi@alcatel.fr wrote:
>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



     References:
          Follow up: draft-decnodder-mpls-ero-rro-fastreroute-00.txt
               From: Omar.Elloumi@alcatel.fr