hi peter, if you can convince stewart to add it as part of the rlfa spec it would be certainly a good thing to have :-)
in the meantime i'd like to use the tagging scheme as described and use it as a last resort tool for expressing network policy in case there is lack of protocol support for doing so. /hannes On Tue, Aug 26, 2014 at 06:40:22PM +0200, Peter Psenak wrote: | Hi Hannes, | | On 8/26/14 17:59 , Hannes Gredler wrote: | >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 ? | | we have an existing mechanism for advertising capabilities - RFC4970, | section 2.3 and 2.4. We can reserve a bit for each well-known application. | | thanks, | Peter | | > | >/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)" <ppse...@cisco.com> 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 | >| >| >>>OSPF@ietf.org | >| >| >>>https://www.ietf.org/mailman/listinfo/ospf | >| >| >>> | >| >| >> | >| >| >>_______________________________________________ | >| >| >>OSPF mailing list | >| >| >>OSPF@ietf.org | >| >| >>https://www.ietf.org/mailman/listinfo/ospf | >| >| > | >| >| >. | >| >| > | >| >| | >| >| _______________________________________________ | >| >| OSPF mailing list | >| >| OSPF@ietf.org | >| >| https://www.ietf.org/mailman/listinfo/ospf | >| >. | >| > | >| | >. | > | _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
