Subject: RE: draft-gan-fast-reroute

From: Sundara Murugan <[email-masked]>
Date: Fri, 12 Oct 2001 11:54:26 -0700

When establishing the detour LSP, the MTU size must not be lower than its
main LSP. The Main LSP's MTU is specified in the RESV flow spec.

When the main LSP traffic is diverted to the detour LSP, there is no need
for fragmentation. Also, the main lsp will update its RESV RRO "local
protection in-use" flag and send it to the headend.

This informs the headend that it has to recompute the path for the main lsp
and reestablish it.

The failed main LSP will not get any RESV refresh from the nhop. When its
refresh timesout the transit router will send PATHERR to the headend and
that takes down the main as well as the detour LSP.

-sundara

-----Original Message-----
From: Arthi Ayyangar
To: [email-masked]
Cc: Alia Atlas; [email-masked]
Sent: 10/12/01 9:23 AM
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