The MPLS WG Archive

[sven.van_den_bosch@alcatel.be]

I have added some additional comments to my original mail. Do you think
these issues should be considered during the final revision of the
document?

Thanks,
Sven.

---------------------- Forwarded by Sven VAN DEN BOSCH/BE/ALCATEL on
22/01/2002 14:01 ---------------------------


Sven VAN DEN BOSCH
18/01/2002 09:57

To:   Yakov Rekhter <yakov@juniper.net>
cc:
Subject:  Re: last call on hierarchy  (Document link: Sven VAN DEN BOSCH)

Yakov,

Thanks for your reply. Please see my additional comments marked Sven>>



Yakov Rekhter <yakov@juniper.net> on 17/01/2002 19:57:49
                                                              
                                                              
                                                              
  To:          Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL          
                                                              
  cc:          mpls@UU.NET                                    
                                                              
                                                              
                                                              
  Subject      Re: last call on hierarchy                     
  :                                                           
                                                              





Sven,

> Hi,
>
> I would like to clarify two questions regarding the hierarchy draft that
is
> currently on last call:
>
> 1. Dynamic recomputation of the path of the FA-LSP
>
> If I understand correctly, the path information regarding the FA-LSP is
> made available to other nodes by means of the PATH TLV.

Correct.

> This information may be used by other nodes for their own path
computations.

Correct.

> They could for instance take it into account when computing a backup
path.

Correct.

> Then if the FA-LSP changes path, primary and backup path of the client
> LSPs may no longer be disjoint.

Correct.

> My proposal would be to foresee the possibility to restrict the
> reroutability of the FA-LSP and advertise this in the PATH-TLV. In this
> way, nodes that use this information would know whether it is subject to
> change or not.

There may be (at least) two reasons why the FA-LSP gets re-routed:

(1) the current path taken by FA-LSP becomes unfeasible (e.g., one
of the links along the path went down)

Sven>> I think this argument maybe applies less in the specific example I
gave. When the FA-LSP is rerouted as a result of a failure it can be
regarded by the client LSPs as a link that "cannot fail". In this case any
protection mechanism on the client LSPs should probably not be triggered
and the protection path wouldn't have to be disjoint from the path taken by
the FA-LSP.

(2) there is a "better" path, so FA-LSP is re-routed as part of
optimization.

Do you want to restrict re-routability in both cases ? Or only
in the second one ?

Sven>> You are of course completely right. I should have used more careful
wording. I will try again. I would propose the possibility to restrict the
reroutability of the *primary* path of the FA-LSP and advertise this in the
PATH-TLV. It would leave the decision on whether to reroute for optimality
or not to operator policy but it would allow an LSP that could be impacted
by rerouting the choice not to use the FA-LSP. It can do this when it knows
whether or not the FA-LSP is subject to rerouting.

Sven>> Things brings up another question:Is it possible to use the exact
same ERO hop sequence as the FA-LSP but still not use the FA-LSP (supposing
you want to use the FA-LSP for some LSPs and not for others)?

> 2. Automatic setup of FA-LSP
>
> The draft says "Otherwise (if no existing FA-LSP is found), the LSR sets
up
> a new FA-LSP.  That is, it initiates a new LSP setup just for the
FA-LSP."
> I would like to clarify what happens when two FA-LSPs exist that, when
> concatenated, can replace the new FA-LSP that is proposed to be set up in
> the quoted text.
>
> I would propose to say that the LSR may set up a new FA-LSP or
> alternatively, it may replace the hop by a sequence of hops for which FAs
> are available.

that would be ok, *provided* that the the strict hop subsequence
from the ERO carried by the new LSP matches the one resulted from
the concatenation of several FA-LSPs. Agreed ?

Sven>> In the case that you describe I definitely agree. But I also saw
another case where it is a loose hop over a region. In this case, instead
of setting up a new FA-LSP you might want to use two existing FA-LSPs.
Then, when there is no FA-LSP to the destination edge of the region instead
of making a new one you would need the freedom to expand the ERO using an
intermediate node (another edge of the region which has a FA-LSP with both
edges in the original ERO). I tried to make a drawing below. I am not sure
the last situation ("desired") is allowed by the draft.

input: explicit route A-B-C-D

current network situation:
                           A----B              C----D
                                 \            /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

new situation according to draft (there is no FA-LSP from B to C):
                           A----B--------------C----D
                                 \    FA3     /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

desired new situation: expand ERO to A-B-X-C-D and leave network as is
                           A----B              C----D
                                 \            /
                              FA1 \          / FA2
                                   \        /
                                     ---X---

Sven.



Yakov.