The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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