Hi Rob, Thanks for your review and comments/suggestions. Please check inline below for responses.
Will update these changes (and further changes, if required) in the next version once we conclude. On Thu, Oct 6, 2022 at 4:20 PM Robert Wilton via Datatracker < nore...@ietf.org> wrote: > 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? KT> If the operator is using this feature, then it needs to be enabled first. This is a one-time/initial config. > Or is the main goal to simplify > the coordination of changing the metric at both ends of the link at the > same > time? > KT> Correct. The advertisement of reverse metric is applied/triggered on the sending side on-need basis. > > 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. > KT> I would expect the feature enablement (specifically the receiving part) to be on multiple hierarchical levels (instance/area/link). The RM value config for sending is on the link, but for some use cases, it would perhaps be also hierarchical. > > 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. > KT> Ack. Will include the same reference and text that we have discussed for the OSPF L2 bundles draft. > > (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? KT> Correct. > In > this scenario, is the expectation that the configuration to accept > reverse-metrics would just be left always enabled on the CE device? KT> Correct. > Is this a > security concern? > KT> Not sure. If it was left enabled, then it was because the use case warranted it. We also have the log/alert recommended so this can be monitored/reported on the CE device. Thanks, Ketan > > Regards, > Rob > > > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
