The MPLS WG Archive

[Der-Hwa Gan <dhg@juniper.net>]

> Sundara,
> 
> Thanks for the feedback.  Please see my inserted comments below.....
> 
> Cheers,
> Tricci
> 
> Sundara Murugan wrote:
> 
> > my comments are embedded.
> >
> > -----Original Message-----
> > From: Tricci So [mailto:tso@caspiannetworks.com]
> > Sent: Monday, January 07, 2002 3:23 PM
> > To: dhg@juniper.net
> > Cc: pingpan@juniper.net; mpls@UU.NET
> > 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.
> 
> [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 neede
d,
> isn't it?

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.

> 
> >
> > 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 ove
r
> > 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 the
y
> > can't be merged.
> 
> [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 al
l
> 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?

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.

> 
> >
> > 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 Protecte
d
> > 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.
> 
> [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 opt
ion
> to specify what are the bandwidth and administrative requirements to be for t
he
> Detour LSP so that no configuration is needed at each PLR to decide whether i
t
> needs to include the bandwidth or administrative info in the Detour Path mess
age
> 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....

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
> 
> >
> > Thanks in advance to your help......
> > Tricci
>