Re: [Gen-art] Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16

[Brian E Carpenter <[e-mail]>]

[N.B. I have added the l3sm list but I am not subscribed]

On 07/10/2016 20:46, [e-mail] wrote:
...

>>> 5.12.2.2.  QoS profile
...
> [SLI2] The current model supports classification based on generic DSCP values. Isn't it enough ?

Yes, I missed that. I agree, that seems the right level for this model. However,
this raises one detail. The model says:

            |  |  |     |  |  +--rw match-flow
            |  |  |     |  |     +--rw dscp?              uint8
            |  |  |     |  |     +--rw tos?               uint8

but tos was obsoleted when dscp was defined by RFC 2474. I don't think
you should include tos. You don't mention ECN, which are the two bits
from tos that are not included in dscp. Those bits are no good for flow
matching because they are variable.  If an operator tries to use the 8 TOS
bits for flow matching but a user supports ECN, the matching will not work
consistently.

...
>> 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?
> 
> [SLI2] Some of them are equivalent for example low latency/jitter, some are different as for diversity.
> I understand your comment, but I think we need a larger discussion on this topic and this may imply a full remodeling of this part. Let me post a thread on L3SM list.

OK.

...
>>> 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.
> 
> [SLI2] That was done for simplification purpose, could you list the different options that you would like to see in this model ? To be honest, I'm not fully aware of all the necessary combinations, so help would be required.

I think the three cases I mentioned are sufficient for a start, but (getting back to
Benoit's point) we could quickly get into configuration detail. So we have

NAT44 - which requires an outside ipv4-address.

NAT64 (for an IPv6-only network requiring IPv4 access) - which requires
an outside ipv4-address and an inside WKP (well-known ipv6-prefix).
(NAT64 implies DNS64, but I don't think that is needed in the model.)

NPTv6 - which requires an outside ipv6-prefix.

(There are also possible NAT444 and XLAT464 cases with added complexity,
but let's leave them for now.)

So the three cases are different. I think you would need something like

      |     |     +--rw nat44-enabled?            boolean
      |     |     +--rw customer-nat44-address?   inet:ipv4-address
      |     |     +--rw nat64-enabled?            boolean
      |     |     +--rw customer-nat64-address?   inet:ipv4-address
      |     |     +--rw customer-nat64-wkp?       inet:ipv6-prefix
      |     |     +--rw nptv6-enabled?            boolean
      |     |     +--rw customer-nptv6-prefix?    inet:ipv6-prefix

If you go that way it needs a quick check on the BEHAVE list, where
NAT expertise exists.

Regards
   Brian