Hi Jeff, Inline comments
From: Jeffrey Haas [mailto:[email protected]] Sent: Monday, July 20, 2015 13:47 To: LITKOWSKI Stephane SCE/IBNF Cc: [email protected] Subject: Re: Comments on draft-shaikh-rtgwg-policy-model On Jul 20, 2015, at 1:35 PM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: - Regarding tags, as pointed today, I would like to have “tag” to be a generic local identifier rather than pointing only to IS-IS and OSPF. Any route within a RIB may have a local tag (this local tag can be learned from the routing protocol or set by configuration or policy). So setting a tag does not refer to any igp-action. I believe we do wish to keep this field used for IGP route tagging since that's a protocol component. [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. (Fascinating issue, while researching ISIS implementations I found that the protocol permits 64bit tagging, but didn't find anyone that implemented them.) [SLI] ☺ we have it in IS-IS yang model , tag64 if I remember correctly. I do realize that there is also a need to do general route mark-up so that policy engines can operate off of that. I know that for certain route types, the "tag" field might be able to be used for this purpose; e.g it has no semantics in a given BGP implementation unless the route is redistributed in the IGP. (And I'm not even sure that field survives export, I'd have to check the code.) Perhaps more appropriate would be to have a new mark-up field, name TBD, to cover this purpose. It could then be implemented as appropriate for a given route type and vendor implementation? -- Jeff _________________________________________________________________________________________________________________________ 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.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
