Subject: Re: draft-gan-fast-reroute

From: [email-masked]
Date: Fri, 12 Oct 2001 20:27:11 +0200

Hi Arthi,

I agree that the approach you suggest, works and is a possible way of 
organising the control plane. However, I do not think that it is mandatory 
to enforce a relation between the contents of the RESV of the detour [node 
2 - node 4] and the RESV of the main LSP on link [node 2 - node 1]. After 
all, it is possible to keep refreshing the RESV of the main LSP on link 
[node 2 - node 1] with the contents the RESV had before the link [node 2 - 
node 3] failed. Doing this, implies that the changes of the detour's RESV 
message contents (e.g. its RRO) would not be propagated upstream in the 
RESV of the main LSP towards node 1.

Best regards,

        Francis.

---------------------------

To:
Francis ARTS/BE/ALCATEL@ALCATEL
cc:
Alia Atlas <[email-masked]>, [email-masked]

Subject:
Re: draft-gan-fast-reroute

Hi,

That para also says that "When it receives Resv, ResvTear and PathErr
messages from the downstream detour destination, the messages MUST not be
forwarded upstream."

But all this holds only when both the primary path and the detour are
active. Once the primary path is gone because of that link going down, you
would have to send the Resv coming along the detour path upstream,
otherwise how are you going to maintain the LSP up on the detour?
Which is why the RRO is also going to change!

thanks,
-arthi

Arthi, Alias,

* When reading the gan-draft, I assumed that node 2 would send [@(2-1),
@(3-2), @(4-3), @(egress-4)]. I deduced this from the statement on p.10
(2nd paragraph) of the draft saying that <<the branching node MUST not mix
the messages for the main and the detour LSP's>>.

* A similar question as for the RRO shows up for the path MTU: Which path
MTU does node 2 send in the RESV to node 1 after the detour [node 2 - node
4] has taken over: The path MTU of [node 1 - node 2 - node 3 - node 4 -
egress] or the path MTU of [node 1 - node 2 - detour (node 2, node 4) -
egress]?

In order to avoid fragmentation in the middle of the lsp, it is preferable
to pass the path MTU of [node 1 - node 2 - detour (node 2, node 4) -
egress].

In order to answer all these questions (and new similar questions that may
show up), we need to look at the general question: How do the signalling
contexts of the main LSP and the detour LSP interact once the detour LSP
has taken over?

Regards,

        Francis.

-------------------

To:
Arthi Ayyangar <[email-masked]>
cc:
Francis ARTS/BE/ALCATEL@ALCATEL, [email-masked]

Subject:
Re: draft-gan-fast-reroute

At 06:40 PM 10/11/01 -0400, Arthi Ayyangar wrote:
>Hi,
>
>>
>> I have a question on the RRO handling in <draft-gan-fast-reroute>.
>>
>>        Node1 ====> Node2 ======> Node3 =====> Node4 ======> Egress
>>                       v                       ^
>>                       |                       |
>>                       +-----------------------+
>>
>> Notation: @(3-2) == IP address of node 3 on the link [node 3 - node 2].
>>
>> Assume that the link between node 2 and node 3 fails. Then the detour
>> [node 2 - node 4] is taking over. But what does node 2 then send in the
>> RRO object of the RESV message to node 1: Does node 2 continue to send
>> [@(2-1), @(3-2), @(4-3), @(egress-4)] or does node 2 send [@(2-1),
>> @(detour between 4-2), @(egress-4)] or ...?
>>
>---> It would send , [@(2-1), @(detour between 4-2), @(egress-4)]
>as the RRO in the Resv once the detour has taken over.

No, the RRO in the RESV for the Primary LSP would not change.  Node 2
would
continue to send the same RRO as before the failure.

If you look at lsp-tunnel-09.txt, there is a "local protection in-use"
flag
which could be set in the IPv4 subobject of the RRO, but the
implementation
of draft-gan with which I am familiar doesn't do this.

Alia