public
public copied to clipboard
openconfig
Flex-algo model for IGP
Support for IGP Flexible algorithms (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-18)
The change proposes model for following
- Definition of flexible algorithm
- Advertising of flexible algorithm definition in IS-IS or just participation of IS-IS node in flexible algorithm
- Advertisement of a prefix-segment associated with a flexible-algorithm in IS-IS
Flex-algorithm is keyed by a name. Attributes of flex-algorithms can be defined under /network-instances/network-instance/flex-algorithms
+--rw flex-algorithms
| +--rw algorithm* [name]
| +--rw name -> ../config/name
| +--rw config
| | +--rw name? string
| | +--rw flex-algo-id flex-algo-id
| | +--rw metric-type? flex-algo-metric-type
| | +--rw calc-type? flex-algo-calc-type
| | +--rw priority? uint8
| | +--rw exclude-group* bit-position
| | +--rw include-all-group* bit-position
| | +--rw include-any-group* bit-position
| | +--rw srlg-names* -> ../../../../mpls/te-global-attributes/srlgs/srlg/name
| | +--rw srlg-values* uint32
| | +--rw color? uint32
| +--ro state
| +--ro name? string
| +--ro flex-algo-id flex-algo-id
| +--ro metric-type? flex-algo-metric-type
| +--ro calc-type? flex-algo-calc-type
| +--ro priority? uint8
| +--ro exclude-group* bit-position
| +--ro include-all-group* bit-position
| +--ro include-any-group* bit-position
| +--ro srlg-names* -> ../../../../mpls/te-global-attributes/srlgs/srlg/name
| +--ro srlg-values* uint32
| +--ro color? uint32
Once the flex-algo attributes are defined, the IGPs can participate/advertise them by using the flex-algo-name. For example in case of IS-IS the path in the model will be /network-instances/network-instance/protocols/protocol/isis/global/segment-routing/config/fad-bindings
+--rw isis
| +--rw global
...
| | +--rw segment-routing
| | | +--rw config
| | | | +--rw enabled? boolean
| | | | +--rw srgb? -> ../../../../../../../segment-routing/srgbs/srgb/config/local-id
| | | | +--rw srlb? -> ../../../../../../../segment-routing/srlbs/srlb/config/local-id
| | | | +--rw fad-bindings
| | | | +--rw fad-binding* [flex-algo-name]
| | | | +--rw flex-algo-name -> /network-instances/network-instance/flex-algorithms/algorithm/name
| | | | +--rw isis-level? oc-isis-types:level-type
| | | | +--rw advertised? boolean
| | | +--ro state
| | | +--ro enabled? boolean
| | | +--ro srgb? -> ../../../../../../../segment-routing/srgbs/srgb/config/local-id
| | | +--ro srlb? -> ../../../../../../../segment-routing/srlbs/srlb/config/local-id
| | | +--ro fad-bindings
| | | +--ro fad-binding* [flex-algo-name]
| | | +--ro flex-algo-name -> /network-instances/network-instance/flex-algorithms/algorithm/name
| | | +--ro isis-level? oc-isis-types:level-type
| | | +--ro advertised? boolean
IGPs can advertise prefix-segments with an associated flex-algo by using the flex-algo-name. flex-algo-prefix-sids container is added for associating prefix with a flex-algo segment. Currently only isis uses this container and the path is /network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/segment-routing/flex-algo-prefix-sids
+--rw isis
| +--rw global
...
| +--rw interfaces
| +--rw interface* [interface-id]
...
| +--rw levels
| | +--rw level* [level-number]
| | +--rw level-number -> ../config/level-number
...
| | +--rw afi-safi
| | | +--rw af* [afi-name safi-name]
...
| | | +--rw segment-routing
| | | +--rw prefix-sids
| | | | +--rw prefix-sid* [prefix]
| | | | +--rw prefix -> ../config/prefix
| | | | +--rw config
| | | | | +--rw prefix? inet:ip-prefix
| | | | | +--rw sid-id? oc-srt:sr-sid-type
| | | | | +--rw label-options? enumeration
| | | | +--ro state
| | | | +--ro prefix? inet:ip-prefix
| | | | +--ro sid-id? oc-srt:sr-sid-type
| | | | +--ro label-options? enumeration
| | | +--rw flex-algo-prefix-sids
| | | | +--rw flex-algo-prefix-sid* [prefix flex-algo-name]
| | | | +--rw prefix -> ../config/prefix
| | | | +--rw flex-algo-name -> ../config/flex-algo-name
| | | | +--rw config
| | | | | +--rw prefix? inet:ip-prefix
| | | | | +--rw flex-algo-name? -> /network-instances/network-instance/flex-algorithms/algorithm/name
| | | | | +--rw sid-id? oc-srt:sr-sid-type
| | | | +--ro state
| | | | +--ro prefix? inet:ip-prefix
| | | | +--ro flex-algo-name? -> /network-instances/network-instance/flex-algorithms/algorithm/name
| | | | +--ro sid-id? oc-srt:sr-sid-type
This matches the config model used in eos: https://eos.arista.com/eos-4-27-0f/is-is-flexible-algorithm/ We can configure flex algo definition under router traffic-engineering. This will translate to the path /network-instances/network-instance/flex-algorithms in the yang model
router traffic-engineering
flex-algo
flex-algo 128 HFT
priority 85
color 47
metric min-delay
administrative-group include all 0,3,5 include any 2,4,6 exclude 7-15
srlg exclude flag marea warf 101 680 880 17
The IS-IS can make use of this definition to either advertise it or it can just participate in the algorithm. This translates to the /network-instances/network-instance/protocols/protocol/isis/global/segment-routing/config/fad-bindings
router isis Amun
...
segment-routing mpls
flex-algo HFT level-1 advertised
IS-IS can advertise prefix-segments associated with a particular flex algorithm. In EOS, this can be configured under interface mode. This translates to this yang path: /network-instances/network-instance/protocols/protocol/isis/interfaces/interface/levels/level/afi-safi/af/segment-routing/flex-algo-prefix-sids
[no | default] node-segment (ipv4|ipv6) index <value> [flex-algo <name>]
Other vendors configuration model looks similar:
Cisco: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-6/segment-routing/configuration/guide/b-segment-routing-cg-asr9000-66x/b-segment-routing-cg-asr9000-66x_chapter_01111.html
Junos: https://www.juniper.net/documentation/us/en/software/junos/is-is/topics/topic-map/infocus-isis-flex-algo-sr.html
Nokia: https://infocenter.nokia.com/public/7750SR217R1A/index.jsp?topic=%2Fcom.nokia.Segment_Routing_and_PCE_User_Guide_21.7.R1%2Fconfiguring_flexible_algorithms.html
Somehow the goyang/ygot is failing and it does not seem to be because of this PR. I have no idea how to make it pass!
Sample failure log:
/go/bin/generator -output_file=/go/src/aft.openconfig-aft//oc.go -path=/workspace/release/models,/workspace/third_party/ietf -package_name=exampleoc -generate_fakeroot -fakeroot_name=device -compress_paths=true -shorten_enum_leaf_names -trim_enum_openconfig_prefix -typedef_enum_with_defmod -enum_suffix_for_simple_union_enums -exclude_modules=ietf-interfaces -generate_rename -generate_append -generate_getters -generate_leaf_getters -generate_delete -annotations -generate_simple_unions -list_builder_key_threshold=3 /workspace/release/models/network-instance/openconfig-network-instance.yang /workspace/release/models/aft/openconfig-aft-network-instance.yang
package aft.openconfig-aft: no Go files in /go/src/aft.openconfig-aft
@vivek-ilangovan you should be able to correct the issue by merging your PR with the latest copy of the master branch. Note there are some conflicts to be resolved
Thanks @dplore I have fetched new changes and resolved conflicts. The error messages were clear now and after some repeated trials all the checks are passing now
I have some comments on the Flex-algo PR. The proposal as it is, use some assumptions and observations for improving the PR.
- Important to realize is that flex-algo is dataplane agnostic and it can be sr-mpls and srv6. We should try to keep the OC agnostic too
- Flex-algo uses Extended Admin Group instead of classic Admin Groups (different TLV type). I believe the OC model should try to follow standard
- I like that a flex-algo definition is defined and abstracted outside the routing network instance, so that it can be used by multiple network instances
- I think that in the flex-algo definition terminology should follow proposed IETF draft: include-all, include-any and exclude instead of the exclude-group, include-all-group and include-any-group
- I think that we should refrain from specifying individual bit-positions under the Flex-algo-definition. We should configure “Extended Admin Groups” names at network instance level and associate each name with a specific EAG bit-position. That way we can use these EAG names to be assigned to interfaces and be used in the Flex-algo-definition
- I do not see the point for having both a config for srlg-names and srlg-values. We should only have a single leaf-list by using srlg names. The srlg are long numbers and hence using names seems the most sensible
- Why do we have the ‘color’ leaf under the FAD definition? This is a property that is not advertised by an IGP network instance. Defining a color is irrelevant for a Flex Algo definition, especially useless when SRv6 is used. It is a property that is most frequently used by applications using sr-mpls to associate a remote ip-address (for example a bgp next-hop) to a flex-algo derived sr-mpls tunnel. I strongly believe that we must not define a ‘color’ leaf and keep focussed upon those components in the flex-algo definition that are defined in the flex-algo specification
- Under the flex-algo definition, it could be interesting to have a description leaf (string) to provide readable information on the purpose of the flex-algo definition
- Should a leaf flags-tlv of type ‘boolean’ be added? When flex-algo is used only intra-domain there is no need for the flags-tlv and some older vendor OS’s did not support the flags-tlv causing havoc and non-compatible flex-algo implementations. With this Boolean we could control if a router is advertising the flags-tlv or not. Inside the flags-tlv there is the M-flag which could be used for consistent inter-area flex-algo operation, but may not be supported by all vendors, hence a Boolean to advertise flags-tlv is beneficial
Beyond the Flex-algo definition, we should define extensions in applications running on the router so that applications do the correct binding of a service to a corresponding sr-mpls flex algo tunnel. If for example for L3VPNs the bgp next-hop is reachable through sr-mpls and needs to be resolved using a particular flex-algo, then bgp must be made aware of this for the binding of the next-hop to the correct sr-mpls tunnel. Keep in mind that some vendors can only use the bgp color attribute for this purpose, while other vendors are less constraint. (Nokia for example, can match upon any of bgp attributes using legacy pre-existing bgp policies). I believe that the OC model should not constrain to only the bgp color attribute, especialy knowing that color is not even mentioned once in the flex-algo ietf draft specification. I think OC model should propose extensions in the policy yang with a new action ‘flex-algo <128..255>’ to steer the traffic into the correct flex-algo tunnels when sr-mpls is used. Note that for srv6 this is a non-existing problem as the srv6 locater used already provide a 1-to-1 relationship with a given flexible algorithm.
be well, Gunter Van de Velde
@gvandeve Thank you for nice suggestions and sorry for my delayed response.
I have some comments on the Flex-algo PR. The proposal as it is, use some assumptions and observations for improving the PR.
- Important to realize is that flex-algo is dataplane agnostic and it can be sr-mpls and srv6. We should try to keep the OC agnostic too
Sure, I believe the current proposal does not differentiate between sr-mpls and srv6. Just wanted to confirm that there is no change asked here right?
- Flex-algo uses Extended Admin Group instead of classic Admin Groups (different TLV type). I believe the OC model should try to follow standard
Agreed. Updated to leafref referencing the admin-group names as per your other suggestion.
- I like that a flex-algo definition is defined and abstracted outside the routing network instance, so that it can be used by multiple network instances
- I think that in the flex-algo definition terminology should follow proposed IETF draft: include-all, include-any and exclude instead of the exclude-group, include-all-group and include-any-group
Done
- I think that we should refrain from specifying individual bit-positions under the Flex-algo-definition. We should configure “Extended Admin Groups” names at network instance level and associate each name with a specific EAG bit-position. That way we can use these EAG names to be assigned to interfaces and be used in the Flex-algo-definition
Yes, I have changed this to reference the configured extended admin group names.
- I do not see the point for having both a config for srlg-names and srlg-values. We should only have a single leaf-list by using srlg names. The srlg are long numbers and hence using names seems the most sensible
Agreed. Removed srlg-values.
- Why do we have the ‘color’ leaf under the FAD definition? This is a property that is not advertised by an IGP network instance. Defining a color is irrelevant for a Flex Algo definition, especially useless when SRv6 is used. It is a property that is most frequently used by applications using sr-mpls to associate a remote ip-address (for example a bgp next-hop) to a flex-algo derived sr-mpls tunnel. I strongly believe that we must not define a ‘color’ leaf and keep focussed upon those components in the flex-algo definition that are defined in the flex-algo specification
Agreed, most vendors associate color with a flex-algo differently and this may not be the best place to have the color configuration. Removed it now.
- Under the flex-algo definition, it could be interesting to have a description leaf (string) to provide readable information on the purpose of the flex-algo definition
Yes, that will be nice. Added a 'flex-algo-description' leaf.
- Should a leaf flags-tlv of type ‘boolean’ be added? When flex-algo is used only intra-domain there is no need for the flags-tlv and some older vendor OS’s did not support the flags-tlv causing havoc and non-compatible flex-algo implementations. With this Boolean we could control if a router is advertising the flags-tlv or not. Inside the flags-tlv there is the M-flag which could be used for consistent inter-area flex-algo operation, but may not be supported by all vendors, hence a Boolean to advertise flags-tlv is beneficial
Got it, I have added a 'prefix-metric-flag' option now. I thought in case if more flags are added to flags-tlv we can control each flag separately using different booleans instead of one boolean for complete flags-tlv
Beyond the Flex-algo definition, we should define extensions in applications running on the router so that applications do the correct binding of a service to a corresponding sr-mpls flex algo tunnel. If for example for L3VPNs the bgp next-hop is reachable through sr-mpls and needs to be resolved using a particular flex-algo, then bgp must be made aware of this for the binding of the next-hop to the correct sr-mpls tunnel. Keep in mind that some vendors can only use the bgp color attribute for this purpose, while other vendors are less constraint. (Nokia for example, can match upon any of bgp attributes using legacy pre-existing bgp policies). I believe that the OC model should not constrain to only the bgp color attribute, especialy knowing that color is not even mentioned once in the flex-algo ietf draft specification. I think OC model should propose extensions in the policy yang with a new action ‘flex-algo <128..255>’ to steer the traffic into the correct flex-algo tunnels when sr-mpls is used. Note that for srv6 this is a non-existing problem as the srv6 locater used already provide a 1-to-1 relationship with a given flexible algorithm.
Sure, I guess the model for applications to bind to a flex-algo can come in later if that is ok?
Thanks, -Vivek
Hi Vivek,
Thanks to consider my feedback. Please find delayed feedback caused by my PTO.
I have some comments on the Flex-algo PR. The proposal as it is, use some assumptions and observations for improving the PR.
- Important to realize is that flex-algo is dataplane agnostic and it can be sr-mpls and srv6. We should try to keep the OC agnostic too
Sure, I believe the current proposal does not differentiate between sr-mpls and srv6. Just wanted to confirm that there is no change asked here right?
It was indeed a general comment, as too often by accident only sr-mpls dataplane is considered, while srv6 does exist and flex-algo is opaque on the dataplane used. It may be tempting to use dataplane aware terminology while proposing the OC model.
- Flex-algo uses Extended Admin Group instead of classic Admin Groups (different TLV type). I believe the OC model should try to follow standard
Agreed. Updated to leafref referencing the admin-group names as per your other suggestion.
Thank you
- I like that a flex-algo definition is defined and abstracted outside the routing network instance, so that it can be used by multiple network instances
- I think that in the flex-algo definition terminology should follow proposed IETF draft: include-all, include-any and exclude instead of the exclude-group, include-all-group and include-any-group
Done
Thank you
- I think that we should refrain from specifying individual bit-positions under the Flex-algo-definition. We should configure “Extended Admin Groups” names at network instance level and associate each name with a specific EAG bit-position. That way we can use these EAG names to be assigned to interfaces and be used in the Flex-algo-definition
Yes, I have changed this to reference the configured extended admin group names.
Thanks you
- I do not see the point for having both a config for srlg-names and srlg-values. We should only have a single leaf-list by using srlg names. The srlg are long numbers and hence using names seems the most sensible
Agreed. Removed srlg-values.
Thank you
- Why do we have the ‘color’ leaf under the FAD definition? This is a property that is not advertised by an IGP network instance. Defining a color is irrelevant for a Flex Algo definition, especially useless when SRv6 is used. It is a property that is most frequently used by applications using sr-mpls to associate a remote ip-address (for example a bgp next-hop) to a flex-algo derived sr-mpls tunnel. I strongly believe that we must not define a ‘color’ leaf and keep focussed upon those components in the flex-algo definition that are defined in the flex-algo specification
Agreed, most vendors associate color with a flex-algo differently and this may not be the best place to have the color configuration. Removed it now.
Yes. I know that we (Nokia) associate a flex-algo differently using another level of abstraction compared to other vendor OS's
- Under the flex-algo definition, it could be interesting to have a description leaf (string) to provide readable information on the purpose of the flex-algo definition
Yes, that will be nice. Added a 'flex-algo-description' leaf.
Thank you
- Should a leaf flags-tlv of type ‘boolean’ be added? When flex-algo is used only intra-domain there is no need for the flags-tlv and some older vendor OS’s did not support the flags-tlv causing havoc and non-compatible flex-algo implementations. With this Boolean we could control if a router is advertising the flags-tlv or not. Inside the flags-tlv there is the M-flag which could be used for consistent inter-area flex-algo operation, but may not be supported by all vendors, hence a Boolean to advertise flags-tlv is beneficial
Got it, I have added a 'prefix-metric-flag' option now. I thought in case if more flags are added to flags-tlv we can control each flag separately using different Boolean insteasd of one Boolean for complete flags-tlv
The reason i suggested a Boolean to either advertise or not advertise the flags-tlv was because i discovered incompatibility with older OS's that did not supported the latest version of flex-algo flags. Maybe we should have a Boolean for advertising/not-advertising the flags-tlv and have a container to control the flags individually?
+--rw flex-algorithms | +--rw algorithm* [name] | +--rw name -> ../config/name | +--rw config | | +--rw name? string | | +--rw flex-algo-id flex-algo-id | | +--rw metric-type? flex-algo-metric-type | | +--rw calc-type? flex-algo-calc-type | | +--rw priority? uint8 ... | | +--flags-tlv boolean | | +--flags-tlv-flags | | | +--prefix-metric-flag boolean //flag that when unset, then prefix-metric-flag is not supported in the IGP area instance will always be advertised as value '0' in the flags-tlv (if a flags-tls is originated by the FAD), however when prefix-metric-flag is set, then that setting identifies that prefix-metric-flag is supported.
Beyond the Flex-algo definition, we should define extensions in applications running on the router so that applications do the correct binding of a service to a corresponding sr-mpls flex algo tunnel. If for example for L3VPNs the bgp next-hop is reachable through sr-mpls and needs to be resolved using a particular flex-algo, then bgp must be made aware of this for the binding of the next-hop to the correct sr-mpls tunnel. Keep in mind that some vendors can only use the bgp color attribute for this purpose, while other vendors are less constraint. (Nokia for example, can match upon any of bgp attributes using legacy pre-existing bgp policies). I believe that the OC model should not constrain to only the bgp color attribute, especialy knowing that color is not even mentioned once in the flex-algo ietf draft specification. I think OC model should propose extensions in the policy yang with a new action ‘flex-algo <128..255>’ to steer the traffic into the correct flex-algo tunnels when sr-mpls is used. Note that for srv6 this is a non-existing problem as the srv6 locater used already provide a 1-to-1 relationship with a given flexible algorithm.
Sure, I guess the model for applications to bind to a flex-algo can come in later if that is ok?
Yes, i think that is correct. How applications figure out the mapping is decoupled from flex-algo technology itself and each application may potentially have its own capabilities and limitations on how that binding is achieved. Taking this out of the equation, avoids introducing biased restrictions on how such binding is achieved.
Be well, Gunter Van de Velde
Sorry for my super late response on this.
- Should a leaf flags-tlv of type ‘boolean’ be added? When flex-algo is used only intra-domain there is no need for the flags-tlv and some older vendor OS’s did not support the flags-tlv causing havoc and non-compatible flex-algo implementations. With this Boolean we could control if a router is advertising the flags-tlv or not. Inside the flags-tlv there is the M-flag which could be used for consistent inter-area flex-algo operation, but may not be supported by all vendors, hence a Boolean to advertise flags-tlv is beneficial
Got it, I have added a 'prefix-metric-flag' option now. I thought in case if more flags are added to flags-tlv we can control each flag separately using different Boolean insteasd of one Boolean for complete flags-tlv
The reason i suggested a Boolean to either advertise or not advertise the flags-tlv was because i discovered incompatibility with older OS's that did not supported the latest version of flex-algo flags. Maybe we should have a Boolean for advertising/not-advertising the flags-tlv and have a container to control the flags individually?
+--rw flex-algorithms | +--rw algorithm* [name] | +--rw name -> ../config/name | +--rw config | | +--rw name? string | | +--rw flex-algo-id flex-algo-id | | +--rw metric-type? flex-algo-metric-type | | +--rw calc-type? flex-algo-calc-type | | +--rw priority? uint8 ... | | +--flags-tlv boolean | | +--flags-tlv-flags | | | +--prefix-metric-flag boolean //flag that when unset, then prefix-metric-flag is not supported in the IGP area instance will always be advertised as value '0' in the flags-tlv (if a flags-tls is originated by the FAD), however when prefix-metric-flag is set, then that setting identifies that prefix-metric-flag is supported.
I checked the older revisions of the flex-algo draft and could not find anything other than the M flag in the flags subtlv section. So I did not understand the 'older OS's that did not supported the latest version of flex-algo flags'. Maybe these implementations used their own flags which are not present in the draft?
I now updated to just include the 'flags-tlv' boolean that you suggested earlier to keep it simple. If there is a need in the future, we can add control for individual flags.
Thanks, -Vivek
I now updated to just include the 'flags-tlv' boolean that you suggested earlier to keep it simple. If there is a need in the future, we can add control for individual flags.
Thanks, -Vivek
Yes, that would be good enough. What i meant is that between version -02 and -03 the flags-tlv was defined, and that some early adopter implementations did not support the encoding of the flags-tlv within an ISIS LSP at all. This caused initially some interop issues because newer implementations did simply advertise the flags-tlv by default. As result we (=Nokia) implemented a knob (Boolean) to either advertise or suppress the flags-tlv to facilitate interop with these early (pre draft -03) implementations. i agree that a future consideration would be to discuss knobs to control individual flags within the flags-tlv
Hi @vivek-ilangovan
Can this proposal be progressed? There are some checks not successful. Maybe the pyang tree's can be updated to reflect your latest code edits?
I had a quick ran through the yang and believe that one item is missing. In the fad-bindings we should add the option for configuring a flex-algo without the router participating and only start the flex-algo when it is enabled. For this there should be a another leaf 'participate' from the type boolean. In addition this it would allow to advertise a flex-algo fad, without the need for local router to participate. At the moment, when a binding is added, the flex-algo is activated and the router is participating, eventhough activation of the flex-algo is not required yet.
+--rw isis
| +--rw global
...
| | +--rw segment-routing
| | | +--rw config
| | | | +--rw enabled? boolean
| | | | +--rw srgb? -> ../../../../../../../segment-routing/srgbs/srgb/config/local-id
| | | | +--rw srlb? -> ../../../../../../../segment-routing/srlbs/srlb/config/local-id
| | | | +--rw fad-bindings
| | | | +--rw fad-binding* [flex-algo-name]
| | | | +--rw flex-algo-name -> /network-instances/network-instance/flex-algorithms/algorithm/name
| | | | +--rw isis-level? oc-isis-types:level-type
| | | | +--rw advertised? boolean
| | | | +--rw participate boolean <--- The new proposed leaf
Major YANG version changes in commit b7103831e5026f7ba74e29fb397297c215c21edb:
Hi @gvandeve
Thanks for the follow up!
Hi @vivek-ilangovan
Can this proposal be progressed? There are some checks not successful. Maybe the pyang tree's can be updated to reflect your latest code edits?
I resolved conflicts and seems like all checks are passing now except "Review required" and "Merging is blocked" (which I think requires review to be approved) Updated the pyang tree with latest code.
I had a quick ran through the yang and believe that one item is missing. In the fad-bindings we should add the option for configuring a flex-algo without the router participating and only start the flex-algo when it is enabled. For this there should be a another leaf 'participate' from the type boolean. In addition this it would allow to advertise a flex-algo fad, without the need for local router to participate. At the moment, when a binding is added, the flex-algo is activated and the router is participating, eventhough activation of the flex-algo is not required yet.
+--rw isis | +--rw global ... | | +--rw segment-routing | | | +--rw config | | | | +--rw enabled? boolean | | | | +--rw srgb? -> ../../../../../../../segment-routing/srgbs/srgb/config/local-id | | | | +--rw srlb? -> ../../../../../../../segment-routing/srlbs/srlb/config/local-id | | | | +--rw fad-bindings | | | | +--rw fad-binding* [flex-algo-name] | | | | +--rw flex-algo-name -> /network-instances/network-instance/flex-algorithms/algorithm/name | | | | +--rw isis-level? oc-isis-types:level-type | | | | +--rw advertised? boolean | | | | +--rw participate boolean <--- The new proposed leaf
I have added the participate bool. Both advertise and participate set a false does not make sense here but I couldn't think of a better way
@vivek-ilangovan Many thanks.
I have added the participate bool. Both advertise and participate set a false does not make sense here but I couldn't think of a better way
Many thanks. There is benefit for both 'participate' and 'advertised' configuration options.
Participate: When this is set to 'true', the router will try to participate with the flex-algo. It will participate when the router has support for the winning Flexible Algorithm Definition (FAD) and set support for relevant algorithm in the supported algorithms. If participate is set to False, then the router will not participate at all in the flexible algorithm.
Advertised: When set to 'true' then a locally configured fad is advertised and will be compared with all other fads learned from other routers. If set to 'false' the router will not advertise or consider the locally configured fad and will only use learned fads from other routers advertising their fad's
could we remove the algorithm out of the fad configuration? it seems to be more inline with your EOS config sniplet
I get impression that with EOS the algorithm itself is also configured within the ISIS context and not within a fad definition. With Nokia SROS the algorithm is configured under ISIS context and not within the configuration of the (named) fad itself.
in EOS
router traffic-engineering
flex-algo
flex-algo 128 HFT
priority 85
color 47
metric min-delay
administrative-group include all 0,3,5 include any 2,4,6 exclude 7-15
srlg exclude flag marea warf 101 680 880 17
in SROS
router
flexible-algorithm-definitions
flex-algo "My128" create
description "This-is-my-algo128"
metric-type delay
no shutdown
exit
exit
isis 0
flexible-algorithms
flex-algo 128 <-- This is the ISIS algorithm the router is intending to support
advertise "My128” <-- This is binding with a locally configured fad (optional requirement)
participate <-- with this the router will try to participate in a flex-algo 128 if the winning fad can be supported
exit
no shutdown
exit
@gvandeve
I have added the participate bool. Both advertise and participate set a false does not make sense here but I couldn't think of a better way
Many thanks. There is benefit for both 'participate' and 'advertised' configuration options.
Sorry for not being clear. Having the option to just advertise sounds good to me. I was pointing out that a config that has both participate=false and advertise=false is not useful as it is a no-op. When both are false neither it will advertise nor it will participate. But I guess it is ok!
could we remove the algorithm out of the fad configuration? it seems to be more inline with your EOS config sniplet
In EOS, the algorithm is actually tied in the FAD definition itself:
router traffic-engineering
flex-algo
flex-algo 128 HFT
This config gives a name HFT to the actual algorithm value 128
router isis Amun
...
segment-routing mpls
flex-algo HFT level-1 advertised
This config picks HFT config and advertises as algorithm 128 in the IGP. So in EOS we need the algorithm->name map even is IS-IS just wants to participate in an algorithm and not advertise FAD.
Is it ok to retain it this way and SROS can probably fetch the algorithm from the flex-algorithm config and use it IS-IS?
@vivek-ilangovan
Is it ok to retain it this way and SROS can probably fetch the algorithm from the
flex-algorithmconfig and use it IS-IS?
It is different hierarchy structure used. I suspect with proposed config model that Nokia SROS must deviate by using a flex-algo name that looks like integer value [128-255]. This means that name and algorithm are contained in single parameter (i.e. 129). Having flex-algo definition decoupled from the algorithm seems more flexible to me on the long run.
@gvandeve
It is different hierarchy structure used. I suspect with proposed config model that Nokia SROS must deviate by using a flex-algo name that looks like integer value [128-255]. This means that name and algorithm are contained in single parameter (i.e. 129). Having flex-algo definition decoupled from the algorithm seems more flexible to me on the long run.
I don't think we need to have a flex-algo name that looks like integer.
A sample open-config configuration might be something like this:
+--rw flex-algorithms
| +--rw algorithm* [name]
| +--rw name -> ../config/name
| +--rw config
| | +--rw name? string. =====> "My128"
| | +--rw flex-algo-id flex-algo-id. =====> 128
Flex-algo name and flex-algo-id are configured
+--rw isis
| +--rw global
...
| | +--rw segment-routing
| | | +--rw config
| | | | +--rw enabled? boolean
...
| | | +--ro state
| | | | +--ro enabled? boolean
...
| | | +--rw fad-bindings
| | | +--rw fad-binding* [flex-algo-name]
| | | +--rw flex-algo-name -> ../config/flex-algo-name
| | | +--rw config
| | | | +--rw flex-algo-name? =====> "My128"
IS-IS uses flex-algo name that is configured earlier
I am assuming SROS should then save the name to flex-algo-id map i.e. "My128"->128 when the "flex-algorithms" config is pushed. And use the flex-algo-id 128 when the "isis" config is pushed to configure IS-IS with flex-algo 128.
In SROS, the conversion of openconfig to SROS config is possible by keeping a map of the name to flex-algo-id map.
But in your suggestion, since we will not have algo-id in the "flex-algorithms" config, EOS will not be able to convert the config from open-config to EOS config as algorithm is mandatory there. It will have to look into IS-IS specific openconfig to find the matching algorithm number and in future if OSPF is supported then it might have a different algorithm number altogether causing conflict of algorithm number for the same flex-algo name
@vivek-ilangovan
I am assuming SROS should then save the name to flex-algo-id map i.e. "My128"->128 when the "flex-algorithms" config is pushed. And use the flex-algo-id 128 when the "isis" config is pushed to configure IS-IS with flex-algo 128.
In SROS, the conversion of openconfig to SROS config is possible by keeping a map of the name to flex-algo-id map.
There are few possibilities that may work reasonably well for SROS using the proposed flex-algo model. Thanks Vivek.
Thank you @gvandeve for reviewing this! Can you approve this review or do you know who can help in approving this.?Currently it is blocked with "Review required"
@dplore can you help in approving this? or can you point me to this correct person?
Thank you @gvandeve for reviewing this! Can you approve this review or do you know who can help in approving this.?Currently it is blocked with "Review required"
Apologies for delay. I lost track of this. I can not approve myself, but can talk to a colleague belonging to the approval chain.
@dplore From Nokia perspective the proposed model reflects meaningful functionality documented by Flex-Algo RFC9350. In addition the proposed model, while not fully aligned with Nokia yang model, is reasonably close and represents a functional configuration tree.
Hi,
Proxying some comments on this model from an internal expert (and author of RFC 9350):
-
Flex-algo affinities are encoded using ASLA, which is different to affinities used for MPLS TE. As such referring to some TE related config does not seem to be correct. The mapping for the flex-algo ASLA affinity bits should be independent of the TE affinity mapping.
-
Enabling flex-algo per level - I'm not sure how useful that is and what value does it bring?
-
They have defined the association between the interface's prefix and flex-algo specific SIDs. That works for the SR-MPLS. In SRv6 and IP flex-algo there are no SIDs, the prefix itself is bound to the flex-algo.
Do the YANG tree structures at the top of this review still represent the proposed configuration?
Thanks, Rob
Hi @rgwilton
Thanks for the comments
- Flex-algo affinities are encoded using ASLA, which is different to affinities used for MPLS TE. As such referring to some TE related config does not seem to be correct. The mapping for the flex-algo ASLA affinity bits should be independent of the TE affinity mapping.
Makes sense. I have created a new flex-algo-global-attributes and flex-algo-interface-attributes and referring to that in the flex-algo definition. The attributes are mostly copied from the mpls container @gvandeve can you please help review this part again where I have added the attributes to flex-algorithms container now.
- Enabling flex-algo per level - I'm not sure how useful that is and what value does it bring?
Arista EOS supports assigning different flex-algo to different levels. So I would like to retain it. Other vendors can probably set the level as level-1-2 in case they do not have that support?
- They have defined the association between the interface's prefix and flex-algo specific SIDs. That works for the SR-MPLS. In SRv6 and IP flex-algo there are no SIDs, the prefix itself is bound to the flex-algo.
I thought of initially supporting the SR-MPLS flex-algo segment for now. Is it ok to add the support for srv6 flex-algo and ip flex-algo later?
Do the YANG tree structures at the top of this review still represent the proposed configuration?
I have updated now with the suggested comments.
Thanks, -Vivek
@dplore just wanted to check with you if this is in a state to be accepted
We will discuss at OC Operators meeting on July 11, 2023
Thanks for discussing about this PR!
Thanks for making the flex algo ID the key, this seems appropriate.
Are there any well known / rfc defined flexalgo ID’s? I didn't see any at the IANA registry but I am not sure I am looking in the right place.