Re: RSVP-TE: specifying links in EROs

David,

I remain a bit puzzled as to why this conversation is happening on the
mailing list of a defunct working group.

Nevertheless, you might benefit from reading around the topic a bit. A lot
can be deduced about the interpretation of RFC3209 from reading RFC3473.
Have a look at interface identification or at label subobjects.

Cheers,
Adrian
----- Original Message ----- 
From: "David Charlap" <[email protected]>
To: "IETF TE-WG List" <[email protected]>
Sent: Wednesday, November 30, 2005 11:51 PM
Subject: 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
>
>
>