[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ERO implementation survey
Diego,
Not my intention to imply this.
TE link ID (incoming or outgoing) means the identifier (numbered or
unnumbered) of the TE link.
TE Router ID means the identifier of the node.
Thanks,
Adrian
----- Original Message -----
From: "Diego Caviglia" <Diego.Caviglia@marconi.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "<ccamp" <ccamp@ops.ietf.org>
Sent: Thursday, March 30, 2006 8:34 AM
Subject: Re: ERO implementation survey
>
> Hi Adrian,
> just a clarification, TE Router ID and Outgoing TE link ID
means
> that the TE Link is unnumbered?
>
> Regards
>
> Diego
>
>
>
> "Adrian Farrel" <adrian@olddog.co.uk>@ops.ietf.org on 28/03/2006
21.12.04
>
> Please respond to "Adrian Farrel" <adrian@olddog.co.uk>
>
> Sent by: owner-ccamp@ops.ietf.org
>
>
> To: <ccamp@ops.ietf.org>
> cc:
>
> 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
>
>
>
>
>
>
>
>
>