The MPLS WG Archive

[Jonathan Lang <jplang@calient.net>]

Bora,
  Please explain how the current ERO and unnumbered interfaces are affected
by fast reroute.  

Thanks,
Jonathan


> -----Original Message-----
> From: Bora Akyol [mailto:akyol@pluris.com]
> Sent: Monday, February 26, 2001 10:48 AM
> To: Bora Akyol
> Cc: Kireeti Kompella; mpls@UU.NET
> Subject: Re: New Internet Draft on ERO
> 
> 
> 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
>