Subject: Re: RSVP-TE: specifying links in EROs

From: David Charlap <[email-masked]>
Date: Wed, 30 Nov 2005 12:11:23 -0500

It would appear that I didn't phrase my original question clearly 
enough, given the nature of several responses I've received so far. 
Hopefully this will be better:

Suppose there are two routers with three links between them

       _________            _________
      |        A|----------|B        |
      |   R1   C|----------|D   R2   |
   ---|G       E|----------|F       H|----
      |_________|          |_________|

All of the interfaces have IDs (A-H).  These IDs may be IP addresses 
(numbered links) or they may be IF-IDs (unnumbered links).  Either way, 
they can all be uniquely identified.

If this would be an ATM network, it would be possible to signal a 
virtual circuit with or without specifying a particular link.  The DTL 
object (ATM equivalent of an ERO) can specify just node IDs, or it can 
specify port IDs as well.  If port IDs are specified, then the VC will 
be established over the link corresponding to that port.

What I can't find is some way of providing similar functionality in the 
MPLS world.

Clearly, if R1 and R2 are routable addresses acting as router IDs, and I
specify them in an ERO (R1, R2, ...), RSVP (running in R1) is free to
select any of the three links using whatever local criterial it
considers appropriate.

Suppose, however, that the ERO instead consists of ingress interface
addresses (G, B, ...) or of egress interface addresses (A, H, ...) or
perhaps even both (G, A, B, H, ...).  In these cases, has the ERO
specified that the LSP should be created over the A-B link?  Or are
these examples no different from the case of using router addresses?

My reading of the RFCs indicates the latter.  That no matter what
addresses you use in the ERO, you are only specifying nodes, and that
there is no way to specify the links.

There is nothing to prohibit RSVP from using interface addresses/IDs 
specified in ERO subobjects as an interface/link-selection mechanism.  I 
would even consider this a good practice.  But I also don't see anything 
in an RFC that could guarantee this behavior.

If there is an RFC-standard mechanism for specifying individual links, 
could someone post a reference to it?

If this is nothing more than a common practice, it would be nice to know 
it based on more than just my (almost certainly incomplete) reading of 
the RFCs.

-- David

---

From: Tony Li <[email-masked]>
Date: Wed, 30 Nov 2005 11:28:36 -0800

> Suppose there are two routers with three links between them

Yes, if the ERO contains interface addresses, that specifies the  
interfaces
to be used.

Tony

---

From: David Charlap <[email-masked]>
Date: Wed, 30 Nov 2005 15:11:31 -0500

Tony Li wrote:
> interfaces to be used.

Could you point out the section of the RFC where this is stated?

As I wrote, this behavior seems to be a common practice, but I can't 
find any document that mandates this behavior.

-- David

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 30 Nov 2005 20:47:19 -0000

David,

Tony is right (again).

You may want to take your discussion to the CCAMP WG where an I-D of what
addresses to use when in MPLS-TE/GMPLS is being put together based on
interop experience. The I-D covers EROs. It is still up for discussion.

Cheers,
Adrian

---

From: Tony Li <[email-masked]>
Date: Wed, 30 Nov 2005 15:16:08 -0800

> As I wrote, this behavior seems to be a common practice, but I  
> can't find any document that mandates this behavior.

David,

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.

Tony

---

From: David Charlap <[email-masked]>
Date: Wed, 30 Nov 2005 18:51:46 -0500

Tony Li wrote:
> That is, there must be a mapping between internet host addresses and
> the interfaces on the router (typically only one).
> 
> 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

---

From: Tony Li <[email-masked]>
Date: Wed, 30 Nov 2005 16:52:06 -0800

David,

> representing a single interface.

I'm unsure of the point that you're trying to make.  The semantics of  
the ERO
has been clear to numerous implementors along the way, as you yourself
have noted.  Simply put, if the path does not traverse the link  
specified by the
IP address, then it has not traversed the appropriate abstract node.

If you're arguing that the wording of the RFC could be clearer, I'll  
grant you
that, but it's a bit late as we don't revise issued RFCs.

If you're not looking for a clarification, I'm not sure how we can  
help you.

Regards,
Tony

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Dec 2005 01:02:35 -0000

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