The MPLS WG Archive

[Eric Gray <eric.gray@sandburst.com>]

David,

    Let me do a little constructive reasoning.

    IF it is not possible to create an LSP from R2 forward that
- even closely - matches LSP(s) we are going to consider
terminating at R2, then there will necessarily be some degree
of complexity associated with both the process of determining
what sets of LSPs to signal (to R2 and beyond R2) and the
process of mapping data arriving on an LSP to R2 onto an LSP
going forward from R2.

    There will definitely be zero or more traffic streams to which
this will apply in any case.

    Let's assume that for one or more traffic streams, however,
there is a simple mapping of data arriving on an LSP to R2 to
an LSP going forward from R2.  Let's call the arriving LSP,
LSP-A and the departing LSP LSP-A'.  If this is the case,
then it is very likely the case that requirements for forwarding
packets on LSP-A are a subset of requirements for packet
forwarding on LSP-A' since - if this is not the case - packet
forwarding resources associated with LSP-A will have been
needlessly expended since the same resource commitment
does not exist for LSP-A'.  Similarly, the reverse is true: if
resources are committed for LSP-A' and not for LSP-A.  As
near as I can tell, this applies generally to all kinds of resources
- including built in fault-tolerance, queuing behavior, etc.

    This being the case, then R2 should not commit resources
for LSP-A until it is known that it can create LSP-A' or can
otherwise ensure that packets will obtain similar consideration
and treatment going forward from R2.

    In my mind, that implies that R2 should signal to obtain LSP-A'
prior to "granting" LSP-A.  Not only does this compare closely
to "tranlation" of the signaling message, but it also preserves the
"ordered control" mode common to both RSVP-TE and CR-LDP.

    Moreover, the example given was deliberatly simplistic.  How
will either RSVP-TE or CR-LDP satisfy an explicit routing for
an LSP if the egress is not within the same signaling domain?  It
would be a lot simpler for the user if they can setup LSPs across
multiple signaling domains within their administrative domain -
as opposed to having to treat each signaling domain as if it is
also an administrative domain.

    Finally, in following the development of both RSVP-TE and
CR-LDP, one thing I can definitely say is that a lot of effort
has gone into making sure that there was very little you could
do (in terms of providing a service) with one protocol that you
could not also do with the other.  I think I would focus on the
types of services that you can provide with either or both - this
being a larger number than the kinds of services you cannot.

    Please see embedded comments below.

--
Eric Gray

You wrote:

Eric Gray wrote:
>
>     Hmmm.  There is the interworking scenario:
>
>   --- R1 --- R2 --- R3 ---
>
> in which R1 only "speaks" CR-LDP/LDP and R3 only speaks RSVP-TE (and
> maybe LDP).  In this scenario, it is quite reasonable for R2 to
> "translate" between the two protocols for LSP set-up.

Would you want to have R2 translate one signalling protocol to another?
This seems unmanagable and needlessly complicated.

In most cases, there are some very simple and - in many cases -
fairly obvious mappings form the objects in one protocol to the
analog objects in the other.  These mappings require very little
in the way of configuration (defaults will work in most cases)
- especially in comparison with the management effort I would
think would be associated with seperate LSP setup.
>  
> In this scenario, I think it would make more sense to use LDP to signal
> an LSP that terminates on R2.  R2 can then signal a different
> LSP that
> goes through R3 to the edge of the MPLS cloud.  R2 can then configure
> itself to forward packets between the two LSPs.
In some (zero or more) cases, this may be necessary. In theory, this
couldbe necessary for all LSPs.  For example, in the case where
the
signaling domain coincides with an administrative domain or "trust"
boundary.  Where the mapping of forwarding requirements is 1:1,
however, the semantic difference between an approach that uses
translation of singaling and one that does not is nil.

 

While the effect is the same, the mechanism is different.  It avoids a
few nasty problems that would result from the differences in the
protocols:

- RSVP-TE uses a different QoS representation from CR-LDP

Most of the objects associated with QoS in CR-LDP were lifted
bodily from RSVP-TE and the resemblence is striking.
>  
> - RSVP-TE explicltly LSPs from a known ingress router to a known
>   egress router.  LDP distributes labels without a firm concept
> of an
>   LSP during the signalling.  CR-LDP appears to be like LDP
> in this
>   respect, although the presence of an explicit route mitigates
> the
>   difference somewhat.
CR-LDP includes Explicit Routing using mechanisms and objects
that are very nearly identical to the objects included in RSVP-TE
(this time, both efforts "borrowed" from the same bank).
>  
> - There is no LDP or CR-LDP way to signal multiple LSPs that share
>   resources.  (RSVP's "SE" reservation style)
CR-LDP accomplishes this using LSP-ID.
>  
> These problems can all be worked around, of course, but it they can
> be
> avoided altogether if the routers create two LSPs, connected at R2
> intead of trying to signal one LSP with two protocols.
As near as I can tell, the means to resolve the above "issues" are
available natively in both RSVP-TE and CR-LDP.  Work-arounds
are not needed.

 
> Also, there is very little difference between setting up a single LSP
> through (for example) R2 above and terminating one LSP (from R1, for
> instance), making a new LSP (toward R3) and connecting them
> internally (at R2) - as long as the mapping (might be a FEC) is
> one-to-one from one LSP to the other.

In the data plane, there is no difference.  But the setup procedures
will be different.  IMO, the two-connected-LSP method will be simpler.

-- David

--
Eric Gray