Hi WG, I support the adoption of this work and I have thoughts on how to improve the document -
Some questions/comments - - Why do you have the config and the state trees separately in Figures 2 and 3? That's out of fashion with NMDA! - I hope this model is applicable for both the headend router as well as for the controller. If yes, we should highlight that as well as make sure the YANG model takes care of this. For example, counters, path-forwarding_state, etc - I found the top-level container "traffic-engineering" on top as out of place when the rest of the SR-Policy work does not use it. - Regarding segment types, I have a few thoughts - * I-D.ietf-spring-segment-routing-policy uses Type A,B,C,..., whereas you use Type 1,2,3.. * Should we use identity here instead of enum, to allow for future segment types to be defined? - Please describe the use of group-id and subgroup-id for disjointness, this was not clear from yang or the text - The constraints currently defined are quite minimal, is there any reason for that? I feel more constraint and optimization criteria should be supported. - How do we relate the information in forwarding-paths to the candidate path? Also, where would the inactive candidate paths received from BGP/PCEP stored in this model (assumption that forwarding-paths are active only)? Maybe segment-lists for dynamic paths should be added as well? Suggestions for improving YANG - - Add references such as during import and important leaves. - Use generic-path-disjointness in ietf-te-types instead of defining a new identity for path-disjointness - Use of identity for protocol-origin-type (instead of enum) to allow other protocols to be added easily - Use of labels as a key in a label stack is incorrect (see grouping mpls-label-stack), as you could have the same label repeated in the stack. - sid-algorithm, color, and name should have its own typedef - Run "pyang -f yang --keep-comments --yang-line-length 69 <FILE>" to help with formatting. Thanks! Dhruv On Mon, Jul 13, 2020 at 9:08 PM James Guichard <james.n.guich...@futurewei.com> wrote: > > Dear WG: > > > > This email begins a 2 week WG adoption call for > https://datatracker.ietf.org/doc/draft-raza-spring-sr-policy-yang/ ending > Monday 27th July 2020. > > > > Please speak up if you support or oppose adopting this document into the WG. > Please also provide comments/reasons for that support (or lack thereof). > Silence will not be considered consent. > > > > Thanks! > > > > Jim, Joel & Bruno > > > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
