Re: RE : RE : RE : Last call comments: draft-ietf-tewg-interarea-mpls-te-req-01.txt

[Arthi Ayyangar <arthi@juniper.net>]

Hi JL,

Sorry for the delay in replying. Please see my answer below.

> And what about FRR: if I want FRR protection of ABRs with no impact on
> backup length and recovery delay, I definitely need contiguous LSPs.
> This is actually the only signaling mode allowing this service. Thus I
> prefer to signal directly the signaling mode "Contiguous LSP", rather
> than the required service, in order to avoid any misinterpretation of
> this service ...
----> I understand that you may want some control on the backup
path length. Even for intra-domain TE LSPs today, (which are contiguous),
depending on topology or constraints you may end up computing longer
paths than desired. So, in order to provide control on backup hops, one
probably specifies a constraint in backup path computation. Won't
specifying a similar constraint for inter-domain backup paths suffice ?
Ofcourse, the constraint may need to take into account forwarding hops
instead of control plane hops (aka RRO).

Also, I agree that with non-contiguous LSPs, you cannot merge back at
intermediate nodes between the FA-LSP or LSP segment end-points, that may
increase the number of forwarding nexthops for the backup. But, that is a
direct consequence of what any hierarchy does...information hiding.
However, even with contiguous LSPs, say for an inter-provider TE LSP
case, if the hops with the provider domain are not exposed via RRO (for
confidentiality reasons), you would still have the same issue. i.e.
you may need to merge back at the boundary node.

So, what I am trying to suggest is that these issues are not entirely tied
to a signaling method, (although there may be some which may be blatant with
one signaling method versus the other). So, instead of signaling the
method, we could solve the problem generically.

thanks,
-arthi