[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ERO implementation survey
See my rsponses below.
Igor
----- Original Message -----
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Sent: Tuesday, March 28, 2006 2: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
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
>
> h. Outgoing TE link ID followed by Component Interface ID subobject
> 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
> Label subobjects
Yes
>
> k. TE Router ID and Outgoing TE link ID followed by Component
> Interface ID subobject
Yes
>
> l. TE Router ID and Outgoing TE link ID followed by Component
> 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
> Label subobjects
No
>
> o. Incoming TE link ID and Outgoing TE link ID followed by Component
> Interface ID subobject
No
>
> p. Incoming TE link ID and Outgoing TE link ID followed by Component
> Interface ID subobject and one or two Label subobjects
No
>
> q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
No
>
> r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
> by one or two Label subobjects
No
>
> s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
> by Component Interface ID subobject
No
>
> 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
No
>
> 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
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
>
> h. Outgoing TE link ID followed by Component Interface ID subobject
> 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
> Label subobjects
Yes
>
> k. TE Router ID and Outgoing TE link ID followed by Component
> Interface ID subobject
Yes
>
> l. TE Router ID and Outgoing TE link ID followed by Component
> 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
> Label subobjects
Yes
>
> o. Incoming TE link ID and Outgoing TE link ID followed by Component
> Interface ID subobject
Yes
>
> p. Incoming TE link ID and Outgoing TE link ID followed by Component
> Interface ID subobject and one or two Label subobjects
Yes
>
> q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID
Yes
>
> r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
> by one or two Label subobjects
Yes
>
> s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed
> by Component Interface ID subobject
Yes
>
> 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
Yes
>
>