[Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Yes 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-ospfv3-extended-lsa-yang/ -- COMMENT: -- Thanks for publishing another YANG model. I do have a little sympathy to Roman's comment that having a bit more descriptive prose at the beginning of this document might be helpful to readers (i.e., I'm thinking in the order of one or two paragraphs). But at the same time, I can also see that repeating (or perhaps summarising) what is already written in another RFC isn't necessarily that helpful, and having the details in the YANG module itself is arguably the most important and useful place because then the tooling can build appropriate GUI help text or user documentation. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-area-proxy-10: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-isis-area-proxy-10: 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-isis-area-proxy/ -- COMMENT: -- Hi, Thanks for this document. I'm not a routing expert, but it does feel that this is somewhat pushing IS-IS beyond its core competency. However, this is obviously just an experimental draft and may be a pragmatic engineering solution to the problem, hence the no obj ballot. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ip-flexalgo-12: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ip-flexalgo-12: 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-ip-flexalgo/ -- COMMENT: -- Hi, Thanks for this document. Only one minor comment/question: (1) p 4, sec 5.1. The IS-IS IP Algorithm Sub-TLV The use of the IP Algorithm Sub-TLV to advertise support for algorithms outside the Flex-Algorithm range (128-255) is outside the scope of this document. What does this actually mean if a router receives a SubTlV containing an algorithm outside the 128-255 range? Should it ignore, or error? And should this be specified in this document? I also note that this is stated here, under IS-IS, but there is no equivalent text for the OSPF definition, and hence wanted to ensure that is intentional. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's Yes on draft-ietf-lsr-rfc8919bis-03: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-rfc8919bis-03: Yes 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-rfc8919bis/ -- COMMENT: -- Thank you for taking the time/effort to update the specification to make it clearer. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-rfc8920bis-04: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-rfc8920bis-04: 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-rfc8920bis/ -- COMMENT: -- Thanks for this update. I reviewed the diff for -04, and then saw Warren's ballot comment against -02. I don't know if the intent is that Warren's comment has already been addressed, but I would give a +1 to a sentence in the introduction briefly explaining the update and forward referencing section 15. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-flood-reflection-11: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-isis-flood-reflection-11: 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-isis-flood-reflection/ -- COMMENT: -- Hi, Thanks for this document, I found it pretty clear and easy to read (although, I skipped the TLV specifications). A couple of minor comments/nits that may help improve the doc: Minor level comments: (1) p 18, sec 9. Security Considerations subversion of the IS-IS level 2 information. Therefore, at tunnel level steps should be taken to prevent such injection. I didn't find the term "tunnel level" to be particularly clear, either here, or below. Nit level comments: (2) p 8, sec 3. Further Details One possible solution to this problem is to expose additional topology information into the L2 flooding domains. In the example network given, links from router 01 to router 02 can be exposed into L2 even when 01 and 02 are participating in flood reflection. This information would allow the L2 nodes to build 'shortcuts' when the L2 flood reflected part of the topology looks more expensive to cross distance wise. Should 01 and 02 be R1 and R2 respectively? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-pce-discovery-security-support-13: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-13: 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-pce-discovery-security-support/ -- COMMENT: -- Discuss cleared, thanks for accommodating my concerns. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-reverse-metric-12: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-12: 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-ospf-reverse-metric/ -- COMMENT: -- Discuss cleared. Thanks for accommodating my concern. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-bfd-strict-mode-09: Yes 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-bfd-strict-mode/ -- COMMENT: -- Thanks for this document. I think that what is being proposed here is useful. A few minor/nit comments that may improve this document. Minor level comments: (1) p 6, sec 5. Operations & Management Considerations Not for this document, and ss per my other OSPF ballots, I assume that the LSR WG will update the OSPF YANG model will be updated to accommodate this feature. (2) p 6, sec 5. Operations & Management Considerations In network deployments with noisy or degraded links with intermittent packet loss, BFD sessions may flap resulting in OSPF adjacency flaps. This in turn may cause routing churn. The use of OSPF BFD strict- mode along with mechanisms such as hold-down (a delay in the initial OSPF adjacency bringup following BFD session establishment) and/or dampening (a delay in the OSPF adjacency bringup following failure detected by BFD) may help reduce the frequency of adjacency flaps and therefore reduce the associated routing churn. The details of these mechanisms are outside the scope of this document. For my understanding, is the expectation that if a device supports this feature then it would (or is that SHOULD) be enabled automatically? Nit level comments: (3) p 6, sec 6. Backward Compatibility established successfully. Implementations MAY provide a local configuration option to enable BFD without the strict-mode which results in the router not advertising the B-bit and BFD operation being performed in the same way as prior to this specification. I find the text about enable BFD without the strict-mode to be slightly unclear, since presumably it is the OSPF interactions with BFD that the configuration is referred to, rather than BFD itself. Perhaps changing "strict-mode" to "OSPF BFD strict-mode" might be clearer. ___ 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
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-flex-algo-24: 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-flex-algo/ -- COMMENT: -- Hi, Thanks for this document. I don't really have much to say. I was slightly surprised by the IPR declaration 3910, which unless I am misreading it, seems to be asserting possible IPR on the BCP 14 text (i.e., section 2 of revision 03)! Perhaps worth flagging to see if an update to the IPR declaration is needed? One minor nit: (1) p 3, sec 1. Introduction This document also specifies a way for a router to use IGPs to associate one or more Segment Routing with the MPLS Data Plane (SR- MPLS) Prefix-SIDs [RFC8660], or Segment Routing over IPv6 (SRv6) locators [RFC8986] with a particular Flex-Algorithm. I found this sentence clunky to parse/understand - possibly putting quotes around "Segment Routing with the MPLS Data Plane" and "Segment Routing over IPv6 (SRv6) locators" would help. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-11: 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-pce-discovery-security-support/ -- DISCUSS: -- Hi, Sorry for the discuss, but I find a couple of specification aspects of this draft to be unclear enough that I think that they probably warrant a discuss, hopefully easy to explain or resolve: In section 3.2, it wasn't clear to me exactly where I find what the Key-Id is. I suspect that this is probably referring to "KeyId" in rfc5925. If so, I think that would be emphasizing. In section 3.3, it wasn't clear to me what the Key chain name is, or what exactly it refers to. Is this referring to a local key-chain name installed in a YANG Keystore (given that there is a reference to RFC8177) or something else. Either way, I think that expanding on the description here would probably be very beneficial. -- COMMENT: -- One minor comment. I noted that the description of the Key-Id slightly differed for the OSPF encoding vs ISIS encoding and I wanted to check that the difference was intentional. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-06: 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-ospf-l2bundles/ -- COMMENT: -- Hi, I support Lars's discuss. I don't really object to publishing this document, although I don't really like the fact that the LAG member information that is being propagated isn't of any relevance to OSPF routing itself, and OSPF is being used only as a generic information propagation mechanism. However, I acknowledge that horse has probably bolted long ago. One point that is not clear to me, is the configuration/management of this feature: Is the expectation that OSPF implementations that support this RFC would automatically propagate bundle member information? Or would this be disabled by default and need to be enabled through configuration? If there is configuration associated with this feature then would it be part of a updated version of the standard OSPF YANG model, or is it via YANG module augmentation to the base OSPF YANG module? If this is configurable then having an informational reference to how/where this OSPF feature can be configured would likely be helpful. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-isis-rfc5316bis-04: 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-isis-rfc5316bis/ -- COMMENT: -- I support Alvaro's discuss. I would like to thank Menachem for the OPSDIR review. I also have a few minor nits for the authors to consider: (1) p 3, sec 2. Problem Statement Two methods for determining inter-AS paths are currently being discussed. It was unclear what is meant by this, please clarify. I.e., Do you mean described in this document? Or there is ongonig discussion in the WG? Or ... (2) p 5, sec 2.2. Per-Domain Path Determination Suppose that the Path message enters AS2 from R3. The next hop in the ERO shows AS3, and R5 must determine a path segment across AS2 to reach AS3. It has a choice of three exit points from AS2 (R6, R7, and R8), and it needs to know which of these provide TE connectivity to AS3, and whether the TE connectivity (for example, available bandwidth) is adequate for the requested LSP. Alternatively, if the next hop in the ERO is the entry ASBR for AS3 (say R9), Should this be "an entry ASBR" rather than "the entry ASBR"? (3) p 7, sec 3. Extensions to ISIS-TE Also, two other new sub-TLVs are defined for inclusion in the IS-IS router capability TLV to carry the TE Router ID when the TE Router ID is needed to reach all routers within an entire IS-IS routing domain. As a nit, I would put the last sentence above into its own paragraph. "This document also defines two other new sub-TLVs ..." (4) p 8, sec 3.1. Inter-AS Reachability TLV Rsvd bits MUST be zero when originated and ignored when received. Perhaps "Reserved (Rsvd) bits MUST be zero ..." ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-yang-isis-reverse-metric-04: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-yang-isis-reverse-metric-04: 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/blog/handling-iesg-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-yang-isis-reverse-metric/ -- COMMENT: -- Hi Chris, Thanks for this YANG module. Nit: - Copyright statement in the YANG module should presumably be updated to 2021, to match the revision entry. A few comments on the YANG model: - For the interface config, reverse-metric turns up twice in the path. You could perhaps drop it from the grouping so that it only appears once? - Would it be helpful to make the top level reverse-metric container have presence? This might make more sense if constraints are ever added to validate that a metric is specified at the top level, or under at least one of the levels. - Am I right in assuming that that the level-1/level-2 config is effectively hierarchical and would override the config under the reverse-metric grouping? E.g., is it allowed to specify a metric at the top level, and the whole-lan flag only under the level-1? If so, would it be helpful to document this hierarchical behaviour in the description for the fields? - There is a default assigned to exclude-te-metric, but no default assigned to whole-lan and allow-unreachable. If the config is not hierarchical, then should these all have defaults? If the config is hierarchical then perhaps they should not have any defaults, and the use statement for the top level reverse-metric grouping should refine them with default values? Assuming that the descriptions make their hierarchical nature clear? Security Considerations: Would it also be helpful to include a reference back to the security considerations of the base ISIS YANG module, since the concerns that apply to metrics there would seem to mostly also apply here. References: - Probably need to add XML and JSON references or otherwise change the requests to edit-config or RESTCONF requests. - XML reference can be as per RFC 8342, JSON should probably be to RFC 7951. A.1. Example Enable XML Suggest retitling to: Enablement Example Using XML YANG Instance Data" A.2. Example Use XML Suggest retitling to: "Usage Example using XML YANG Instance Data" A.3. Example JSON Suggest retitling to: "Usage Example using JSON YANG Instance Data" Thanks, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-isis-srv6-extensions-14: 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/ -- COMMENT: -- Hi, Thanks for this document. In various places, this document references lists of numerical algorithm numbers, or TLV Ids without any associated human names. I would have found this document to be a bit more readable if the names of the algorithms and TLVs were also used alongside their numerical ids. Thanks, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-ospf-prefix-originator-10: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/ -- COMMENT: -- Thanks for this. Not a comment that requires addressing in the text, but considering section 5 on the operational impact: Is there an OSPF YANG model that is being updated to cover any additional configuration required to enable this functionality on a subset of prefixes, and/or are any changes to the operational YANG data model required to express the prefix source? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-lsr-isis-invalid-tlv-02: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-lsr-isis-invalid-tlv-02: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-invalid-tlv/ -- COMMENT: -- The document is short and easy to read, thanks! However, I was sure whether I should put a DISCUSS on this document for section 3.4. I find that the quoted paragraph from RFC6232 to be badly worded: "The POI TLV SHOULD be found in all purges and MUST NOT be found in LSPs with a non-zero Remaining Lifetime." Taking a strict reading of this, my interpretation is that an implementation is not compliant to RFC 6232 if it happens to receive a POI TLV in an LSP with non-zero remaining lifetime! Further, this text then arguably conflicts with earlier parts of this document regarding how unrecognized or bad TLVs should be handled. Hence, given that RFC6232 is being updated, I would prefer it if this document also updated RFC6232 to clarify the above paragraph to something like: "The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime." One other minor comment: It is RECOMMENDED that implementations provide controls for the enablement of behaviors that are not backward compatible. Is this covered by the existing ISIS YANG model, or included in the latest update to that YANG model? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-ospf-te-link-attr-reuse-15: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-15: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ -- COMMENT: -- Discuss cleared. Thank you for addressing my comments. Two possible nits in section 5: If the same attribute is advertised in more than single ASLA sub-TLVs with the application listed in the Application Bit Masks, the application SHOULD use the first instance of advertisement and ignore any subsequent advertisements of that attribute. Propose changing "single" to "one". If link attributes are advertised associated with zero length Application Identifier Bit Masks for both standard applications and user defined applications, then any Standard Application and/or any User Defined Application is permitted to use that set of link attributes. Propose changing "associated with" to "with associated" or just "with" Thanks, Rob Previous discuss comments: I found parts of this document hard to understand, but I'm not familiar with the specifics of the protocols. This discuss is in the vein of "I think that folks might struggle to implement this correctly/consistently". In particular I had some questions/concerns about section 5 which, if clarified, would probably help this document. In Section 5: The ASLA sub-TLV is an optional sub-TLV and can appear multiple times in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA sub-TLV MUST be used for advertisement of the link attributes listed at the end on this section if these are advertised inside OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. It has the following format: I think that it would be useful to clarify when/why the ASLA sub-TLV can be included multiple times. I.e. when different applications want to control different link attributes. Standard Application Identifier Bits are defined/sent starting with Bit 0. Undefined bits which are transmitted MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. Bits that are not supported by an implementation MUST be ignored on receipt. It was not clear to me what it means if the SABM (or UDABM) fields are entirely empty. This paragraph states that they are treated as if they are 0, but sections 8 and 11 imply that if the field is omitted then it acts as if all applications are allowed. Section 12.2 implies that if the field is omitted then it is as if all applications are allowed unless there there is another ASLA with the given application bit set, in which case it is treated as being a 0 again. I think that this document would be helped if the specific behaviour was defined in section 5, retaining the justification/clarification in the subsequent sections. It is also not entirely clear to me exactly how the bits are encoded on the wire. My assumption is that if bit 0 is set, then this would sent the highest bit of the first byte. E.g. 0x80? Is that correct? If not, then I think that the document needs more text, if so, then an example of the encoding may still aid readability. User Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body. It is recommended that bits are used starting with Bit 0 so as to minimize the number of octets required to advertise all UDAs. Doesn't this need more constraints to ensure easy interop (i.e. bits default to 0). Otherwise, it would seem that anyone is allowed to put any value in this field that they like that could harm interop, or otherwise it might be tricky to compare a 4 byte UDABM to an 8 byte UDABM? This document defines the initial set of link attributes that MUST use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV. Documents which define new link attributes MUST state whether the new attributes support application specific values and as such MUST be advertised in an ASLA sub-TLV. The link attributes that MUST be advertised in ASLA sub-TLVs are: I think that I get what this means, but I find the last two sentences slightly jarring given than the ASLA TLV is optional. Perhaps predicate both of these constraints with "(if supproted)". E.g., something like, Documents which define new link
[Lsr] Robert Wilton's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-isis-te-app-14: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ -- COMMENT: -- I'm not sure whether this should really be a discuss ... I raised a similar concern on the OSPF document as part of a discuss, and presume consistency is helpful. 4.1. Application Identifier Bit Mask UDABM Length: Indicates the length in octets (0-8) of the User Defined Application Identifier Bit Mask. The length SHOULD be the minimum required to send all bits which are set. User Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body. It is recommended that bits are used starting with Bit 0 so as to minimize the number of octets required to advertise all UDAs. In section 4.1, I think that the document should also add the sentence (taken from the previous paragraph) "Bits that are not transmitted MUST be treated as if they are set to 0 on receipt." Note, that I also think that this behaviour is implicitly required from the description of UDABM Length. Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS)
Robert Wilton has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-14: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse/ -- DISCUSS: -- I found parts of this document hard to understand, but I'm not familiar with the specifics of the protocols. This discuss is in the vein of "I think that folks might struggle to implement this correctly/consistently". In particular I had some questions/concerns about section 5 which, if clarified, would probably help this document. In Section 5: The ASLA sub-TLV is an optional sub-TLV and can appear multiple times in the OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. The ASLA sub-TLV MUST be used for advertisement of the link attributes listed at the end on this section if these are advertised inside OSPFv2 Extended Link TLV and OSPFv3 Router-Link TLV. It has the following format: I think that it would be useful to clarify when/why the ASLA sub-TLV can be included multiple times. I.e. when different applications want to control different link attributes. Standard Application Identifier Bits are defined/sent starting with Bit 0. Undefined bits which are transmitted MUST be transmitted as 0 and MUST be ignored on receipt. Bits that are not transmitted MUST be treated as if they are set to 0 on receipt. Bits that are not supported by an implementation MUST be ignored on receipt. It was not clear to me what it means if the SABM (or UDABM) fields are entirely empty. This paragraph states that they are treated as if they are 0, but sections 8 and 11 imply that if the field is omitted then it acts as if all applications are allowed. Section 12.2 implies that if the field is omitted then it is as if all applications are allowed unless there there is another ASLA with the given application bit set, in which case it is treated as being a 0 again. I think that this document would be helped if the specific behaviour was defined in section 5, retaining the justification/clarification in the subsequent sections. It is also not entirely clear to me exactly how the bits are encoded on the wire. My assumption is that if bit 0 is set, then this would sent the highest bit of the first byte. E.g. 0x80? Is that correct? If not, then I think that the document needs more text, if so, then an example of the encoding may still aid readability. User Defined Application Identifier Bits have no relationship to Standard Application Identifier Bits and are not managed by IANA or any other standards body. It is recommended that bits are used starting with Bit 0 so as to minimize the number of octets required to advertise all UDAs. Doesn't this need more constraints to ensure easy interop (i.e. bits default to 0). Otherwise, it would seem that anyone is allowed to put any value in this field that they like that could harm interop, or otherwise it might be tricky to compare a 4 byte UDABM to an 8 byte UDABM? This document defines the initial set of link attributes that MUST use the ASLA sub-TLV if advertised in the OSPFv2 Extended Link TLV or in the OSPFv3 Router-Link TLV. Documents which define new link attributes MUST state whether the new attributes support application specific values and as such MUST be advertised in an ASLA sub-TLV. The link attributes that MUST be advertised in ASLA sub-TLVs are: I think that I get what this means, but I find the last two sentences slightly jarring given than the ASLA TLV is optional. Perhaps predicate both of these constraints with "(if supproted)". E.g., something like, Documents which define new link attributes MUST state whether the new attributes support application specific values and as such MUST be advertised in an ASLA sub-TLV (if supported). The link attributes that MUST be advertised in ASLA sub-TLVs (if supported) are: Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-isis-mpls-elc-12: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-isis-mpls-elc/ -- COMMENT: -- Hi, Same comment as for equivalent OSPF draft. Is there any associated YANG module required to manage this protocol enhancement? If so, is that already being worked or, or planned work for the WG? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Robert Wilton's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
Robert Wilton has entered the following ballot position for draft-ietf-ospf-mpls-elc-13: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-mpls-elc/ -- COMMENT: -- Hi, This is a straight forward document, thanks. Is there any associated YANG module required to manage this protocol enhancement? If so, is that already being worked or, or planned work for the WG? Regards, Rob ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
