hi peter, understood - so what about simply reserving a certain range of the tag space for well-known applications (+IANA registry etc.) such that for 2) we can avoid distributing policies ?
/hannes On Tue, Aug 26, 2014 at 05:43:48PM +0200, Peter Psenak wrote: | Hi Hannes, | | On 8/26/14 17:32 , Hannes Gredler wrote: | >hi peter, | > | >operators want to assign node-tags as per router function (ABR, PE, core) and then | >the LFA-selection becomes much easier to specify. - e.g. | >- only pick a LFA that does not cross another PE router. | > | >similarily it is desirable for "LFA tunnel termination" | >to put out a constraint which says | >- only pick a PQ neighbor which has node tag 'X' | | my point is that with the above approach you have to: | 1. On candidate PQ nodes configure the tag X | 2. on all other nodes configure "only pick a PQ neighbor which has node tag | 'X'" | | It's (2) which makes me feel uncomfortable, as it's a config to be applied | to many nodes. | | If we instead define a capability bit which would mean "PQ candidate", we | would avoid (2). | | > | >i found it always strange that we for TE (as an example for | >constraining paths) we have got ways to tag links, but | >not way to tag nodes - that draft aims to fix that. | | I'm not against tagging nodes as such. What worries me if we end up using | node tags for signalling capabilities of node. | | thanks, | Peter | | > | >HTH, | > | >/hannes | > | >On Tue, Aug 26, 2014 at 04:30:26PM +0200, Peter Psenak wrote: | >| Hi Acee, | >| | >| On 8/26/14 15:45 , Acee Lindem (acee) wrote: | >| >Hi Peter, | >| >This is a valid concern and one that we¹ve discussed previously with | >| >respect to routing behavior based on policies. I think that accepting this | >| >draft as a WG document should not preclude standardization of capabilities | >| >advertisement for popular applications. | >| | >| sure. Just that the draft mentions applications like "Controlling Remote LFA | >| tunnel termination", which I'm not sure the node tag is the best approach | >| for. | >| | >| thanks, | >| Peter | >| | >| >Thanks, | >| >Acee | >| > | >| >On 8/26/14, 4:05 AM, "Peter Psenak (ppsenak)" <[email protected]> wrote: | >| > | >| >>On 8/25/14 23:18 , Acee Lindem (acee) wrote: | >| >>>There are situations where node level policy is required and an OSPF | >| >>>advertised admin tag simplifies this. For example, advertisement of | >| >>>remote-LFA eligibility. | >| >> | >| >>my concern with the generic use of admin tags for signaling capability | >| >>is that it's operationally unfriendly compared to explicit signaling of | >| >>the capability (e.g. using a bit or a TLV). The reason is that you have | >| >>to configure the tag meaning on all receiving routers. | >| >> | >| >>thanks, | >| >>Peter | >| >> | >| >>> | >| >>>Please indicate your support or objections to adopting this draft as an | >| >>>OSPF WG document. | >| >>> | >| >>>Thanks, | >| >>>Acee | >| >>> | >| >>> | >| >>>_______________________________________________ | >| >>>OSPF mailing list | >| >>>[email protected] | >| >>>https://www.ietf.org/mailman/listinfo/ospf | >| >>> | >| >> | >| >>_______________________________________________ | >| >>OSPF mailing list | >| >>[email protected] | >| >>https://www.ietf.org/mailman/listinfo/ospf | >| > | >| >. | >| > | >| | >| _______________________________________________ | >| OSPF mailing list | >| [email protected] | >| https://www.ietf.org/mailman/listinfo/ospf | >. | > | _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
