Subject: RE: Questions for FRR

From: Sundara Murugan <[email-masked]>
Date: Mon, 7 Jan 2002 19:10:06 -0800

my comments are embedded.

-----Original Message-----
From: Tricci So [mailto:[email-masked]]
Sent: Monday, January 07, 2002 3:23 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Questions for FRR 

Hi Der-Hwa and Ping,

After reviewing your draft in more details, I have the following questions
regarding the detour mechanism for FRR.  Hope you can help me to clarify a
few
things.  Thanks....

1. According to the latest draft, section 3.2.1, your recommend the use of
the
RSVP_HOP object to be included in the detour Path message.  Since the
SENDER_TEMPLATE, which contains the new sender's IP's address in the "IPv4
tunnel sender address", is also being used in the Path message, why the
RSVP_HOP
object is needed to carry the same information (i.e. PLR's IP addrss)?

>> Detour and the protected LSPs will have the same session and sender id.
Also the next-hop will send resv msg to the IP addr specified in the
RSVP_HOP oject. 

2. In section 3.2.2., you have a statement mentioned that the MP may
receieve
the Path message from different interfaces with the identical SESSION and
SENDER_TEMPLATE objects.  I don't see this would be possible except for the
case
of the software error.  It is because the SENDER_TEMPLATE should be coded
with
different LSP_IDs for the Protected and Detour LSPs for the same tunnel over
different interfaces.  This the design intent of using different LSP_IDs to
differentiate different instances of the LSPs for the same tunnel.  Am I
misunderstood your statement?

>> If the LSP_IDs of the protected and the detour lsp is different then they
can't be merged.

3. Somebody sent a previous email to suggest that the detour Path message
should
include the option to specify the requested LSP's bandwidth and
administrative
group constraint that is same as the Protected LSP, instead of locally
configuring these two options at each FRR capable LSR to adopt the Protected
LSP
requirements or not.  I happen to agree with his view.  What do think about
his
suggestion?

>>Since the detour lsp will be used only during reroute, the user may not
want to waste the band-width. So, the user will decide the bw allocated for
the detour lsp.

Thanks in advance to your help......
Tricci

---

From: Tricci So <[email-masked]>
Date: Tue, 08 Jan 2002 10:00:22 -0800

Sundara,

Thanks for the feedback.  Please see my inserted comments below.....

Cheers,
Tricci

> Also the next-hop will send resv msg to the IP addr specified in the

[Tricci] I am sorry that I don't agree.  The Detour and the Protected LSPs
should  NOT have the same sender id except for the case when the PLR is the
ingress LER.  In general, the PLR should include its IP address in the
SENDER_TEMPLATE.  To me, it does not make sense to have the PLR to initiate a
Detour LSP but to insert the ingress LER's IP address into the detour Path
message.  If my observation is correct, then the RSVP_HOP object is not needed,
isn't it?

> >> If the LSP_IDs of the protected and the detour lsp is different then they

[Tricci] There is already a Tunnel ID defined in the LSP_TUNNEL_IPv4_SESSION
object to be used to identify the tunnel (i.e. the Detour and Protected LSPs
would have the same Tunnel ID); and the merging can be done via the use of all
the info from the SESSION object.  Different LSP_ID should be used to
differentiate the Detour and the Protected LSPs.  How else can it be done to
differentiate the messages for the Detour and the Protected LSPs?  What am I
missing?

> want to waste the band-width. So, the user will decide the bw allocated for

[Tricci] I apologize for my mis-written of my previous question.  What I meat
was to have the original Path message of the Protected LSP to contain the option
to specify what are the bandwidth and administrative requirements to be for the
Detour LSP so that no configuration is needed at each PLR to decide whether it
needs to include the bandwidth or administrative info in the Detour Path message
or not.   The current draft implies that such encoding decision is configured
locally at each PLR.  Please check it out and let me know if I am wrong.
Thanks....

---

From: Der-Hwa Gan <[email-masked]>
Date: Tue, 08 Jan 2002 21:04:49 -0800

> message.  If my observation is correct, then the RSVP_HOP object is not neede
d,

RSVP_HOP object is a hop-by-hop information, to help downstream routers
sending Resv message (and others) upstream. It is always needed, and it
should reflect the current interface being used to transmit Path message.

As for the sender id in the detour, as specified in the current spec,
is the same id as protected LSP. This was intended as a necessary
condition for doing the merging procedure.

But the spec is being changed due to comments received at last IETF. It 
will be optional whether or not PLR modifies the sender id. On the MP,
it must perform merging procedure for LSPs with identical sender id.
As for LSPs with different sender id, merging becomes optional.

> differentiate the messages for the Detour and the Protected LSPs?  What am I

It is not necessary to use SENDER_TEMPLATE to differentiate Detour 
and Protected LSP.  The FAST_REROUTE/DETOUR objects already do the job for you.

> locally at each PLR.  Please check it out and let me know if I am wrong.

The requirements for detour are already contained in the FAST_REROUTE
object, which is configurable by user at ingress. The requirements do
include bw, administrative constraints, and others.

THanks,
Der-Hwa

---

From: Tricci So <[email-masked]>
Date: Wed, 09 Jan 2002 15:52:44 -0800

Der-Hwa,

Thank you for your responses.  However, somehow it seems I can't quite clearly
describe my questions to you and Sandara.  In order to make it easier for our
further discussion, let me rephase each question carefully to you.

1. In the latest draft, section 3.2, it indicates that the user of RSVP_HOP object
is needed for the "Detour" Path message.

My question is that why "hop-by-hop" info is needed for the "Detour" LSP especially
the RRO object will be returned in the Resv message.  I can see that it is needed
for the "Protected" LSP since each PLR needs to be awared of its neighbour. But I
don't know why it is needed for the Detour LSP.   I understand that the RSVP_HOP is
mandatory for a Path message for RSVP. But, is this the case for the RSVP-TE?

2. According to RFC 3209, you can use the LSP_TUNNEL_IPv4_SESSION to identify the
ingress and the egress LERs to uniquely identify the same LSP tunnel to support
merging;  and use the LSP_ID from the SENDER_TEMPLATE object to differentiate
instance of the LSP for a particular tunnel.

But in your FRR approach
(a) All PLRs encode the SENDER_TEMPLATE with the ingress LER's IP address instead
of the PLR's IP address to support merging
(b) Rather than using the LSP_ID, you use the Fast_reroute and Detour objects to
distinguish the Protected and Detour LSP requests.

(3) Finally, I am aware that the Detour Path message includes the bandwidth and the
administrative group info.  But, my question is that how to let each PLR know what
to encode in the bandwidth and administrative group objects (e.g. original
bandwidth for Protected LSP is 1 Gb, but the bandwidth for the Detour LSP is
degraded to 0.2 Gb)?   One way for PLR to know what the detour bandwidth to set to
or how to select the detour path as according to the administrative group info or
not is to configure each PLR locally.  The other way is to have the ingress LER to
specify such information in the beginning of the Path message of the Protected
LSP.   In fact, the latter approach make more sense since it is likely the ingress
LER would have the policy information of the Detour requirements.  Your current FRR
approach will require the policy to be distributed to all PLRs.

I hope that this time I make my questions more clear to you.  Thanks in advance to
your help:-o)

Tricci

---

From: Der-Hwa Gan <[email-masked]>
Date: Thu, 10 Jan 2002 13:19:00 -0800

> mandatory for a Path message for RSVP. But, is this the case for the RSVP-TE?

It is also mandatory for RSVP-TE, that is why Detours also need to have
RSVP_HOP. THe purpose of the statement in 3.2, is to make sure you don't 
just copy RSVP_HOP from Protected LSP to Detours, its contents need some
changes.

> instance of the LSP for a particular tunnel.

3209 did not mandate what value should be in the 'Extended Tunnel ID' field.
It will be risky to assume that 'Extended Tunnel ID' matchs that of LSP_ID
(in SENDER_TEMPLATE) for the Protected LSP.

> approach will require the policy to be distributed to all PLRs.

This information is encoded in FAST_REROUTE object by ingress, and distributed
to all PLRs via Path messages. There is no need to configure each PLR
separately, in the current design.

Thanks,
Der-Hwa