Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-09: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. I support Alvaro's discuss. Having read Alvaro's discuss after writing my ballot comments it seems to be some what closely related, but I am also balloting discuss because I find the operational guidelines to be unclear. (1) p 8, sec 7. Operational Guidelines Implementations MUST NOT signal reverse metric to neighbors by default and MUST provide a configuration option to enable the signaling of reverse metric on specific links. Implementations SHOULD NOT accept the RM from its neighbors by default and SHOULD provide a configuration option to enable the acceptance of the RM from neighbors on specific links. This is to safeguard against inadvertent use of RM. I'm not really sure that I properly understand how this feature works from a manageability perspective. Particularly for your first use case, when considering that the proposal is for per link configuration for the acceptance of RM from neighbours. This would seem to suggest that before you can make use of reverse-metric you have to already have determined the links on the affected devices to then configure them to accept the reverse-metrics, at which point, doesn't this partially defeat the use case? Or is the main goal to simplify the coordination of changing the metric at both ends of the link at the same time? Or is the intention that during the maintenance window the operators would enable the "allow receipt of reverse-metrics" on all links within, say, an area? If so, would hierarchical device and area specific configuration be more appropriate? E.g., allow it to be enabled/disbaled on individual links, but also allow more coarse grained configuration. Not as an update for this document, but I am assuming that the LSR working group with eventually update or augment the OSPF YANG module with standard configuration to support this feature. (2) p 8, sec 7. Operational Guidelines For the use case in Section 2.1, it is RECOMMENDED that the network operator limits the period of enablement of the reverse metric mechanism to be only the duration of a network maintenance window. Presumably this isn't feasible when the CE is not managed by the provider? In this scenario, is the expectation that the configuration to accept reverse-metrics would just be left always enabled on the CE device? Is this a security concern? Regards, Rob _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
