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

["Acee Lindem (acee)" <[e-mail]>]

I’ve read all the E-mails in this thread and I think I agree with Stephane in that a route has one or more tags that are advertised within the protocols and are installed into the appropriate RIB. This is the most straight forward and useful application of tags.

I think having two types of tags for routes (local and IGP) will only add complexity and confusion.

Thanks,
Acee

From: rtgwg <[e-mail]<mailto:[e-mail]>> on behalf of Stephane Litkowski <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 22, 2015 at 2:43 PM
To: Rob Shakir <[e-mail]<mailto:[e-mail]>>, Jon Mitchell <[e-mail]<mailto:[e-mail]>>
Cc: Routing WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

I have no issue to have two tags as long as I can have dynamic copy of the one the other (copying local tag to protocol tag, or reverse, or a protocol tag between two different protocols …).


From: Rob Shakir [mailto:[e-mail]]
Sent: Wednesday, July 22, 2015 10:18
To: Jon Mitchell; LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; [e-mail]<mailto:[e-mail]>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

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]<mailto:[e-mail]>) wrote:
On 22/07/15 07:32 +0000, [e-mail]<mailto:[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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.