Subject: ERO implementation survey

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Mar 2006 20:12:04 +0100

In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we
determined that implementations must support any form of ERO that is
legitimately sent by any other implementation. At the same time there is a
desire to reduce the number of options if this is possible. Lastly, there
was some confusion about what the RFCs actually allow you to do, and
rather than debate this as though we were lawyers, it may be more
profitable to look at what current implementations do.

Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473
go to Draft Standard.

To move things forward, I would like to do an informal and *confidential*
survey of current implementations.

Please respond to each question below with, Yes / No / NA
NA would largely apply where the implementation is found on a NE where the
technology makes the ERO option inappropriate.

Send your responses to me and not to the mailing lists (unless you fancy
the publicity).

Thanks,
Adrian

1. EROs built for use on Path messages
For each hop in the path, which of the following options does your
implementation utilise?
This question applies to EROs that your implementations construct, NOT to
EROs that you forward.

a. IP Address with non-full prefix length specifying a group of nodes

b. AS number

c. TE Router ID

d. Incoming TE link ID

e. Outgoing TE link ID

f. Outgoing TE link ID followed by one or two Label subobjects

g. Outgoing TE link ID followed by Component Interface ID subobject

h. Outgoing TE link ID followed by Component Interface ID subobject
   and one or two Label subobjects

i. TE Router ID and Outgoing TE link ID

j. TE Router ID and Outgoing TE link ID  followed by one or two
   Label subobjects

k. TE Router ID and Outgoing TE link ID followed by Component
   Interface ID subobject

l. TE Router ID and Outgoing TE link ID followed by Component
   Interface ID subobject and one or two Label subobjects

m. Incoming TE link ID and Outgoing TE link ID

n. Incoming TE link ID and Outgoing TE link ID  followed by one or two
   Label subobjects

o. Incoming TE link ID and Outgoing TE link ID followed by Component
   Interface ID subobject

p. Incoming TE link ID and Outgoing TE link ID followed by Component
   Interface ID subobject and one or two Label subobjects

q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID

r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID  followed
   by one or two Label subobjects

s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
   by Component Interface ID subobject

t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
   by Component Interface ID subobject and one or two Label subobjects

2. EROs received from the previous hop on Path messages
Which *top* subobjects in the ERO does your implementation support
receiving?
This question applies to ERO subobjects that your implementations must
handle, NOT to ERO subobjects that you forward.

a. IP Address with non-full prefix length specifying a group of nodes

b. AS number

c. TE Router ID

d. Incoming TE link ID

e. Outgoing TE link ID

f. Outgoing TE link ID followed by one or two Label subobjects

g. Outgoing TE link ID followed by Component Interface ID subobject

h. Outgoing TE link ID followed by Component Interface ID subobject
   and one or two Label subobjects

i. TE Router ID and Outgoing TE link ID

j. TE Router ID and Outgoing TE link ID  followed by one or two
   Label subobjects

k. TE Router ID and Outgoing TE link ID followed by Component
   Interface ID subobject

l. TE Router ID and Outgoing TE link ID followed by Component
   Interface ID subobject and one or two Label subobjects

m. Incoming TE link ID and Outgoing TE link ID

n. Incoming TE link ID and Outgoing TE link ID  followed by one or two
   Label subobjects

o. Incoming TE link ID and Outgoing TE link ID followed by Component
   Interface ID subobject

p. Incoming TE link ID and Outgoing TE link ID followed by Component
   Interface ID subobject and one or two Label subobjects

q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID

r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID  followed
   by one or two Label subobjects

s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
   by Component Interface ID subobject

t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
   by Component Interface ID subobject and one or two Label subobjects

---

From: "Igor Bryskin" <[email-masked]>
Date: Wed, 29 Mar 2006 09:27:13 -0500

See my rsponses below.
Igor

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 28, 2006 2:12 PM
Subject: ERO implementation survey

> a. IP Address with non-full prefix length specifying a group of nodes
No
> b. AS number
No
> c. TE Router ID
Yes
> d. Incoming TE link ID
No, with the exception of the LSP destination, that is, our implementation
has an option to include in the ERO an incoming Te link ID on the
destination.
> e. Outgoing TE link ID
Yes
> f. Outgoing TE link ID followed by one or two Label subobjects
Yes
> g. Outgoing TE link ID followed by Component Interface ID subobject
Yes
>    and one or two Label subobjects
Yes
> i. TE Router ID and Outgoing TE link ID
Yes
> j. TE Router ID and Outgoing TE link ID  followed by one or two
Yes
> k. TE Router ID and Outgoing TE link ID followed by Component
Yes
>    Interface ID subobject and one or two Label subobjects
Yes
> m. Incoming TE link ID and Outgoing TE link ID
No
> n. Incoming TE link ID and Outgoing TE link ID  followed by one or two
No
> o. Incoming TE link ID and Outgoing TE link ID followed by Component
No
>    Interface ID subobject and one or two Label subobjects
No
> q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
No
>    by one or two Label subobjects
No
>    by Component Interface ID subobject
No
>    by Component Interface ID subobject and one or two Label subobjects
No
> a. IP Address with non-full prefix length specifying a group of nodes
No (I wonder what does this mean in the TE context? I thought we have agreed
that IP Address in the ERO does not necessarily mean routable address,
rather, numbered TE links. So, what does it mean numbered TE link Id with
non-full prefix length? )
> b. AS number
Yes
> c. TE Router ID
Yes
> d. Incoming TE link ID
Yes
> e. Outgoing TE link ID
Yes
> f. Outgoing TE link ID followed by one or two Label subobjects
Yes
> g. Outgoing TE link ID followed by Component Interface ID subobject
Yes
>    and one or two Label subobjects
Yes
> i. TE Router ID and Outgoing TE link ID
Yes
> j. TE Router ID and Outgoing TE link ID  followed by one or two
Yes
> k. TE Router ID and Outgoing TE link ID followed by Component
Yes
>    Interface ID subobject and one or two Label subobjects
Yes
> m. Incoming TE link ID and Outgoing TE link ID
Yes
> n. Incoming TE link ID and Outgoing TE link ID  followed by one or two
Yes
> o. Incoming TE link ID and Outgoing TE link ID followed by Component
Yes
>    Interface ID subobject and one or two Label subobjects
Yes
> q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
Yes
>    by one or two Label subobjects
Yes
>    by Component Interface ID subobject
Yes
>    by Component Interface ID subobject and one or two Label subobjects
Yes