[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospfv3-extended-lsa-yang-27: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospfv3-extended-lsa-yang-27: 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-ospfv3-extended-lsa-yang/ -- COMMENT: -- Thanks for the work done in this document. Like id-nits, I wonder why BCP14 template is used in the main body (in addition to its occurence in the YANG module itself) as there are occurence of normative language neither in the main body nor in the YANG module. Please consider removing the 2 occurence of the BCP 14 template. Should there be a less trivial example ? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospfv3-srv6-extensions-14: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospfv3-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/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-srv6-extensions/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospfv3-srv6-extensions-14 Thank you for the work put into this document. Sorry for belated ballot, as Roman cleared his DISCUSS, I just noticed today that there is one ballot missing: here it is ;-) Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## SRv6 or Network Programming The name of the document and its abstract refer to SRv6 while it is rather for network programming (RFC 8986). ## Section 5 `Locators associated with algorithms 0 and 1`, I must admit that I am not familiar with OSPF/network programming, but is the reader expected to know what are "algorithms 0 and 1" ? Some short explanations are probably welcome. ## Section 6 Bits in a flag field are more often specified by their position, bit 0, rather than by their value, 0x80. But, this is a matter of taste. The same inconsistency happens in sections 13.3 (using a value) and 13.4 (using a bit position) in the IANA section. ## Section 7.1 Should the obvious be stated for the Locator field ? I.e., this field should be the shortest as possible with unused bits set to 0 ? ## Section 8 `Every SRv6-enabled OSPFv3 router SHOULD advertise` as it is not a MUST, in which case a router may deviate from the SHOULD behavior ? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ip-flexalgo-13: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ip-flexalgo-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-ip-flexalgo/ -- COMMENT: -- Thank you for the work put into this document. Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review as if it was my own review: https://datatracker.ietf.org/doc/review-ietf-lsr-ip-flexalgo-12-intdir-telechat-fressancourt-2023-06-01/ (and I have seen that the authors have responded to the review) I hope that this review helps to improve the document, Regards, -éric ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospf-terminology-07: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospf-terminology-07: 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-terminology/ -- COMMENT: -- I find interesting that this update to be more inclusive has non-inclusive abstract and introduction... There are more than 200 countries (if not mistaken) and readers can genuinely wonder which one is referred by "National Institute of Standards and Technology" (of course, most readers knowing the IETF will guess the NIST of the USA). I also wonder whether IANA should keep the old name of the L bit in a footnote or so. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-flex-algo-24: (with COMMENT)
Éric Vyncke 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: -- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-flex-algo-24 CC @evyncke Thank you for the work put into this document. The underlying concept is brillant and can be useful, but it was hard for me to understand all the details as the document is rather tedious to read (and to author -- so congrats!), I may have misunderstood several points. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. ***But***, I regret the lack of reply to the question about `WG discussion and conclusion regarding the IPR disclosures`. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Alvaro's DISCUSS Just to write that I find Alvaro's DISCUSS points sensible, but I am sure that the authors will address those points. ### Who allocates the flex algo ID After reading the I-D (and skipping some too deeply technical parts to be honest), I still wonder whether it is the operator who defines locally significant flex algo ID or whether it will be the IETF by standard actions. I was about to raise a DISCUSS on this point. ### Section 1 For the non-expert reader, it would be nice to shortly indicate why this document is about SRv6 locators and not SRv6 SIDs. (no need to explain this to me BTW ;-) ) ### Section 4 In `We want the mapping`, who is the "we" ? Please do not use such ambiguous sentence patterns. In `As long as all routers in the domain`, what is the "domain" ? The OSPF area? the AS? another concept ? In `The following values area allocated from this registry for Flex-Algorithms`, the reader would benefit to already understand which party (operator/IANA/?) will assign specific values in that range. ### Section 5.1 Even if obvious, it will not hurt to have the unit specified in `Length: variable,`. ### Section 5.1 Calc-Type I am probably confused and lost due to my lack of knowledge... But the definition of Calc-Type: 1) specifies that type 0 is SPF, which is useless as the IANA https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types already says so. I.e., why addin useless/redundant information in the normative part (use of MUST) 2) the same IANA registry https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types has a clear indication that value 2-127 are unassigned. I.e., this I-D should not add constraints in this registry. ### Section 5.1 Priority tie What is the expected behavior when there is a priority tie ? Perhaps add a forward reference to section 5.3 ? ### Sections 6.2 and 6.3 Suggest to repeat the TLV format from section 6.1. ### Sections 6.4, 7.4 Sorry, but cannot understand/parse `Bits that are not transmitted MUST be treated as if they are set to 0 on receipt.` Is the meaning "bits defined by further specification but not in the actual transmitted TLV" ? What is the expected behavior when length is 0, i.e., I would assume that SRv6 nodes will either do not send this TLV or send it with length=0. ### Section 11 Again a "we" in `we say it`, please rephrase without using ambiguous "we". ### Section 20.1 Is RFC 8986 really normative? I would have assumed it is informative. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments * As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Check for IPv4, IPv6, address, NAT, ICMP, MTU As usual, as the responsible AD for the ADD WG, I have done an AD review before the IETF Last Call. Please find a MD-formatted review below. Before going further, I am requesting the authors to act/reply/comment on all the points below. The end goal is to ease the rest of the publication process. Please note that Tim
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-pce-discovery-security-support-11: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-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-pce-discovery-security-support/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-pce-discovery-security-support-11 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status, but we miss the WG reaction on the IPR disclosure (see below). Please note that Suzanne Woolf is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Suzanne will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/reviewrequest/16328/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### IPR The shepherd's write-up rightfully states that IPR disclosures were done (e.g., https://datatracker.ietf.org/ipr/5027/). But, the write-up says nothing about the WG reaction on a licensing scheme that it rather ambiguous `Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee` as the "possible royalty/fee" could hinder the deployment and use of this I-D. What was the WG reaction ? ### Section 1 The first paragraph mentions privacy, which is important but I would have assumed that integrity was even more important. Should integrity be mentioned ? It is probably obvious, but should the change of registry names be linked to supporting IS-IS as well ? ### Section 3.2.1 (and 3.3.1) The section would benefit of a simple figure showing the TLV structure, even if only to be consistent with section 3.2.2 ### Normative references Unsure whether RFC 5925, 5926, and others are really normative as I would qualify them as informative. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-reverse-metric-08: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospf-reverse-metric-08: 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-reverse-metric/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-shmoo-hackathon-07 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Even, if I cannot really parse `During the WG last call, a number of WG members the draft with the only issue being the predominant use cases.`. Please note that Wassim Haddad is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Wassim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-reverse-metric/reviewrequest/16329/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Abstract `that receiving neighbor(s) should use for a link to the signaling router` should the neighbor be qualified by "OSPF" ? More generally about the abstract: it is rather hard to parse and to understand (at least for a native English reader). ### Generic Should this be "mirrored metric" rather than "reverse metric". I appreciate that this is late in the process, but it sounds clearer. ### Section 1 s/and/or/ in `Open Shortest Path First (OSPFv2) [RFC2328] and OSPFv3 [RFC5340] `? ``` ... then R2 advertises this value as its metric to R1 in its Router-LSA instead of its locally configured value. ``` Suggest to s/in its Router-LSA/in its Router-LSAs to all its OSPF neighbors/ ### Section 2.2 s/some point T/some point in time T/ ? Please expand "CLOS" ### Section 6 ` When using multi-topology routing with OSPF [RFC4915],` what about OSPFv3 ? ### Section 7 s/The use of reverse metric signaling does not alter the OSPF metric/The use of *received* reverse metric *signalling* does not alter the OSPF metric/ ? Rather than `If routers that receive a reverse metric advertisement log an event to notify system administration, `, what about using "It is RECOMMENDED" or a "SHOULD" ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-bfd-strict-mode-09: (with COMMENT)
Éric Vyncke 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: -- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-bfd-strict-mode-09 CC @evyncke Thank you for the work put into this document. It is short, clear, and useful (hence my YES). Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Section 3 Suggest to move section 3 (Local Interface IPv4 Address TLV) as a subsection of section 4.1 (OSPFv3 IPv4 Address-Family Specifics) as, at least for me, the reader cannot understand the use of section 3 before reading section 4.1 As I am not an OSPFv3 expert, the following question is possibly irrelevant, but can the IPv4 address be a link-local (i.e., 169.254/16)? ### Section 4.1 ``` ... In most deployments of OSPFv3 IPv4 AF, it is required that BFD is used to monitor and verify IPv4 data plane connectivity between the routers on the link and, hence, the BFD session is setup using IPv4 neighbor addresses. ``` The text is a little unclear whether an IPv6 BFD session is also required. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's Yes on draft-ietf-lsr-ospf-l2bundles-06: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-lsr-ospf-l2bundles-06: 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-l2bundles/ -- COMMENT: -- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-ospf-l2bundles-06 CC @evyncke Thank you for the work put into this document: it is short, clear, and will be useful. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. A follow up on the Ericsson IPR would be welcome though if there is any update. As a side note, yet another definition for the overloaded "SID" ;-) I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### IEEE802.1AX as informative ? The only occurence of IEEE802.1AX appears to me as informative: ` for instance a Link Aggregation Group (LAG) [IEEE802.1AX]` => suggest to change the reference type to informative rather than normative. ### Section 2 ``` ... Therefore advertisements of member links MUST NOT be done when the member link becomes operationally down or it is no longer a member of the identified L2 bundle. ``` OTOH, if the information is for an external party (e.g., a controler), having information of an operationally-down link could be useful. Are the authors sure that this would never be used ? ### Section 2, length field `Length: Variable.` while it is probably obvious, it would probably not hurt to specify the units and what is included. ### Section 2, extensibility Should there be some text on how to decide applicable/non-applicable for any new link attribute TLV that could be added in the coming years ? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-rfc5316bis-04: (with COMMENT)
Éric Vyncke 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: -- # Éric Vyncke, INT AD, draft-ietf-lsr-isis-rfc5316bis-04 CC @evyncke Thank you for the work put into this document especially about `This document builds on RFC 5316 by adding support for IPv6-only operation.` Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Christian Hopp for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Section 3.1 ``` The Router ID field of the inter-AS reachability TLV is 4 octets in length, which contains the IPv4 Router ID of the router who generates the inter-AS reachability TLV. The Router ID SHOULD be identical to the value advertised in the Traffic Engineering Router ID TLV [RFC5305]. If no Traffic Engineering Router ID is assigned, the Router ID SHOULD be identical to an IP Interface Address [RFC1195] advertised by the originating IS. ``` AFAIK, the router ID is 'just' a 32-bit value that it is protocol version agnostic. So, s/IPv4 Router ID/Router ID/ ? Suggest: s/IP Interface Address [RFC1195]/IPv4 Interface Address [RFC1195]/ ? ### Section 6.1 & 6.2 `This document defines the following new IS-IS TLV type` but this type is already defined in RFC 5316, so does it still qualify as "new" ? Propose to rewrite the IANA section to simply request IANA to update the registries to point to this I-D rather than to RFC 5316. ### Section 7 While Les was not an author of RFC 5316, he is an author of this I-D, so no more need to acknowledge him ;-) ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits. Thank you to Christian Hopps for his shepherd's write-up (including the WG consensus). I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 2 -- Any reason why the bits of the 'Flags' field are not reserved (except for the O-bit) ? or be in a to-be-created IANA registry? I would expect the default value for sending them (usually 0) and what to do on the receiving side(s) when the value is not 0 (usually ignore them). E.g., see the section 7.1 -- Section 3 -- Isn't it obvious that the "Segment Routing Algorithm" is also supported by SRv6 routers ? Consider removing this section ? If you prefer to keep it, then please use the wording "Segment Routing Algorithm" exactly as in the IANA registry. -- Section 7.1 (also 7.2 and possibly others) -- The header 'Length' should not be defined as 'variable' as it is probably a fixed length of 1 octet. Specifying how it is measured and in which units (octets, 32-bit word, ...) is probably welcome. -- Section 7.2 -- What is the default value of the "Flags" field? == NITS == -- title- Should the plural form be used for 'extension' ? -- Section 1 -- s\topology/algorithm specific\topology/algorithm-specific\ ? -- Section 13 -- While there is a rather long contributors list, there is no acknowledgement section. The latter is of course optional but usual. Should the doc shepherd or last call reviewers be acknowledged ? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-lsr-ospf-prefix-originator-10: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. Easy to see the added value for trouble shooting ! Please find below some non-blocking COMMENT points (but replies would be appreciated). I hope that this helps to improve the document, Regards, -éric Thanks for fixing Warren Kumari's question in the latest -10. -- Section 1 -- Is the reference to RFC 5329 correct ? I fail to see the link of TE with this document. Should it be made clearer that the OSPFv3 router ID is a 32-bit value hence cannot be used in an IPv6-only network ? "it does not necessarily represent a reachable address for the router" is slightly ambiguous. -- Section 2.2 -- Thanks for fixing Warren Kumari's question in the latest -10. -- Section 4 -- Suggestion: made the sentence "A rogue node that can inject prefix..." in a separate paragraph. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-isis-te-app-14: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. I have only one nits in section 4.3: while I appreciate IPv6, there is no need to capitalize 'IPv6 Interface Address' as "IPv4 interface address" is not capitalized ;-) Special thanks to Acee, as the document shepherd he managed to represent the conflicts within the WG. I hope that this helps to improve the document, Regards, -éric ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-isis-mpls-elc-12: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. The document is easy to read. Like other ADs, I wonder why the IS-IS and OSPF are separate documents. Please find below one NIT. I hope that this helps to improve the document, Regards, -éric == NIT == -- section 4 -- The "one" is ambiguous in "the router MUST advertise the smallest one." even if we can guess that it is not "interface" ;-) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-mpls-elc-13: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. The document is easy to read. Please find below one non-blocking COMMENTs and two NITs. I hope that this helps to improve the document, Regards, -éric == COMMENT == For my own curiosity, is there a possibility that a router receives conflicting node capability via OSPFv2 and OSPFv3 (assuming that both are running over the same network and using the same router-ID over OSPFv2 and OSPFv3) ? == NITS == -- section 4 -- The "one" is ambiguous in "the router MUST advertise the smallest one." even if we can guess that it is not "interface" ;-) -- Sections 3 & 4 -- Is there a meaningful difference between the "advertizing" of section 3 and the "signaling" of section 4? ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-ospfv2-hbit-11: (with COMMENT)
Éric Vyncke 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: -- Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-) The deployment issue (section 5) had raised a DISCUSS of mine and I appreciated your reply, so, I have cleared this DISCUSS. Feel free to ignore my COMMENTs and NIT. == COMMENTS == -- Generic -- Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful. -- Section 1 -- A description of "Closet Switches" would be welcome. -- Section 3 -- Isn't the wording "host router" an oxymoron ? == NITS == -- Section 8 -- I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's Discuss on draft-ietf-ospf-ospfv2-hbit-11: (with DISCUSS and COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-ospf-ospfv2-hbit-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/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/ -- DISCUSS: -- Thank you for the work put into this document. The short document is easy to read even if I wonder whether it is useful to spend time on IPv4-only protocol ;-) The deployment issue (section 5) has raised a DISCUSS of mine and I would appreciate a reply on this DISCUSS. Regards, -éric == DISCUSS == -- Section 5 -- The risk of having inconsistent view of the topology with H-bit aware and unaware routers seems possible to me (albeit perhaps only transient). Has this feature been tested / simulated in large scale networks? -- COMMENT: -- Feel free to ignore my COMMENTs and NIT. == COMMENTS == -- Generic -- Mentioning that the H-bit of OSPFv2 is the reverse of the R-bit of OSPFv3 would be useful. -- Section 1 -- A description of "Closet Switches" would be welcome. -- Section 3 -- Isn't the wording "host router" an oxymoron ? == NITS == -- Section 8 -- I recommend reading and following the suggestions of RFC 8126 (how to write the IANA considerations) ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-isis-yang-isis-cfg-40: (with COMMENT)
Éric Vyncke has entered the following ballot position for draft-ietf-isis-yang-isis-cfg-40: 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-yang-isis-cfg/ -- COMMENT: -- Thank you for the work put into this document. Disclaimer: I am neither an IS-IS export nor a YANG doctor ;-) I have 2 COMMENTs below. Regards, -éric == COMMENTS == -- Section 2.3 -- C.1) Is there a reason to have one example with a generic value of 250 that will never be used as you are either level-1 or level-2 ? (I am not an IS-IS expert of course) -- Section 6 / YANG module -- C.2) About lsp-entry/remaining-lifetime, is there also a state about the received hold time ? It could be interesting to know whether the remaining lifetime is 3% of the original lifetime or 30% ;-) But again, I am not an IS-IS expert ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Éric Vyncke's No Objection on draft-ietf-ospf-xaf-te-06: (with COMMENT)
Éric Vyncke 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: -- Alvara, Anton, Michael, Thank you for the work done for this document. Just curious about section 3: OSPFv2 routers send their IPv6 address(es) and OSPFv3 routers send their IPv4 address(es). But, what happens when OSPFv3 routers are multi-topology ? Should they also send their IPv6 address(es)? Of course, in this case, the issue fixed by your memo does not exist ;-) Probably worth mentioning anyway that OSPFv3 multi-topology does not need this feature. Regards, -éric ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
