The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi Bora,

I have some comments on your draft.

Section 1:

           Specifically, ERO 
           definition for unnumbered interfaces is context sensitive and 
           dependent on the order of appearance in the ERO.

Note that the graph-theoretic definition of a path is an *ordered*
sequence of edges (or nodes).  What issue does the fact that the ERO
needs to be ordered raise?  Do you suppose that the EERO format that
you propose does not dependent on the order of appearance?

           For example, if 
           the same interface identifier is repeated twice in the ERO 
           consecutively, the desired behavior is unclear.

Actually, the desired behaviour is quite clear; if an ERO consists of
<1, 1, 1, 1, 1, 1>, then the path is quite explicit: take interface #1
from the ingress; then take interface #1 from the next hop; then take
interface #1 from the next hop, etc. until you reach the egress.  The
fact that all the interfaces are numbered 1 is wholly irrelevant; each
hop is in a different numbering scope.  (Note that unnumbered interfaces
are always *strict* hops.)

        c. Different styles of specifying the ERO in different 
           implementations. [RSVP-TE] gives the head-end LSR considerable 
           leeway in specifying the ERO. For example, an LSR that is on the 
           path can be specified by a router ID, an ingress (w.r.t. to the 
           LSP) interface ID (usually an IP address), an egress interface ID 
           or any combination of the above. This "flexibility" may cause LSP 
           establishment and interoperability failures. 

These "issues" are easily solved (and are solved in practice).  A BCP
that describes one style for ERO specification *without* protocol
changes would be a better solution (IMHO) than an entirely new ERO
format that contains twice redundant information.

Section 2: Ingress Interface Identifier & Egress Interface Identifier 

For a given link, the ingress and egress interface indices are assigned
by different routers.  This means that the scopes are under different
router IDs.  The draft contradicts that.  Can you clarify?

By the way, the idea of adding a router ID to unnumbered interface
objects was discussed on the MPLS mailing list several months ago and
discarded as unnecessary.

In any case, what is the value of the router ID when the ingress/egress
interface identifiers are IPv4 addresses?

Also, loose hops should probably not have any associated interfaces.
I'm not sure what it means to have unnumbered interface indices with
loose hops.  Unfortunately, I cannot make out the use of interface IDs
in the context of loose hops from the description in section 3.

Section 3: ERO processing

There are actually eight cases: with/without EERO-HOPs, with/without
AN-HOPs, with/without LR-HOPs.  I fail to see how this classification
helps, though.  You seem to assume that LR-HOPs cannot be interspersed
with EERO-HOPs, and that EERO-HOPs must be present.  Is that what you
meant?

IMO the stated goal of "simplification of abstract node and loose route
processing" has not been achieved.  It may well be that ERO processing
should be reworded; if so, the goal should not be to use fewer words,
but rather to achieve greater clarity.  Of course, the current semantics
should be maintained.

Kireeti.