Re: RSVP-TE: specifying links in EROs

Tony Li wrote:
> 
> Please see RFC 791, page 24:
> 
> That is, there must be a mapping between internet host addresses and
> network/host interfaces that allows several internet addresses to
> correspond to one interface.
> 
> This implies that any single IP address corresponds to a subset of
> the interfaces on the router (typically only one).
> 
> The binding of an IP address to an interface has been argued to be an
> architectural misfeature, but it is certainly a long term accepted
> facet of the IP architecture.

This has nothing to do with MPLS or EROs.  The fact that interfaces are
numbered does not mean that an RSVP-TE ERO subobject is capable of
representing a single interface.

The only reference to link selection I've found is section 4.3.4.1 of
RFC 3209 ("Selection of the Next Hop").  It deals entirely with abstract
nodes:

     5) Interior of the Abstract Node Case: Otherwise, the node selects a
        next hop within the abstract node of the first subobject (which
        the node belongs to) that is along the path to the abstract node
        of the second subobject (which is the next abstract node). ...

Nothing in the ERO processing procedure mentions link selection at all.

Section 2.2  says:

     The EXPLICIT_ROUTE object specifies the route as a sequence
     of abstract nodes.

Section 4.3.3.2 defines the IPv4 prefix subobject as:

     ... The abstract node represented by this subobject is the set of
     nodes that have an IP address which lies within this prefix.
     Note that a prefix length of 32 indicates a single IPv4 node.

Again, it talks about nodes, not links.

The unnumbered-interface RFC (RFC 3477) doesn't change this:

     4.2. Processing the ERO

        The Unnumbered Interface ID subobject is defined to be a part
        of a particular abstract node if that node has the Router ID
        that is equal to the Router ID field in the subobject, and if
        the node has an (unnumbered) link or an (unnumbered) Forwarding
        Adjacency whose local identifier (from that node's point of
        view) is equal to the value carried in the Interface ID field
        of the subobject.

        With this in mind, the ERO processing in the presence of the
        Unnumbered Interface ID subobject follows the rules specified
        in section 4.3.4.1 of [RFC3209].

In other words, the new subobject type only creates a new way of 
identifying abstract nodes.  It does not change the ERO processing 
procedures at all, meaning there is still no link-selection procedure.

-- David