[Lsr] Tsvart last call review of draft-ietf-lsr-isis-fast-flooding-07
Reviewer: Mirja Kühlewind Review result: On the Right Track This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. I did an early TSV review a few weeks ago and the current version addresses a lot of the comments and is an improvement. On the high level I still think the document can be further improves by recommending and discussion appropriate default values or values ranges to ensure safe operation as implementors often reply on default value and if no recommendation is given or discussed this can lead easy to a selection of too high values that would overload the other end. Also the congestion control part seems rather complex for a point-to-point connection. I understand that the proposed mechanism was experimented with and showed improvements in case of overload of the internal switch. However, congestion control usually also aims to fully utilise the available resources which is not a goal here and therefore a simpler solution like a circuit breaker would probably be sufficient. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06
Reviewer: Mirja Kühlewind Review result: Not Ready First of all I have a clarification question: The use the of flags TLV with the O flag is not clear to me. Is that also meant as a configuration parameter or is that supposed to be a subTLV that has to be sent together with the PSNP? If it is a configuration, doesn’t the receiver need to confirm that the configuration is used and how does that work in the LAN scenario where multiple configurations are used? If it has to be sent together with the PSNP, this needs to be clarified and it seem a bit strange to me that it is part of the same TLV. Or maybe I’m missing something completely about the flag? Then, generally thank you for considering overload and congestion carefully. Please see my many comments below, however, I think one important part is to ensure that the network/link doesn’t get normally overloaded with the parameter selected. You give some recommendation about parameters to use but not for all and, more importantly, it would be good to define boundaries for safe use. What’s a “safe” min or max value? I know this question is often not easy to answer, however, if you as the expert don’t give the right recommendations, how should a regular implementer make the right choice? Please see further comments below. Section 4.7: “NOTE: The focus of work used to develop the example algorithms discussed later in this document focused on operation over point-to-point interfaces. A full discussion of how best to do faster flooding on a LAN interface is therefore out of scope for this document.” Actually this is quite important and also not clear to me. You do discuss how to interpret parameters in a LAN scenario but then you say you only give proper guidance how to adjust the sending rate for non-LAN. But what’s the right thing to do in LAN then? Why is LAN out of scope? If you don’t give guidance, I think you have to also say that this mechanism that enables using higher values in this document MUST NOT be used on LAN setups. Section 5.1: “The receiver SHOULD reduce its partialSNPInterval. The choice of this lower value is a local choice. It may depend on the available processing power of the node, the number of adjacencies, and the requirement to synchronize the LSDB more quickly. 200 ms seems to be a reasonable value.” Giving some recommended value is fine, however, it would be more important to ensure safe operation to give a range or at least a minimum value. Also on use of normative language. Just saying “The receiver SHOULD reduce its partialSNPInterval.” Is a bit meaningless without saying when and to with value/by how much. I guess you should say something like “partialSNPInterval SHOULD be set to 200ms and MUST NOT be lower than X.” “The LPP SHOULD also be less than or equal to 90 as this is the maximum number of LSPs that can be acknowledged in a PSNP at common MTU sizes, hence waiting longer would not reduce the number of PSNPs sent but would delay the acknowledgements. Based on experimental evidence, 15 unacknowledged LSPs is a good value assuming that the Receive Window is at least 30 and that both the transmitter and receiver have reasonably fast CPUs.” Why is the first SHOULD a SHOULD and not a MUST? What is a reasonable fast CDU? Why would the receive window be 30? Is that also the value that you would recommend? So you maybe more generally aim to recommend to set the LPP to half the Receive Window (or does it have to be those specific values)? Section 5.2: “Therefore implementations SHOULD prioritize the receipt of Hellos and then SNPs over LSPs. Implementations MAY also prioritize IS-IS packets over other less critical protocols.” What do mean by prioritise exactly? I find the second sentence here meaningless when you only say “less critical protocols”. What do you mean by this? How should I as an implementer decide which protocols are more or less critical? Section 6.1: “Congestion control creates multiple interacting control loops between multiple transmitters and multiple receivers to prevent the transmitters from overwhelming the overall network.” This is an editorial comment: I think I know what you mean but the sentence is not clear as there is always only one congestion loop between one transmitter and one receiver. Section 6.2.1: “If no value is advertised, the transmitter should initialize rwin with its own local value.” I think you need to give more guidance anyway but a good buffer size might be. However, if you don’t know the other ends capability, I’m not sure if you own value is a good idea or if it would be better to be rather conservative and select a low value that still provides reasonable performance. Section 6.2.1.1: “The LSP transmitter MUST NOT exceed these parameters. After having sent a full burst of un-acknowledged LSPs, it MUST send the following LSPs with an LSP Transmission Interval between LSP transmissions. For CPU scheduling reasons, this rate may be averaged over a small period, e.g.,
[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-ospf-ospfv2-hbit-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/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-ospfv2-hbit/ -- COMMENT: -- Three comments/questions: 1) This sentence in section 3: "An OSPFv2 router advertising a router-LSA with the H-bit set indicates that it MUST NOT be used as a transit router (see Section 4) by other OSPFv2 routers in the area supporting the functionality." Isn't the MUST here too restrictive? What if the router is the part of the only path to a certain host? Or is the assumption that this host is some kind of endhost/deadend, but then it should never be on the shortest path anyway, or? Later on you say "When the H-bit is set, the OSPFv2 router is a Host (non-transit) router and is incapable of forwarding transit traffic." However, there might also be routers that don't understand the H bit and therefore will route traffic over this host anyway, no? 2) Shouldn't this document update RFC2328, given section 4 and this sentence in section 2: "If the H-bit is set then the calculation of the shortest- path tree for an area, as described in section 16.1 of [RFC2328], is modified by including a check to verify that transit vertices DO NOT have the H-bit set (see Section 4)." (And why is DO NOT in upper letters?) 3) Is there an attack that by spoofing the H-bit an attacker could influence the routing such that traffic is router over a malicious node instead? I guess there are multiple ways to impact the routing that way and this might not be specific to the H bit but maybe still worth thinking about it once more...? Nit: Section 5: "The RI LSA MUST be area-scoped. Bit:" -> I guess the "Bit:" should be removed. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-yang-26: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for
draft-ietf-ospf-yang-26: 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-yang/
--
COMMENT:
--
Just two quick questions about references:
- Is there no reference for mtu-ignore (see section 2.4)? If not, can you
further describe what exactly would be disabled?
- Also is there no reference for OSPF Non-Stop Routing (NSR) (see section
2.4)...?
And one more comment:
In the interface-common-config part (p76 and p77) you provide example or
default values for various intervals and delays. Where does those values come
from? Would it be possible to provide a reference/RFC that specifies actual
default values? Especially when you specify something normatively ("The value
MUST be greater than 'hello-interval'.") it would be good to provide a
reference! Do any specification maybe also specify min and max value? If so,
you should mention them here as well! If not would it make sense to recommend
min and max values? If possible I would strongly support to describe min and
max values as well!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Mirja Kühlewind's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-ospf-xaf-te-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/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-xaf-te/ -- COMMENT: -- Sec 1: "This document updates [RFC5786] so that a router can also announce one or more local X-AF addresses using the corresponding Local Address sub-TLV. Routers using the Node Attribute TLV [RFC5786] can include non-TE enabled interface addresses in their OSPF TE advertisements, and also use the same sub-TLVs to carry X-AF information, facilitating the mapping described above." I wonder if this text should use normative language (s/can/MAY/) as this is the part that actually updates RFC5786, however, I didn't check the exact wording in RFC5786... ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Mirja Kühlewind's No Objection on draft-ietf-isis-segment-routing-extensions-24: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-isis-segment-routing-extensions-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/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-segment-routing-extensions/ -- COMMENT: -- A few comments/questions: 1) For both the Prefix Segment Identifier and the Adjacency Segment Identifier sub-TLV it is not fully clear to me what the value field is used for when the V-Flag is set. Can you further elaborate this in the draft or provide a respective pointer? 2) The F-Flag in Adjacency Segment Identifier sub-TLV and SID/Label Binding TLV is only one bit. I'm not expecting a new version of IP any time soon, however, maybe completely different address families could be useful as well. Not sure if only 1 bit is future-proof...? 3) Would it make sense to also discuss any risk of leaking information (e.g. about the network topology) in the security consideration section? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
