Fair enough. I think the author has implemented this in v(-017). -Qin -----邮件原件----- 发件人: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] 发送时间: 2016年10月11日 7:49 收件人: Qin Wu; stephane.litkow...@orange.com; draft-ietf-l3sm-l3vpn-service-model....@ietf.org; General Area Review Team; l...@ietf.org 主题: Re: Gen-ART Last Call review of draft-ietf-l3sm-l3vpn-service-model-16
That's certainly a valid option, but if you limit it to NAT44 I strongly suggest *calling* it NAT44, not plain NAT. Regards Brian Carpenter On 10/10/2016 21:55, Qin Wu wrote: > Not sure we should enumerate all the options in the base model, so your > solution makes sense to me. > > -Qin > -----邮件原件----- > 发件人: stephane.litkow...@orange.com > [mailto:stephane.litkow...@orange.com] > 发送时间: 2016年10月10日 16:29 > 收件人: Brian E Carpenter; > draft-ietf-l3sm-l3vpn-service-model....@ietf.org; General Area Review > Team; l...@ietf.org > 主题: RE: Gen-ART Last Call review of > draft-ietf-l3sm-l3vpn-service-model-16 > > 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
