Hi Ketan, I’ve cleared my discuss.
Regards, Rob From: iesg <iesg-boun...@ietf.org> On Behalf Of Ketan Talaulikar Sent: 10 October 2022 14:34 To: Rob Wilton (rwilton) <rwil...@cisco.com> Cc: The IESG <i...@ietf.org>; draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) <a...@cisco.com> Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS) Hi Rob, Please check inline below for responses with KT2 to the open comments. We have also posted an update with the changes as discussed below: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-reverse-metric-12 On Mon, Oct 10, 2022 at 6:18 PM Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: Hi Ketan, Please see inline … From: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Sent: 06 October 2022 12:58 To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-lsr-ospf-reverse-met...@ietf.org<mailto:draft-ietf-lsr-ospf-reverse-met...@ietf.org>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto:lsr@ietf.org>; cho...@chopps.org<mailto:cho...@chopps.org>; Acee Lindem (acee) <a...@cisco.com<mailto:a...@cisco.com>> Subject: Re: Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS) 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<mailto: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. Sure. Presumably you mean both on the devices that will transmit the RM and also devices that will receive them? KT2> Correct. 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. Okay, it is only the feature enablement that I am concerned with, with my reading of the text implying that the feature to accept RM values must (perhaps only) be configurable on a per interface basis. KT2> The "only" part is not there. The point was that the operator needs to have an option for control at each link level. It does not preclude hierarchical config. Specifically, it is this text that I have an issue with: Implementations MUST NOT accept the RM from its neighbors by default and MUST 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 think that this text should be changed to explicitly acknowledge or allow hierarchical configuration. E.g., something along the lines of: Implementations MUST NOT accept the RM from neighbors by default. Implementations MAY provide configuration to accept the RM globally on the device, or per area, but Implementations MUST support configuration to enable/disable acceptance of the RM from neighbors on specific links. This is to safeguard against inadvertent use of RM. KT2> Sure. Updated as suggested. 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. Sounds good. Thanks. Two typos in your -11 text: introduce -> introduced, as augmentation -> as an augmentation KT2> Ack Thanks, Ketan (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. Okay. Thanks, Rob Thanks, Ketan Regards, Rob
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
