> On Jul 22, 2015, at 10:18 AM, Rob Shakir <[email protected]> wrote: > > The way that we have tried to approach these things with the OpenConfig > initiated models is “what is the way that we use this feature” - and then try > and design the way that the model works around this. > > To me, it seems like I want to be able to explicitly control whether > something that I am using as a local route marker (‘colour’) is propagated to > any of my neighbours via a particular routing protocol - otherwise, it takes > on other semantics that I might not intend it to do. > > In the local-routing [0] module, we use ‘tag’ as a protocol-agnostic way to > mark particular routes — and then when these locally generated routes are > imported into other protocols, then attributes for those protocols can be set > (e.g., BGP community etc.). It strikes me that we should have something > similar in each protocol export policy that says match on the local > ‘tag’/‘colour’ and set protocol-tag value X (or even a switch that says > ‘propagate tag’ assuming that the colour type can be mapped to the protocol > tag type). > > I’d really like to separate local ‘tag’/‘colour’ from ‘tag’ within any > particular protocol.
This is the substance of my suggested separate attribute rather than using "tag". I'm quite aware of operators using tag for this purpose, but it has impact in protocol and redistribution depending on implementation. There is some advantage to simply picking a similar attribute in an abstract fashion and letting a vendor choose where it goes to in the implementation. -- Jeff _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
