Hi Ian, Many thanks for the prompt review. Much appreciated!
Please see inline. Cheers, Med De : Ian Farrer [mailto:[email protected]] Envoyé : mardi 8 novembre 2016 12:24 À : BOUCADAIR Mohamed IMT/OLN Cc : softwires; [email protected] Objet : Re: [Softwires] Volunteers to review draft-ietf-softwire-dslite-yang? Hi Med, Thanks for the reminder. I’ve been meaning to review this for a while. Cheers, Ian General Comments: 1, How does this draft relate to the model in draft-sivakumar-yang-nat? There seems to be a lot of redundancy between them, which is understandable given the respective functions of a CGN and an AFTR. Wouldn’t it be better to reference the ietf-nat model for the nat specific functionality? [Med] This is fair point, but given the current progress of draft-sivakumar-yang-nat I prefer to avoid that dependency and build the DS-Lite as self-contained modules. Section 1 2, It would be useful to include a YANG model for B4 configuration as well to be inline with what is covered by the softwire-yang draft. Operators that are planning on moving to configuring CPEs with Netconf would also find this useful and given that there is a fairly small amount of confiig necessary for the B4, it would be neater to include this here rather than another draft. [Med] The B4 module will be quite simple. I don’t have objection to include that module, but this will require to change the scope of the draft. Section 2 3, "A device can enable multiple AFTR instances” I’m only familiar with one vendor’s DSLite AFTR implementation and I believe this only supports a single instance. Suggest something like - "The model supports enabling one or more instances of the AFTR function on a device” [Med] OK with this change. FWIW, there are vendors who support the activation of multiple instances on the same AFTR. 4, The tree model needs a clean up for the data type column positioning [Med] This will be fixed. Model comments: 5, aftr-parameters/ipv4-address - You could use 192.0.0.1 as a default value here. [Med] Agree. 6, aftr-parameters/leaf-mss-clamping-enable - Does this need an option to configure the MSS size to be used for clamping? [Med] thank you for catching this. When it clamping is enabled, a value should be provided. 7, aftr-parameters/max-softwire-per-subscriber - the description could reference the subscriber-mask leaf to clear up how a ‘subscriber’ is defined. [Med] Makes sense. 8, Should it be possible to configure an IPv6 range(s) for clients that the AFTR instance will service? If so, then the subscriber mask should be a child of this object. [Med] The base AFTR behavior does not require explicit configuration of the IPv6 prefix to service. I’m hesitating to add that. 9, container logging-info - Can this be extended to contain timestamping information for the start/endtime of an active translation? I’m aware of a large commercial CGN deployment which requires these timestamps for regulatory compliance. [Med] I agree that timestamping is needed, but this model assumes that the structure of the logging entries are fixed. Because there is no recommendation about such entries (except a discussion in RFC6888 and RFC6269), we avoided to zoom more on that part. 9, Also, I’ve seen several different logging/ protocol options that are implemented by vendors (local, syslog, netflow/ipfix, proprietary). Should a way of configuring these be available in this model? [Med] May make sense to be added. 11, mapping-entry/lifetime - what is the unit for this leaf? [Med] Seconds ; the module will be updated. 12, statistics/traffic-statistics - are there any useful sent ICMP set error messages that could be included here for e.g. to identify MTU problems? [Med] Will be happy to align with lw4o6/MAP-E. 13, The notifications section seems quite light given then number of configurable threshold values that are available. e.g. max-softwire-per-subscriber (would be useful to know how often this is exceeded), no. of exceeded port-quota or port-set-size. [Med] This section focuses only on critical events. What about a counter for drops of packets received with unsupported transport protocols? [Med] We can but this may be just logged locally. Grammatical comments: Section 2: s/each responsible to service a group of B4s/each responsible for serving a group of B4s/ s/with a dedicated configuration data/with dedicated configuration data/ leaf hold-down-timeout s/not reassigned till this timer/not reassigned until this timer/ [Med] Fixed. Thanks On 08 Nov 2016, at 10:04, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: Dear WG, We are seeking for volunteers to review draft-ietf-softwire-dslite-yang. If you are willing to review, please send a note to the list. Thank you. Cheers, Med _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
