The MPLS WG Archive

[Curtis Villamizar <curtis@workhorse.fictitious.org>]

In message <3FBA90B5.4050609@marconi.com>, David Charlap writes:
> Curtis Villamizar wrote:
> > 
> > First of all:  RSVP/TE != explicit-path
> > 
> > They are related but not equal.  RSVP/TE paths can be determined by
> > the ingress based on the CSPF computation.  Explicit-path means the
> > path is predetermined and fixed.  RSVP/TE supports explicit-path as an
> > option.  When determined by the CSPF (explicit-path is not being
> > used), the path is in a sense nailed down, at least until the
> > adaptivity timer fires and a later CSPF decides there is a better path
> > now.
> 
> RSVP-TE's definition of "explicit" can be rather fluid, depending on the 
> nature of the ERO object and how it is generated.
> 
> - An LSP may be signaled without an ERO object.  In which case, it 
> follows the IGP's route to the egress address.  The route table may be 
> populated by the result of CSPF, ECMP, or other mechanisms.  When the 
> route table changes, the LSP reroutes to follow it.  This is obviously 
> not in any way explicit.
> 
> - The path described by an ERO may terminate before the egress node is 
> reached, in which case the remaining hops are determined using the route 
> table and the egress address.  This is only explicit up to the end of 
> the ERO.
> 
> - An ERO object may contain loose hops.  The next-hop chosen in response 
> to a loose hop is a function of the routing table.  This is explicit in 
> the sense that the LSP will pass through certain nodes, but the route 
> taken between those nodes is not explicit.
> 
> - Since RSVP ERO hop addresses identify nodes, not links (except when 
> the GMPLS IF_ID/unnumbered HOP extensions are used), the local route 
> table is used to pick a link when multiple links exist between a pair of 
> nodes along the path.
> 
> - Finally, the ERO used by the ingress node may be manually generated by 
> an operator, or it may be computed by software external to RSVP.  If it 
> is computed, then the ERO-computation software may choose to generate a 
> new ERO and reroute the LSP as the network topology changes.  This is 
> explicit from RSVP's perspective, but not necessarily from the 
> operator's perspective.
> 
> RSVP's path is only fixed in the intuitive sense if an ERO consisting 
> entirely of strict subobjects is used, and these subobjects lead all the 
> way to the egress node, and the entity that computes the ERO (human or 
> software) chooses not to reroute the LSP as the network changes.
> 
> -- David


I was using the RFC2702 definition of explicit-path.

  5.6.1 Administratively Specified Explicit Paths

   An administratively specified explicit path for a traffic trunk is
   one which is configured through operator action. An administratively
   specified path can be completely specified or partially specified. A
   path is completely specified if all of the required hops between the
   endpoints are indicated. A path is partially specified if only a
   subset of intermediate hops are indicated. In this case, the
   underlying protocols are required to complete the path.  [... etc]

Note that the term explicit path is used *only* for this case at least
in RFC2702 and AFAIK is not redefined differently in any other RFC.

My statement still stands: RSVP/TE != explicit-path.  And the rest of
it remains true.  I neglected to mention that an explicit-path may
contain loose hops.

Your statement is also entirely correct.  I think we are going off
into detail on a tangent.  Just wanted to clarify where the definition
comes from and that it really does mean "configured" (which can
include SNMP - to fend off another possible tangient).

Curtis

btw - in case anyone thinks ECMP is some new requirement (also from
RFC2702, dated Sep 1999):

  5.6.5 Load Distribution Across Parallel Traffic Trunks

   Load distribution across multiple parallel traffic trunks between two
   nodes is an important consideration.  In many practical contexts, the
   aggregate traffic between two nodes may be such that no single link
   (hence no single path) can carry the load. However, the aggregate
   flow might be less than the maximum permissible flow across a "min-
   cut" that partitions the two nodes. In this case, the only feasible
   solution is to appropriately divide the aggregate traffic into sub-
   streams and route the sub-streams through multiple paths between the
   two nodes.