Subject: RE: New Internet Draft on ERO

From: Jonathan Lang <[email-masked]>
Date: Mon, 26 Feb 2001 14:00:38 -0800

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

Thanks,
Jonathan

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Monday, February 26, 2001 10:48 AM
> To: Bora Akyol
> Cc: Kireeti Kompella; [email-masked]
> 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
>

---

From: Bora Akyol <[email-masked]>
Date: Mon, 26 Feb 2001 14:39:37 -0800

My question is as follows:

How do you do fast reroute when you have unnumbered interfaces in the 
ERO as in the unnumbered draft? What out of band information is added 
to what's in the ERO when we do CSPF? Is everyone doing it the same 
way?

If we use the (newly defined) EERO then fast reroute is the same for 
both numbered and unnumbered interfaces and it actually becomes quite 
easy.

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Feb 2001 15:14:38 -0800

Bora,

> both numbered and unnumbered interfaces and it actually becomes quite 

Could you point me to the MPLS WG document(s) that specifies
how to perform fast re-route ?

Yakov.

---

From: Bora Akyol <[email-masked]>
Date: Mon, 26 Feb 2001 15:49:29 -0800

>how to perform fast re-route ?

Well, there was the ID from George Swallow that we discussed in San 
Diego. And then there were some discussions on the list that I 
participated in 1998. Vishal Sharma et al, produced IDs on that 
subject as well.

Maybe it is time that we write a BCP on that topic. Would this fall 
into CCAMP or MPLS? In the last IETF, **all** of the fast 
reroute/recovery schemes were sent to CCAMP AFAIK.

I know how we implemented fast reroute and I am sure you know of at 
least two implementations.

So if there is interest on the WG, I can volunteer to put together a 
group of people to write such a BCP.

But my original question still stands,

how do you do fast reroute when you have unnumbered interfaces? It is 
possible to do, but becomes much easier if you have the router ID as 
part of the ERO subobject as we did in our EERO specification. Please 
see draft-akyol-mpls-exp-ero-00.txt

Regards

Bora

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Feb 2001 11:21:17 -0800

Bora,

> But my original question still stands,

Your original question is ambiguous, as it didn't spell out
which *specific* fast reroute scheme is used (and as you indicated
above there is more than one such scheme).

Also, are you asserting that none of the fast reroute schemes
could work with unnumbered interfaces in the ERO as specified
in the unnumbered draft ?

Yakov.

---

From: Bora Akyol <[email-masked]>
Date: Tue, 27 Feb 2001 11:59:12 -0800

>in the unnumbered draft ?

Yakov

What I am asserting is the fact that unnumbered interfaces as 
specified in the unnumbered draft make calculation of a fast reroute 
LSP difficult even when you make assumptions about which interface 
belongs to which router. The specific fast reroute scheme that I had 
in mind was the one where you calculate a fast reroute LSP that 
avoids the immediate next hop.

Also see the point that Vach made in a separate email.

Bora