Topology and FC properties Nigel Davis 20190316

Properties considered Risk Transfer Cost Transfer Timing Transfer Capacity Transfer Integrity Validation Layer Transition

Specific properties

Understanding the parameters Identify essential properties For a bidirectional Forwarding entity there could be properties on bidirectional entity or distinct properties on subordinate unidirectional entity The properties can be applied to any lifecycle stage: Constraints on intent Retrieved settings from actual The properties are not all measurable from the actual information flow

Refactoring the Essential Properties Requested/Intended For all adjustable parameters it is reasonable to state constraints in an outcome oriented constraint based interaction. Target (average/mean) ToleranceLower (deviation) ToleranceUpper (deviation) Current/actual – measure A key consideration is the degree of change of the property. If it changes rarely then notification is reasonable, if it changes frequently or in bursts, then notification may not be sensible other than for spotlighting. instantaneousState instantaneousValue averageMean currentEventCounts

Refactoring the Essential Properties Threshold – measure Any measure may require a combination of thresholds. In some cases the best value is zero and hence only upper threshold are meaningful. lowerWatermark upperWatermark LowerWarn LowerSevere LowerFail NoValueWarn NoValueSevere NoValueFail UpperWarn UpperSevere UpperFail TimePeriod

Refactoring the Essential Properties Alarms BooleanAlarm Capability (requested/intended, current, threshold and alarms) For all parameters there will be definition. The degree of support for each may vary in terms of range supported etc. Default Range Preference Interaction

Risk The risk characteristics of a ForwardingEntity come directly from the underlying physical realization. The risk characteristics propagate from the physical realization to the client and from the server layer to the client layer; this propagation may be modified by protection. A ForwardingEntity may suffer degradation or failure as a result of a problem in a part of the underlying physical realization. The physical realization can be partitioned into segments which have some relevant common failure modes. There is a risk of failure/degradation of each segment of the underlying physical realization. Each segment is a part of a larger physical/geographical unit that behaves as one with respect to failure (i.e. a failure will have a high probability of impacting the whole unit (e.g. all cables in the same duct). Disruptions to that larger physical/geographical unit will impact (cause failure/errors to) all ForwardingEntities that use any part of that larger physical/geographical entity. Any ForwardingEntity that uses any part of that larger physical/geographical unit will suffer impact and hence each ForwardingEntity shares risk. The identifier of each physical/geographical unit that is involved in the realization of each segment of a ForwardingEntity can be listed in the RiskParameter_Pac of that ForwardingEntity. A segment has one or more risk characteristic. Shared risk between two ForwardingEntities compromises the integrity of any solution that use one of those ForwardingEntity as a backup for the other. Where two ForwardingEntities have a common risk characteristic they have an elevated probability of failing simultaneously compared to two ForwardingEntities that do not share risk characteristics. The risk characteristics cannot be determined by reading properties of monitorable equipments. They are derived from an analysis of the physical/geographical/political/commercial etc. landscape.

Risk A list of risk characteristics for consideration in an analysis of shared risk. Each element of the list represents a specific risk consideration. Each element of the list provides the information for a particular risk characteristic where there is a list of risk identifiers related to that characteristic. riskCharacteristicName String The name of the risk characteristic. The characteristic may be related to a specific degree of closeness. For example, a particular characteristic may apply to failures that are localized (e.g. to one side of a road) where as another characteristic may relate to failures that have a broader impact (e.g. both sides of a road that crosses a bridge). Depending upon the importance of the traffic being routed different risk characteristics will be evaluated. riskIdentifier String A list of the identifiers of each physical/geographic unit (with the specific risk characteristic) that is related to a segment of the ForwardingEntity.

Application Intended Current Alarm Capability Shared risk considerations Specific exclusions Current Risk parameters related to current routes Alarm Shared risk violations Capability Sets of risks etc.

Risk Previously, shared risk has been discussed. This could be discussed again at this session. Nearly all of the text in the previous slides was taken directly from the UML model. If the text has proved to be useful, then we can dive into the model for the remainder of the groups of parameters (which do not have the degree of coverage of Risk – we may want to strengthen the documentation as we proceed) with only a light weight coverage in this pack If the risk discussion has not proved useful and has not clarified the application to TAPI then we should discuss what is missing and then step back again to add that to Risk (perhaps in this session)

Transfer Cost Relevant for path computation and path analysis The cost characteristics cannot be determined by reading properties of monitorable equipments. They are derived from an analysis of the physical/geographical/political/commercial etc. landscape. There may be a number of separate cost considerations relating to different dimensions of the solution Each Cost will have some associated algorithm for analysis of the cost properties in the context of the overall network and path through that network The algorithm is essentially a capability consideration, not a consideration per instance Current costName String The cost characteristic will related to some aspect of the ForwardingEntity (e.g. $ cost, routing weight). This aspect will be conveyed by the costName. costValue String The specific cost. costAlgorithm ToBeDefined The cost may vary based upon some properties of the ForwardingEntity. The rules for the variation are conveyed by the costAlgorithm Issues costAlgroithm is not defined String may be too loose Steps and considerations Exploring RFC7285 which has examples of cost characteristics Cost metric and cost mode appear to be name/value and algorithm respectively. Cost mode has two values, numerical and ordinal. Has a cost map to cost Domains (where as we have cost applied via rules in domains – this gives an opportunity for efficient statement of cost but can do per pair) Need to look for further cost considerations It is important that the mechanism is extensive and allows for change It would seem inappropriate to cast only one set of metrics Forward looking Consider generalized component placement Any instance of anything should be considered as cost. In the current model, only FD, FC and Link are allocated cost

Application Intended Current Alarm Capability Shared cost targets Cost parameters related to current routes Alarm Cost target violations Capability Sets of costs etc.

Transfer integrity errorCharacteristic lossCharacteristic Including looks right when actually wrong! lossCharacteristic repeatDeliveryCharacteristic deliveryOrderCharacteristic unavailableTimeCharacteristic  

Application Intended Current Alarm Capability Integrity targets Current intergrity Alarm Integrity violations Capability Sets of integrity statements etc.

Transfer Capacity See model and discuss as per previous section building on capacity discussion from earlier today

Transfer Timing See model and discuss as per previous section

Validation Somewhat different consideration from the previous set… Identifies how an intent was validated to match the actual This is especially relevant for Link but also relevant in some cases for FC As FD is essentially of the same sort as Link it would seem that FD validation should also be considered

Transition Again, a somewhat different consideration Transitional Link consideration and assumes that FD and FC can transition The FC consideration applies to “Transitional Link Connections”, but these are slaves to the Transitional Link