On Mon, 3 Feb 2003, Juergen Schoenwaelder wrote: > Since forwarding architectures tend to look pretty different, I guess > we can't do more than using some opaque identifier - whether that is > an OBJECT IDENTIFIER, an INTEGER will some smart numbering scheme > (similar to SnmpSecurityModel), or an OCTET STRING does not really > make a big difference to me.
In principle any one of those could be made to work, yes. > The problem is that mgmt applications either understand the > semantics of a particular implementation or they will have to > guess or ignore some rows. I undestand that a management application may not have full understanding of route table entries without understanding the nature of the opaque identifier. But I don't follow why that implies that a management application has to ignore some rows -- at least if all it's doing is inspecting rather than modifying the rows. The proposed index components are destination prefix, opaque identifier, and next hop. I can still determine how many routes to a given destination via a particular next hop exist (and query their other properties) even if I don't know what the opaque identifier is. [Note that the order given for the indices may not be the optimal one -- probably the opaque identifier should be last -- but that does not affect the information content.] > So from an interoperability point of view, all this is only > little better than not having such an index component. I don't think I agree. It's much better, because I can at least represent a forwarding architecture that permits multiple routes to a destination via the same next hop. Without the opaque identifier I could not do that. More generally, without the opaque identifier I could not map the table to an arbitrary forwarding architecture. It is true that it's best to split as much common stuff out of the opaque identifier as possible. If you can identify some additional generic candidate index components beside destination prefix and next hop please say so. //cmh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
