Thanks Rob.
On Mon, Oct 10, 2022 at 7:23 PM Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > 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> > wrote: > > Hi Ketan, > > > > Please see inline … > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > *Sent:* 06 October 2022 12:58 > *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, > > > > 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. > > > > 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
