Subject: New Internet Draft on ERO

From: Bora Akyol <[email-masked]>
Date: Sat, 24 Feb 2001 07:52:43 -0800 (PST)

We have posted a new Internet Draft on ERO in RSVP-TE.
We welcome comments from the MPLS WG.

The draft can be found at:

http://www.ietf.org/internet-drafts/draft-akyol-mpls-exp-ero-00.txt

Regards

Bora Akyol

---

From: Kireeti Kompella <[email-masked]>
Date: Mon, 26 Feb 2001 03:41:47 -0800 (PST)

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.

---

From: Bora Akyol <[email-masked]>
Date: Mon, 26 Feb 2001 08:45:55 -0800 (PST)

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:

> you propose does not dependent on the order of appearance?

It does depend on the order of appearance but we clearly wanted to make

> 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.

> 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 > 

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.

> 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 ;-)

> 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.

> 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.

> with EERO-HOPs, and that EERO-HOPs must be present.  Is that what you

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.

> but rather to achieve greater clarity.  Of course, the current semantics

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 10:48:10 -0800

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

Thanks

Bora

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 27 Feb 2001 10:33:33 -0500

Hello,

I don't remember the question was answered in the previous discussion, which
ended silently. So, if the router ID is not in ERO, where is it?

Thanks for updating me.

Yangguang