Re: Comments on draft-shaikh-rtgwg-policy-model

[Rob Shakir <[e-mail]>]

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.

Cheers,
r.

[0]: https://github.com/YangModels/yang/blob/master/experimental/openconfig/local-routing/local-routing.yang 

On 22 July 2015 at 08:39:55, Jon Mitchell ([e-mail]) wrote:

On 22/07/15 07:32 +0000, [e-mail] wrote:  
> Hi Rob,  
>  
> Agree with the case you presented, IMO, we may provide some guidance to implementation on the behavior to use when a local-tag is translated to a protocol-tag and translation is not possible due to protocol-tag constraint (for example “do not copy tag”).  

I'd also point out that some implementations (even from the same  
vendor!) have different behavior on whether to default copy up from  
lcoal tag to protocol tag even when it is possible when redistribution  
is configured.  

-Jon