Subject: RE: Interworking between CR-LDP and RSVP-TE

From: "Pour, Mort" <[email-masked]>
Date: Fri, 17 Aug 2001 14:22:38 -0500

Thanks Eric. 
I see your point about the need to extend one protocol (the one we are
mapping
messages to) to prevent information loss. For example in the case of
RSVP-TE -> CR-LDP we need to extend CR-LDP. Then in case 2 (CR-LDP ->
RSVP-TE) and 3
we would need to extend RSVP-TE. This is not done in the draft but yet it
claims to cover those cases. 

If those cases are covered, then, it seems to me, case 4 must also be
covered. 
It is still not clear to me.

On the point about obsoleteness, it seems that some vendors are supporting
RSVP-TE
and some others CR-LDP. If that is the case, won't interoperability become
an issue?

Thanks
Mort

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]
Sent: Friday, August 17, 2001 1:40 PM
To: Pour, Mort
Cc: [email-masked]'
Subject: Re: Interworking between CR-LDP and RSVP-TE

Mort,

    This draft was allowed to expire by its authors.  It expired almost a
year
ago, and it is possible that people do not feel it is worth continuing this
work.  On this score, I don't know.

    However, the intent of the draft is captured in its title - "CR-LDP
Extensions for Interworking with RSVP-TE".  Note that it does not seem
to propose RSVP-TE extensions for interworking with CR-LDP.

    The draft also states that scenarios 1 and 2 are mutually exclusive.
This
makes sense, because these scenarios are intended to describe entire LSPs.
In the first two cases, the LSP starts with one protocol and ends with
another. In the last two cases, the LSP starts and ends with the same
protocol but traverses some non-zero number of LSRs using the other
protocol.

    From these facts, one might imagine that the authors felt that
information
may be lost in transforming LSP-related transactions from one protocol to
another and - by proposing extensions to one of those protocols - authors
hoped to eliminate this loss of information in the case where that protocol
was in use between instances of the other protocol.  If information loss is
the concern, then scenario 4 would require extensions to RSVP-TE for the
purpose of preventing information loss when RSVP-TE is in use between
instances of CR-LDP.

    Hopefully, this answers your question.

--
Eric Gray

You wrote:

> Hi,
> I have a question regarding draft write-mpls-crldp-rsvpte-iw-00.txt on
> interworking LSRs
> supporting CR-LDP and RSVP-TE.
>
> The draft gives four network scenarios, namely
> 1- RSVP-TE -> CR-LDP
> 2- CR-LDP -> RSVP-TE
> 3- RSVP-TE -> CR-LDP -> RSVP-TE
> 4- CR-LDP -> RSVP-TE -> CR-LDP
>
> and states that scenarios 1, 2 and 3 are covered by this draft, but not 4.
> If the ingress LSR can support case 2 and the egress case 1, with RSVP-TE
> supported in between,
> don't we get case 4? What am I missing?
>
> Thanks
> Mort