Right, each protocol has its own constraint, but do you think creating an additional generic marker will solve those constraints ? We would expect to be able to have the generic marker to protocol tag and also two protocol tags with different constraints to interact between each other (I mean for example, learning a RIP tag and copying it to ISIS or OSPF).
From: Jeffrey Haas [mailto:[email protected]] Sent: Monday, July 20, 2015 14:44 To: LITKOWSKI Stephane SCE/IBNF Cc: [email protected] Subject: Re: Comments on draft-shaikh-rtgwg-policy-model Stephane, On Jul 20, 2015, at 2:21 PM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[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 _________________________________________________________________________________________________________________________ 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
