Stephane, > On Jul 20, 2015, at 2:21 PM, <[email protected]> > <[email protected]> wrote: > > [SLI] Do we really need to differentiate from a policy point of view ? from > an import policy perspective, matching a tag, means learning the tag value > available in the protocol (if available) and when the route ins inserted into > RIB the tag value is copied from the protocol value if not overrided by > import policy action; from an export policy perspective (talking about export > from rib to protocol), matching a tag means matching the tag value in the RIB > (which may come from protocol or not), setting a tag means fill the protocol > field if available. From a RIB point of view, the tag associated with the > route is protocol agnostic, even if the protocol does not support tags in > encoding you may associate a local tag for policy processing. > > Having two types of tags is also possible : protocol-tag and local-tag but I > see more complexity and do not see more flexibility : but maybe there is some > use case that I do not see.
The messy detail with this attribute is that while it's useful as a generic policy element, in specific protocol context it needs to have differing constraints. OSPF has one set of constraints, RIP a slightly different one (zero is reserved), and ISIS has different sizes with some option for one or two tags plus the 64-bit tag previously discussed. This set of context specific constraints probably removes some level of the flexibility that you'd want for it to be a generic marker - unless you can live within the least common denominator. -- Jeff
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
