Stephane, Thanks for the response and the proposed updates. Some follow-up on a few points:
On 06/10/2016 21:46, stephane.litkow...@orange.com wrote: ... >> 5.3.2.2.1. IP addressing > ... >> o slaac : enables stateless address autoconfiguration ([RFC4862]). >> This is applicable only for IPv6. > > You can't stop there. Within SLAAC, privacy addresses (RFC4941) may or may > not be allowed by an operator, and opaque addresses (RFC7217) may be > required. So two more Boolean properties are needed. > > Also, DHCPv6, SLAAC and static addresses may coexist; they are not mutually > exclusive. I'm not sure if your model allows that. > > [SLI] We did not wanted to add all the possible options, but the most current > ones. New scenarios can always been added through augmentations. OK. I think a general note in the Introduction saying that would be very useful. > > >> 5.12.2.1. QoS classification > > This is too simple. At least, it needs to be able to handle a port range, not > just a single port number. > > [SLI] What we need to identify is a particular application running on a > specific port, we are not defining a router configuration framework here. No, but there are applications that run on multiple ports and it's a bit clumsy to require a separate classifier for each port. > > >> 5.12.2.2. QoS profile > > rate-limit, priority-level, and guaranteed-bw-percent may be OK for MPLS, but > they do not capture the needed parameters for differentiated services. I > could write an essay here, but I think the best starting point is > draft-ietf-tsvwg-diffserv-intercon. > [SLI] Again, we captured the most used parameters by service providers. The > goal is not to provide all. But If you see a specific parameter that is > widely used and not implemented here, feel free to point it. Diffserv DSCP values are widely used. I suggested diffserv-intercon because it proposes a specific subset useful at network boundaries, but there is also RFC 5127 and related work for WebRTC (https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos). > > Also, I don't understand how you can separate this issue from Section 5.13.2. > Transport constraints, where you do discuss parameters relevant to diffserv. > The whole point about diffserv-intercon is to quantify and standardise the > constraints at interconnections. > [SLI] We discussed this point when we designed the model, and it was simpler > to express the transport constraint at vpn level than trying to implement > them per site. That's why it was decoupled. OK, but you still need a rich set of QoS parameters at that level, and shouldn't it be the same set? > I recommend having TSVWG review sections 5.12 and 5.13. > > > Minor Issues: > ------------- > >> 5.2.2. Cloud access > ... >> If NAT is required to access to the cloud, the nat-enabled leaf MUST >> be set to true. > ... > Although NAT is mentioned, I saw no support for NPTv6 (RFC6296). I also saw > no mention of private or shared address space (RFC1918, RFC4193 or RFC6598). > > [SLI] NAT is a generic term, it only mentions that address translation is > needed but does not tell what technology will be used. Nothing prevents SP to > implement NPTv6. No, but the IETF strongly recommends against NAT66, while having specs for NAT44, NAT64 and NPTv6. Hiding these distinctions under the buzzword "NAT" is misleading. > The non working point is that the customer-nat-address is an IPv4 type which > is a mistake ... it could be IPv6 also. But it's not a NAT address, it's an NPTv6 prefix. A different animal. ... Regards Brian _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
