Hi Rob, We've posted an update to include the changes discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-10
Thanks, Ketan On Thu, Oct 6, 2022 at 5:28 PM Ketan Talaulikar <[email protected]> wrote: > 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 < > [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
