Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
Thanks Rob. On Mon, Oct 10, 2022 at 7:23 PM Rob Wilton (rwilton) wrote: > Hi Ketan, > > > > I’ve cleared my discuss. > > > > Regards, > > Rob > > > > > > *From:* iesg *On Behalf Of *Ketan Talaulikar > *Sent:* 10 October 2022 14:34 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; > lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) > *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) > wrote: > > Hi Ketan, > > > > Please see inline … > > > > *From:* Ketan Talaulikar > *Sent:* 06 October 2022 12:58 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; > lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) > *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 coar
Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
Hi Ketan, I’ve cleared my discuss. Regards, Rob From: iesg On Behalf Of Ketan Talaulikar Sent: 10 October 2022 14:34 To: Rob Wilton (rwilton) Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 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) mailto:rwil...@cisco.com>> wrote: Hi Ketan, Please see inline … From: Ketan Talaulikar mailto:ketant.i...@gmail.com>> Sent: 06 October 2022 12:58 To: Rob Wilton (rwilton) mailto:rwil...@cisco.com>> Cc: The IESG 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) 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 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 nee
Re: [Lsr] 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) wrote: > Hi Ketan, > > > > Please see inline … > > > > *From:* Ketan Talaulikar > *Sent:* 06 October 2022 12:58 > *To:* Rob Wilton (rwilton) > *Cc:* The IESG ; > draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; > lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) > *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
Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
Hi Ketan, Please see inline … From: Ketan Talaulikar Sent: 06 October 2022 12:58 To: Rob Wilton (rwilton) Cc: The IESG ; draft-ietf-lsr-ospf-reverse-met...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; cho...@chopps.org; Acee Lindem (acee) 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 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? 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. 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. 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
Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
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 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 > 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 < >> 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 >>>
Re: [Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
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 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 < > 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
Re: [Lsr] 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. > 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
[Lsr] Robert Wilton's Discuss on draft-ietf-lsr-ospf-reverse-metric-09: (with DISCUSS)
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? Or is the main goal to simplify the coordination of changing the metric at both ends of the link at the same time? 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. 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. (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? In this scenario, is the expectation that the configuration to accept reverse-metrics would just be left always enabled on the CE device? Is this a security concern? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
