The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

Also, how do you do fast reroute with unnumbered interfaces when 
there is no router ID associated with an ifindex?

Thanks

Bora

At 8:45 AM -0800 2/26/01, Bora Akyol wrote:
>Kireeti
>
>Thank you for your comments. The fact that you suggested that a draft
>without defining a new object but explicitly defining behaviors on ERO
>generation and processing leads me to believe that you recognize the
>problem that we are trying to address. I still think a new object is
>necessary however. Please see my comments within:
>
>
>  On Mon, 26 Feb 2001, Kireeti Kompella wrote:
>
>>  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?
>>
>
>It does depend on the order of appearance but we clearly wanted to make
>the case you listed below impossible:
>
>>             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.)
>>
>
>What you are assuming here is that there is one ERO hop for each hop,
>however, the RSVP-TE draft allows a hop to be specified by any combination
>of interface identifiers and router ID. I recognize the point that you are
>making but I think that it is advantageous to make things as clear as they
>can be. The EERO that we define achieves this clarity.
>
>  >         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.
>  >
>
>I know that these issues are solved in practice, I know that our
>implementation solves these issues as well. One of my main motivations for
>this draft was to stop other implementors from making different
>assumptions and achieve maximal interoperability. We are still in the
>earlier stages of deployment for MPLS and as more and more edge devices
>come on-line, we will see more interoperability problems. The EERO object
>that we defined prevents interoperability problems since it is very strict
>in its definition.
>
>
>>  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?
>
>Kireeti, what we meant here is:
>
>The ingress and the egress interfaces through the same router. Think of
>threading a needle where the router is the needle. You come in through
>interface A and leave through interface B and both A & B belong to the
>same router.
>
>
>>  > 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.
>
>I know, I was part of the discussion, but I don't recall anyone objecting
>to a new EERO at the time ;-)
>
>>
>>  In any case, what is the value of the router ID when the ingress/egress
>>  interface identifiers are IPv4 addresses?
>
>As stated in the draft, it makes EERO processing very very simple. There
>are no abstract node lookups, you just see if you are the router with the
>router ID and then associate with the UP/DOWN-stream interfaces and the
>LSP setup is on its way. The fact that you don't need to do a AN lookup by
>itself probably saves about 1/3 to 2/3 of LSP PATH processing in the node.
>
>
>>  > 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.
>
>Why?  You can perfectly specify a loose hop where you want the LSP to
>specifically enter through interface A and leave the hop through interface
>B. I can see benefits of this in a regular MPLS network as well as an
>optical network.
>
>>
>>  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?
>>
>
>The cases that were stated were examples, it is perfectly legal to have
>only LR-HOPs or AN-HOPs by themselves and add or delete HOPs in the middle
>of an LSP.
>
>We will refine this section in the next version of the draft.
>
>>  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,
>
>I think you have seen the problem that we are trying to address but do not
>believe that a new ERO (EERO) is necessary. On the other hand, the fact
>that we have cut the AN lookup out of most EERO processing, that we have
>made
>the EERO very specific and detailed have achieved our goal. If these were
>in the ERO in the first place, I am sure that at least our implementation
>would have been shorter.
>
>We believe that this draft is useful and adds value to existing MPLS
>implementations and reduces the chance having un-interoperable MPLS
>implementations. I know of interoperability problems even between two
>leading vendors' implementations that have brought networks down for days,
>and we are trying to prevent that when there are (say) six vendors'
>equipment in the network.
>
>We appreciate your comments and will incorporate these into the next
>version of our draft.
>
>Regards
>
>Bora