Subject: RE: Expanded ERO draft

From: Vach Kompella <[email-masked]>
Date: Thu, 1 Mar 2001 09:19:47 -0800

My vote (I didn't see dev. manager, but I run the group that's implementing
it, so I speak on their behalf) would be to throw the router ID in there.  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.

However, I would rather see a single ERO rather than both an ERO and an
EERO, and the mess of having to deal with interoperability, backwards
compatibility.

-Vach

-----Original Message-----
From: Rahul Aggarwal [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 8:53 AM
To: Vijay Gill
Cc: Kireeti Kompella; [email-masked]
Subject: Re: Expanded ERO draft

This is coming from a developer : )

I was in favor of adding a router id to the unnumbered ERO subobject
when the subject was discussed on the list a while back. Its cleaner
to implement. 

At the same time I think most of the information in the expanded ERO
draft is redundant. An informational doc on the current usage
will be of more value than adding new objects all over the
place. Some rewording in the RSVP-TE draft will also help.

Its a yes to adding a router id to the unnumbered ERO subobject.

thanks,
rahul

On Thu, Mar 01, 2001 at 01:20:38AM -0500, Vijay Gill wrote:
> On Tue, 27 Feb 2001, Kireeti Kompella wrote:
> 
> > As Yakov said, no concrete reason for adding the router ID has been
> > given.  However, we've wasted enough time and bandwidth.  Let's put
> > this to vote:
> >
> > Who all think that adding a router ID to the unnumbered ERO subobject
> > would be beneficial?  A simple yes, no or don't care, please.
> 
> I would listen to what the people who are implementing this have to say on
> the subject. I particularly don't care about the bandwidth/extra bytes
> argument, but as a service provider, I do care that the people who are
> implementing this do this in the simplest way possible. It makes for
> robust code and I like robust code because getting up in the AM really
> really annoys me.
> 
> So my vote ranking system would go like this ;)
> 
> People who are writing this code (developers): 10x
> People who are the protocol architects: 2x
> Other people: 1x
> 
> Lets hear it from the implementors:
> 
> thank you
> 
> /vijay
>

---

From: Bora Akyol <[email-masked]>
Date: Thu, 1 Mar 2001 16:02:16 -0800

having the router id in addition to at least the egress interface ID 
helps by eliminating abstract node lookups and just simplifies ERO 
processing.

If WG will adopt this as a new ERO as opposed to defining an EERO, then be it.

Bora

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 2 Mar 2001 11:26:26 -0800 (PST)

Hi Vach,

> I

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.

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 2 Mar 2001 11:33:28 -0800

> just shipped to the IETF).  Does this cover it?

That is great.

> If you agree that the above two are not needed, we don't need a new

I don't think the above two are needed. We don't need a new EERO object.

thanks,
rahul

---

From: Bora Akyol <[email-masked]>
Date: Fri, 2 Mar 2001 13:03:10 -0800

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

---

From: Ben Black <[email-masked]>
Date: Fri, 2 Mar 2001 13:11:06 -0800

> objects. (Ok, this is a consistency issue)

Ok.

> the most common type objects (/32) as in you don't need to do it at 

Doesn't introducing a special case contradict your argument for
consistency above?

Ben

---

From: Bora Akyol <[email-masked]>
Date: Fri, 2 Mar 2001 13:24:04 -0800

>Doesn't introducing a special case contradict your argument for

This is a good point.

Once you agree to add the router ID, it takes a few lines of code to 
diffentiate between /32 subobjects and others.

In our EERO draft, this is why we separated out Abstract Node and 
Loose route subobjects from the strict subobjects.

But if you want to use the ERO, then if you have a non-/32 subobject 
you can safely ignore the router ID.

Alternatively, we can merge the EERO with ERO and end up with 
something along the lines:

1) Create separate Abstract Node and Loose Route subobjects as 
described in EERO draft.
2) Add router ID to both strict numbered and unnumbered subobjects.

This will result in a more consistent solution.

Just out of curiousity, how often does one encounter either Loose or 
Abstract Node subobjects in real networks?

Bora

---

From: Yangguang Xu <[email-masked]>
Date: Mon, 05 Mar 2001 09:10:21 -0500

Kireeti,

> just shipped to the IETF).  Does this cover it?

Fine for conventional MPLS. But still not enough for circuit switched networks,
for example, optical network.

> If you agree that the above two are not needed, we don't need a new

Sure.

Yangguang