Hi Rob, We have posted a further update: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-11
Please let us know if further updates or clarifications are needed to address your DISCUSS and comments. Thanks, Ketan On Thu, Oct 6, 2022 at 8:32 PM Ketan Talaulikar <[email protected]> wrote: > 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
