The MPLS WG Archive

["Don Fedyk" <dwfedyk@nortelnetworks.com>]

Title: RE: CR-LDP doubts

Vijay and Katta

Please see comments below.
> -----Original Message-----
> From: Vijayanand C - CTD, Chennai. [mailto:vijayc@ctd.hcltech.com]
> Subject: RE: CR-LDP doubts
>
> Katta,
>
> See my comments in line.
> Please correct me if I am wrong.
>
> Regards,
> Vijay
>
> -----Original Message-----
> From: Katta Sambasiva Rao [mailto:KattaSR@netbrahma.com]
> Sent: Friday, September 21, 2001 10:54 AM
> To: 'mpls@uu.net'
> Subject: CR-LDP doubts
>
>
> Hi,
> I have some doubts about CR-LDP.
>
> 1. Suppose a CRLSP is setup with no-pin option and  LSR-A is
> part of LSP as
> loose hop member.
> When LSR-A finds better nexthop, it is supposed to taer down
> LSP along old
> path  and send label request to new nexthop. For this, LSR-A
> has to store
> all the TLVs it received in CRLSP initiation request so that
> it can initiate
> request along new nexthop. Does not it imply that CR-LDP is
> not scalable?
This is not a scalability issue but a simple engineering issue,
no-pinning with a CR-LDP loose hop is an unlikely scenario.
No pinning is most appropriate with LDP.

>
> 2. We need to maintain state-inforamtion like LSP id and
> other CRLDP TLVs of
> CRLSP in all  LSRs to support LSP updation. With more ingress
> routers and
> more LSPs getting added to MPLS domain, support for updation
> of LSP seems to
> be not scalable. Is my view correct?
>
> Vijay >> Yes. I agree with your view.

This applies to any constraint based path setup protocol,
RSVP-TE and CR-LDP equally.

>
> 3. When a pinned LSP is pre-empted by high priority LSP
> request, should it
> be re-routed or should be teared down?
>
> Vijay >> I think if you have CSPF running then you can try re-routing
That depends on the implementation. Pre-emption forces the lower
LSP to reroute. The LSPs action on being pre-empted depends on how
the LSP to behave. Again this issue applies to all constraint
based signaling protocols.

>
> 4. What is the criteria for preemption Suppose there are two LSPs
> established with out-interface as interface 2 and hold
> priority of LSPs is
> same. Now I need to preempt one of them to setup new high
> priority LSP. What
> is the procedure for tie breaking. Shall I preempt the one
> that gives me
> required bandwidth or preempt both.
This is a implementation detail for any protocol doing pre-emption.

>
> If there are lots of LSPs going out through interface 2 with
> same priority
> but with different bandwidth reservations, deciding which
> LSP(s) should be
> pre-empted seems to be a complex issue. If this is done in
> propritary way,
> the setup and preemption of LSPs may not occur in predictable way.
>
> I think a standard algorithm is required for this decision instead of
> everyone doing their own arithmatic in different ways.

You have to decide why you are doing pre-emption. Usually it is in
the event of lost resources therefore logically you start at the
lowest holding priority and release resources as necessary. Providing
an algorithmic way to do this within a priority rather than random would
tend to favor some LSPs over others within a priority. That is
not usually the main goal.
>
> Vijay >> I don't see why you should preempt both. I think it
> is sufficient
> to preempt
> the one which just releases the required bandwidth. If you plan to do
> rerouting on the
> preempted LSP then that also has to be considered.
>
> 5. Is CRLDP draft intended for specifying only encoding of TLVs and a
> different draft/RFC is expected about complete CRLDP
> functionality as the
> currect draft does not seem to address many critical and
> general issues.

There are drafts on modification, feedback and LSP query. These
concepts are applicable to both RSVP-TE and CR-LDP. What you
are asking for is really some of the procedures that address the
TE requirements of RFC 2702. There is ongoing work in the
TE group to address some of these issues.

>
> 6. CRLDP draft has expired. Is it going to be revised.

CR-LDP draft is in the IESG queue for RFC approval.

>
> Vijay >> I fully agree with you that there are a lot
> unaddressed issues in
> the draft. We have
> raised many issues related to CR LDP  which have not been
> addressed in the
> draft.
> In this context, people have even asked whether 'CR LDP is
> dead', since the
> draft has not been updated and it is has been given secondary
> treatment
> probably because RSVP-TE is preferred by the giants.

The issues you point out are mostly not specific to CR-LDP but
involve constraint based routing in general.

Regards,
Don