Subject: [Softwires] Volunteers to review draft-ietf-softwire-dslite-yang?

From: <[email-masked]>
Date: Tue, 8 Nov 2016 09:04:10 +0000

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

---

From: Ian Farrer <[email-masked]>
Date: Tue, 8 Nov 2016 12:24:03 +0100

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?

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.

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”

4, The tree model needs a clean up for the data type column positioning

Model comments:
5, aftr-parameters/ipv4-address - You could use 192.0.0.1 as a default value here.

6, aftr-parameters/leaf-mss-clamping-enable - Does this need an option to configure the MSS size to be used for clamping?

7, aftr-parameters/max-softwire-per-subscriber - the description could reference the subscriber-mask leaf to clear up how a ‘subscriber’ is defined. 

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.

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.

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?

11, mapping-entry/lifetime - what is the unit for this leaf?

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?

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.
What about a counter for drops of packets received with unsupported transport protocols?

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/

> On 08 Nov 2016, at 10:04, <[email-masked]> <[email-masked]> wrote:
> 
> Dear WG,
>  
> _______________________________________________
> Softwires mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>

---

From: <[email-masked]>
Date: Tue, 8 Nov 2016 12:54:14 +0000

Hi Ian,

Many thanks for the prompt review. Much appreciated!

Please see inline.

Cheers,
Med

De : Ian Farrer [mailto:[email-masked]]
Envoyé : mardi 8 novembre 2016 12:24
À : BOUCADAIR Mohamed IMT/OLN
Cc : softwires; [email-masked]
Objet : Re: [Softwires] Volunteers to review draft-ietf-softwire-dslite-yang?

Hi Med,

Cheers,
Ian

General Comments:

[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

[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:
[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.

[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:

leaf hold-down-timeout

[Med] Fixed. Thanks

On 08 Nov 2016, at 10:04, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG,

Thank you.

Cheers,
Med
_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires