The MPLS WG Archive

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

> 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 especiall
y
> 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 i
s
> 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.

> 
> 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.

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.

> 
> 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 th
e
> 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 FR
R
> 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

> 
> I hope that this time I make my questions more clear to you.  Thanks in advance to
> your help:-o)
> 
> Tricci
> 
> 
> Der-Hwa Gan wrote:
> 
> > > 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
> > >
>