Subject: Expanded ERO draft (http://cell.onecall.net/mhonarc/mpls/current/msg00062.html)

From: "Francis Arts" <[email-masked]>
Date: Mon, 12 Mar 2001 23:26:27 +0100

Hello Bora,

I have a question concerning the use of the ingress IDs and how these can be replaced using 2 ERO subobjects.

The example I have in mind, is the one you mentioned:
* 2 routers connected with 2 ethernet switches in the middle.
* Each router has 2 interfaces - 1 to each ethenet switch.

This case was one of the arguments for the addition of the egress ID to the EERO subobject: The ingress LSR can then choose either of the 2 egress interfaces for routing the LSP.

Can the same argument be applied when traffic is flowing in the reverse direction? That is, can the ingress ID just as well be useful here to choose the proper ingress ID on which the explicitly routed LSP should enter the node? [I do not see how this behavior can be achieved by using 2 ERO subobjects.]

Kind regards,

    Francis.

------------------

--------------------------------------------------------------------------------
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 
Expanded ERO draft
a.. From: Bora Akyol <[email-masked]> 
    b.. Date: Fri, 2 Mar 2001 13:03:10 -0800 
    c.. Cc: [email-masked], [email-masked] 
    d.. In-Reply-To: <[email-masked]> 
    e.. References: <[email-masked]> 
    f.. X-Sender: akyol@avalon 

Kireeti

There are two reasons why it would be a good idea to add the router 
ID to the ERO for numbered interfaces as well:

1) It makes the ERO consistent between numbered and unnumbered 
objects. (Ok, this is a consistency issue)
2) It makes Abstract node lookup as described in RSVP-TE simpler for 
the most common type objects (/32) as in you don't need to do it at 
all.
3) By using the router ID in the numbered subobjects one can easily 
catch errors in TE database, helps troubleshooting also in this case.

It makes the common path processing faster.

Regarding having both ingress and egress IDs. I still think that this 
makes the ERO very precise and removes any ambiguity in creation of 
these objects. For example, we currently create the egress interfaces 
out of each node as the ERO, but we don't have any problem creating 
an object that leaves nothing to guess-work. Regardless, you can 
achieve the same thing by adding two ERO subobjects which wastes even 
more bytes than our proposal. Instead, we can make the (I/E) bits on 
our draft to signal three possibilities:

	- Both exist and are unnumbered
	- I exists and is unnumbered
	- I exists and is numbered
(I may be missing a case here).
So one can easily omit the ingress interface ID.

To summarize, here is what I am proposing:

I) Add router ID to both numbered and unnumbered subobjects.
II) Improve the word alignments of the ERO subobjects as described in EERO.

I will be happy with (I).

Bora

At 11:26 AM -0800 3/2/01, Kireeti Kompella wrote:
>Hi Vach,
>
>>  I
>>  think it's great for debugging, too.  You can look at an inflight ERO and
>>  know exactly what it is supposed to do, without reference to a TED or an
>>  LSDB.
>
>Okay, I buy this argument -- it makes trouble shooting easier.
>
>We've added Router ID to the unnumbered ERO subobject (see version 01,
>just shipped to the IETF).  Does this cover it?
>
>So, about EERO, the remaining questions are:
>1) Why have router IDs for numbered subobjects?
>2) Why have ingress and egress ids *all* the time?  For the one
>    case of multiple multiaccess interfaces on a common subnet,
>    use two ERO subobjects.
>
>If you agree that the above two are not needed, we don't need a new
>EERO object.
>
>Kireeti.

    a.. Follow-Ups: 
        a.. Expanded ERO draft 
            a.. From: Ben Black <[email-masked]>
a.. References: 
        a.. Expanded ERO draft 
            a.. From: Kireeti Kompella <[email-masked]>
        b.. Expanded ERO draft 
            a.. From: Kireeti Kompella <[email-masked]>
a.. Prev by Date: Standards for IP stats collection? (corrected) 
    b.. Next by Date: RSVP-TE draft-08 
    c.. Prev by thread: Expanded ERO draft 
    d.. Next by thread: Expanded ERO draft 
    e.. Index(es): 
        a.. Date 
        b.. Thread