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
