Mohamed Boucadair has entered the following ballot position for draft-ietf-lsr-anycast-flag-09: No Objection
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-anycast-flag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Ran, Detao, Peter, Ketan, and Changwang, Thank you for the effort put into this specification, which is about mirroring a functionality already specified for IS-IS and OSPFv3. Thanks to Juergen for the OPSDIR review and Ran for engaging. Some of the replies in the thread are better if echoed in the document (e.g., backward compatibility mention). I would ballot Yes if two first points below were addressed. I have two main points and a set of more low-level comments: # Summarization CURRENT: The AC-flag MUST be preserved when re-advertising the prefix across areas. Wouldn’t that be lost if the prefix is covered a summarized adv by an ABR? Maybe tweak this as? NEW: The AC-flag MUST be preserved when the OSPFv2 Extended Prefix Opaque LSA is propagated between areas. # Operational Considerations ## Consistent configuration In addition to the backward compatibility mentioned above, I would add a brief discussion that basically say that anycast prefixes should be consistently managed through the network. Stale configuration of a prefix tagged as anycast may have implications as that value will take precedence over other same prefix announcement with AC-flag set to 0. ## Anomalies You may also add a point retrieval of a router configuration having N-flag and AC-flag set to 1 for a given prefix should be used as an indication of configuration anomaly. Alos, consider adding a point that receipt of adv with both N-flag and AC-flag set to 1 can be used as an indication of configuration anomaly. This can be used by a network controller. BTW, how such function is supposed to be done using the YANG-based interface? Is retrieval of prefix flags from peers covered by the base YANG OSPF module? If so, please add a mention of the data nodes used for that purpose. ## Please find below some additional comments, fwiw: ## Identifier CURRENT: It is useful for other routers to know that the advertisement is for an anycast identifier. I appreciate this text is grabbed from SR OSPF/IS-IS extension, but I would s/anycast identifier/ anycast prefix ## Mention the YANG augmentation in the abstract OLD: This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. NEW: This document defines a new flag in the OSPFv2 Extended Prefix TLV Flags to advertise the anycast property. The document also specifies a companion YANG module for managing this function. You may consider a mention in the introduction as well. ## set/clear You may add a mention to say that “set” meant “set to 1” and “clear” means “set to 0”. ## Curiosity CURRENT: When a prefix is configured as anycast, the AC-flag MUST be set Just out of curiosity, why the WG went for a distinct behavior for the IS-IS part as RFC9352 has: “When the prefix/SRv6 Locator is configured as anycast, the A-flag SHOULD be set” ## Manage vs configure OLD: This section defines a YANG data model that can be used to configure and manage the usage of OSPFv2 Anycast Property as defined in this NEW: This section defines a YANG data model that can be used to manage the usage of OSPFv2 Anycast Property as defined in this “configure” is one of the management (FCAPS) function ## nit OLD: The following show the tree diagram of the module: NEW: The following shows the tree diagram of the module: ## No need to have the NMDA mention in the module (*) Consider deleting: CURRENT: This YANG module conforms to the Network Management Datastore Architecture (NMDA) as described in RFC 8342. ## The module is not only about configuration, but also retrieval (*) (1) OLD: "This YANG module adds the support of configuring an OSPFv2 prefix as anycast. NEW: "This YANG module adds the support of managing an OSPFv2 prefix as anycast. (2) Delete: OLD: /* Configuration */ (3) OLD: "This augments the OSPFv2 interface configuration."; NEW: "This augments the OSPFv2 interface."; (4) OLD: "This augments OSPFv2 interface configuration with anycast NEW: "This augments OSPFv2 interface with anycast ## Update to follow the IETF template + no need to have a reference clause OLD: This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; reference "RFC XXXX"; NEW: All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; ## This is an identity, not a boolean “when set” does not parse here. OLD: description "Anycast flag. When set, it indicates that the prefix is configured as anycast."; NEW: description "Indicates that the prefix is configured as anycast."; ## Data node description OLD: leaf anycast-flag { type boolean; default "false"; description "Sets the prefix as an anycast address."; NEW: leaf anycast-flag { type boolean; default "false"; description “Indicates that the prefix is an anycast address, if set to 1. It indicates a node-specific prefix if set to 0."; ## Please update Section 6 to follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#name-security-considerations-sect ## These are not normative ### Move RFC6241 and RFC8040 to be listed as Informative ### I don’t think RFC9085 is normative, but I leave it to you to double check. Cheers, Med _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
