For NAT, I would like to hear opinion for other people before doing the change. And additional options can be added through augmentation. One solution is to limit to IPv4 case which is really usual today.
-----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] Sent: Saturday, October 08, 2016 02:08 To: LITKOWSKI Stephane OBS/OINIS; draft-ietf-l3sm-l3vpn-service-model....@ietf.org; General Area Review Team; l...@ietf.org Subject: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16 [N.B. I have added the l3sm list but I am not subscribed] On 07/10/2016 20:46, stephane.litkow...@orange.com 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
