Calling implementors: ERO implementation survey

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

I have had some responses to this request.

In case the information so far is unrepresentative, I'd really appreciate
it if you could take 5 minutes to send me a private response.

Thanks.

Adrian
----- Original Message ----- 
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, March 28, 2006 8:12 PM
Subject: ERO implementation survey


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