[Lsr] I-D Action: draft-ietf-ospf-yang-21.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for OSPF Protocol Authors : Derek Yeung Yingzhen Qu Jeffrey Zhang Ing-Wher Chen Acee Lindem Filename: draft-ietf-ospf-yang-21.txt Pages : 125 Date: 2019-01-24 Abstract: This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-yang-21 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-yang-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-yang-21 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Comments regarding convergence regarding draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding
Dear LSR WG, The LSR chairs informed that attempts to merge drafts draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding is exposing challenges, and hence asked me as independent unbiased WG contributor to have a look at both drafts and provide suggestions on how we may progress to deliver the highest quality WG technology deliverable. Please find following observations on both documents with my hat of "independent unbiased LSR contributor": Both drafts have clearly written problem space description and in general a well written solution space. The problem space is real. Each draft approaches the problem space using different accents within the solution space. These accents are obvious when the solution-space is discussed in both drafts. I found the solution space described in "draft-cc-lsr-flooding-reduction" centered around restoring flooding topology and making sure that during critical changes, flooding is still fast. The solution space provides mechanism to make sure that a reduced flooding topology has minimal impact upon convergence (it use backup paths, critical paths/node, ...). The compromise to achieve fast topology restoration is by introducing a complexity trade-off. For example, there are many moving parts from flooding mechanics, to avoid against flooding topology split. This raise to me some concern from implementor perspective. The solution space discussed in "draft-li-lsr-dynamic-flooding" uses a generic vision based upon solution requirements and seems to focus around protocol efficiency/simplicity versus speed of topology convergence. From a documentation perspective I found the flow contained by "draft-li-lsr-dynamic-flooding" easier to understand. This understanding includes packet format descriptions and architectural decisions (for example known LSR technology properties/limitations). I found most of the information sufficiently well described with minimal complexity. In both drafts the distributed algorithm solution seems underspecified and that raise implementation concerns to me. Conclusion: Coming back to the original request of the LSR chairs asking feedback to progress for a quality WG deliverable. I have read both drafts and constructed an opinion. Items of interest to me were draft documentation flow, draft technological format/content and high level architectural decisions made within each proposal. Using those criteria, the balance scales towards "draft-li-lsr-dynamic-flooding" because it is using clear solution requirements, clear descriptions of encoding and their usage, clear behavioral specifications and has considered introducing minimal complexity. This means that from review perspective "draft-li-lsr-dynamic-flooding" seems best candidate to adopt with most potential for high quality WG deliverable. In addition, we could assign a shepherd to work within the WG. If needed I am happy to help shepherding the WG deliverable. This work is important for industry. The solution must work and be causing less issues as the problem we are trying to fix. We need to progress the work on flooding reduction. We need to select the most optimal/pragmatic solution. Obviously, additional reviews from WG contributors will help LSR WG to define and build the highest quality WG deliverable. Kind Regards, Gunter Van de Velde ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] Comments regarding convergence regarding draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding
[with corrected copy/paste in cc] Dear LSR WG, The LSR chairs informed that attempts to merge drafts draft-cc-lsr-flooding-reduction and draft-li-lsr-dynamic-flooding is exposing challenges, and hence asked me as independent unbiased WG contributor to have a look at both drafts and provide suggestions on how we may progress to deliver the highest quality WG technology deliverable. Please find following observations on both documents with my hat of "independent unbiased LSR contributor": Both drafts have clearly written problem space description and in general a well written solution space. The problem space is real. Each draft approaches the problem space using different accents within the solution space. These accents are obvious when the solution-space is discussed in both drafts. I found the solution space described in "draft-cc-lsr-flooding-reduction" centered around restoring flooding topology and making sure that during critical changes, flooding is still fast. The solution space provides mechanism to make sure that a reduced flooding topology has minimal impact upon convergence (it use backup paths, critical paths/node, ...). The compromise to achieve fast topology restoration is by introducing a complexity trade-off. For example, there are many moving parts from flooding mechanics, to avoid against flooding topology split. This raise to me some concern from implementor perspective. The solution space discussed in "draft-li-lsr-dynamic-flooding" uses a generic vision based upon solution requirements and seems to focus around protocol efficiency/simplicity versus speed of topology convergence. From a documentation perspective I found the flow contained by "draft-li-lsr-dynamic-flooding" easier to understand. This understanding includes packet format descriptions and architectural decisions (for example known LSR technology properties/limitations). I found most of the information sufficiently well described with minimal complexity. In both drafts the distributed algorithm solution seems underspecified and that raise implementation concerns to me. Conclusion: Coming back to the original request of the LSR chairs asking feedback to progress for a quality WG deliverable. I have read both drafts and constructed an opinion. Items of interest to me were draft documentation flow, draft technological format/content and high level architectural decisions made within each proposal. Using those criteria, the balance scales towards "draft-li-lsr-dynamic-flooding" because it is using clear solution requirements, clear descriptions of encoding and their usage, clear behavioral specifications and has considered introducing minimal complexity. This means that from review perspective "draft-li-lsr-dynamic-flooding" seems best candidate to adopt with most potential for high quality WG deliverable. In addition, we could assign a shepherd to work within the WG. If needed I am happy to help shepherding the WG deliverable. This work is important for industry. The solution must work and be causing less issues as the problem we are trying to fix. We need to progress the work on flooding reduction. We need to select the most optimal/pragmatic solution. Obviously, additional reviews from WG contributors will help LSR WG to define and build the highest quality WG deliverable. Kind Regards, Gunter Van de Velde ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
[Lsr] I-D Action: draft-ietf-isis-yang-isis-cfg-34.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for IS-IS Protocol Authors : Stephane Litkowski Derek Yeung Acee Lindem Jeffrey Zhang Ladislav Lhotka Filename: draft-ietf-isis-yang-isis-cfg-34.txt Pages : 119 Date: 2019-01-24 Abstract: This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-34 https://datatracker.ietf.org/doc/html/draft-ietf-isis-yang-isis-cfg-34 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-yang-isis-cfg-34 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
