Re: [OSPF] Poll for WG adoption of draft-hegde-ospf-node-admin-tag

[Hannes Gredler <[e-mail]>]

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)" <[e-mail]> 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
| >| >| >>>[e-mail]
| >| >| >>>https://www.ietf.org/mailman/listinfo/ospf
| >| >| >>>
| >| >| >>
| >| >| >>_______________________________________________
| >| >| >>OSPF mailing list
| >| >| >>[e-mail]
| >| >| >>https://www.ietf.org/mailman/listinfo/ospf
| >| >| >
| >| >| >.
| >| >| >
| >| >|
| >| >| _______________________________________________
| >| >| OSPF mailing list
| >| >| [e-mail]
| >| >| https://www.ietf.org/mailman/listinfo/ospf
| >| >.
| >| >
| >|
| >.
| >
|