On 9/27/17 09:20, mohamed.boucad...@orange.com wrote: > > Adding policy and >> other non-NAT items would conflate the scope. > > [Med] Allowing for multiple NAT configurations within the same instance is > easy to add. > What I'm hesitating to add is advanced classification filtering that is not > specific to the NAT function. An approach I'm investigating is: > - Add an informative section to record the comment from Kris (i.e., bind a > packet/flow to a NAT configuration) and declare it out of scope. > - Suggest that extensions to ietf-netmod-acl-model module can be defined by > implementers, if needed. > >> >> Speaking as an individual -- and maybe this is what you mean by the >> multiple instances -- wouldn't the ability to have routing contexts act >> as inside and outside of each other be covered in your draft today? > > [Med] The current version is silent about inside/outside routing contexts per > se. The current approach assumes that: > * Some NATs are embedded in systems that are able to determine how/when to > invoke the NAT service. This is typically the case of NATs embedded in CPEs. > For example, a residential gateway determines in its own LAN interfaces and > WAN interfaces. > * Some NATs need to be bound to an external interface explicitly. An > interface can be of any nature (physical, virtual, tunnel, etc.). Remaining > interfaces are assumed to be internal ones.
> > Kris is asking to have the ability to associate the NAT service with VRF > contexts, too. Ah, I did misunderstand a bit. I assumed the VRFs were bound to interfaces and then NAT would be bound to those interfaces. > > I think that we can accommodate that comment by making the following change > to the draft (see the proposed change below). In order to avoid conflating > the scope, I don't want to list here every routing context type, but to limit > the scope to these two choices. > > OLD: > > +--rw internal-interfaces* [internal-interface] > | +--rw internal-interface if:interface-ref > +--rw external-interfaces* [external-interface] > | +--rw external-interface if:interface-ref > > NEW: > > +--rw internal-realm > | +--rw (realm-type)? > | +--:(interface) > | | +--rw internal-interfaces* [internal-interface] > | | +--rw internal-interface if:interface-ref > | +--:(vrf) > | +--rw internal-vrf-instances* [internal-vrf-instance] > | +--rw internal-vrf-instance identityref > +--rw external-realm > | +--rw (realm-type)? > | +--:(interface) > | | +--rw external-interfaces* [external-interface] > | | +--rw external-interface if:interface-ref > | +--:(vrf) > | +--rw external-vrf-instances* [external-vrf-instance] > | +--rw external-vrf-instance identityref This makes sense to me. Joe > >> >> Joe >> >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.pos...@nokia.com] >>>> Envoyé : mardi 26 septembre 2017 00:31 >>>> À : BOUCADAIR Mohamed IMT/OLN >>>> Cc : draft-ietf-opsawg-nat-y...@ietf.org >>>> Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01 >>>> >>>> Hi Med, >>>> Sorry for the late reply, this time from my side. >>>> We can continue in whichever way is the most efficient in your opinion. >>>> I'm OK either way. >>>> >>>> I replied to your comments inline. >>>> But my preference would be that this (NAT YANG model) is a more >> modular, >>>> i.e. have building blocks. >>>> Current model is a bit too monolithic and maybe even CE centric. >>>> >>>> We (Nokia) will be able to consolidate some configuration data and >> maybe >>>> even make it within a single configuration instance. >>>> For example, for inside make it a 'choice' between interface and entire >>>> 'vrf' (not sure how you want to call this if not routing context); same >>>> for outside. >>>> This way we can say the whole VRF is the inside and another (or the >> same) >>>> whole VRF is outside, which means that routing is used to determine >> where >>>> the translated packet needs to go out (this is how we do it, there no >>>> interfaces in our NAT for the reason I specified below - transport >>>> independent). >>>> >>>> But in general, my idea would be: >>>> >>>> - your NAT instance kinds of defines what gets mapped where >>>> >>>> But then outside of the nat-instance you have a bunch of other >>>> configuration that can be referenced from inside this nat-instance >>>> (classifiers and different policies). >>>> For example, when certain traffic is mapped to a pool, then this >> traffic >>>> may have different NAT parameters (ALGs, TCP/UDP timers, etc) than some >>>> other traffic that is mapped to a different pool within the same NAT >>>> instance. This kind of flexibility should exist. Thanks. >>>> Kris >>>> >>>> -----Original Message----- >>>> From: mohamed.boucad...@orange.com >> [mailto:mohamed.boucad...@orange.com] >>>> Sent: Wednesday, September 20, 2017 3:51 AM >>>> To: Poscic, Kristian (Nokia - US) <kristian.pos...@nokia.com> >>>> Cc: draft-ietf-opsawg-nat-y...@ietf.org >>>> Subject: RE: Request to review draft-ietf-opsawg-nat-yang-01 >>>> >>>> Hi Kris, >>>> >>>> (ccing my co-authors) >>>> >>>> Apologies for the delay to answer. I was out of office. >>>> >>>> Thank you very much for sharing the comments. Much appreciated! >>>> >>>> Please see inline. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Poscic, Kristian (Nokia - US) [mailto:kristian.pos...@nokia.com] >>>>> Envoyé : mercredi 13 septembre 2017 23:01 À : BOUCADAIR Mohamed >>>>> IMT/OLN Objet : RE: Request to review draft-ietf-opsawg-nat-yang-01 >>>>> >>>>> Hi Med, >>>>> >>>>> Wim asked me to review this draft and I here I provide my feedback. >>>> >>>> [Med] Thank you. >>>> >>>>> Unfortunately it does not line-up with our implementation. It seems >>>>> that this model configures everything under the same nat instance >>>>> (private side, public side and all the other config options). >>>> >>>> [Med] As a reminder, the module covers both "simple NAT" (that you can >>>> find in a CPE) and more advanced ones like your implementation. As such >>>> the module allows: >>>> - an implementation to determine its internal/external interfaces in >> its >>>> own. This is typically the residential gateway case. >>>> - instruct an implementation about the external interface(s) to which >> to >>>> bind the NAT with or without filter on the internal interface(s). >>>> >>>> >>>> [Kris] Ok, thanks for mentioning this, I'll talk from the CGN >> perspective, >>>> scalable version of NAT deployed in SP networks (not the CE). >>>> I'm not sure that the interface is the right way to go. I think this >>>> should be based on the routes. So you translate the packet and then let >>>> the routing decides where to go. Different transports my encapsulate >> this >>>> packet differently on egress (MPLS/GRE, etc.) and this is interface >>>> independent. >>>> --------------------- >>>> If no indication is provided, all the traffic that is send/received on >> an >>>> external interface is NATed. >>>> If subscriber-match is provided, the NAT will be applied only if that >>>> filter matches. >>>> >>>> [Kris] In this case this is based only on dest prefix. But sometimes >> it >>>> should be based on filters which are more flexible in identifying what >>>> should be translated (for example translate only traffic coming from >> these >>>> source IP addresses, or only going to those destination ports, ect). >>>> So I'm talking about real IP filters (or access-lists, however you call >>>> them) that are applied to interfaces. >>>> ------------------------------------------- >>>> If nat-pass-through is provided, all the traffic will be NATed except >> the >>>> one that matches the nat-pass-through filter(s). >>>> >>>> The current version allows to define multiple pools; each identified by >> an >>>> id. This id can be called typically for advanced filtering operations. >>>> Such filters are not supported in the current version. I'm open to >> discuss >>>> those with you. >>>> >>>> >>>> [Kris] yes, this is important. What is needed is a sort of >> classification >>>> block, where you say 'this traffic' is mapped to this 'pool'. >>>> This should be done via ip-filters that are applied to interfaces, and >>>> thus all together outside of NAT instance, or on a coarser level via >>>> subscriber-match that is a list with a leaf that accepts not only ip- >>>> prefix but a pool id (leafref) as well. >>>> >>>> Talking about multiple pools, it is possible that pools have different >>>> settings (max number of subs per outside IP address, etc). So pool >> config >>>> should have additional parameters (pool should be a list with multiple >>>> leafs). So we allow this today, a very flexible config that may now get >>>> restricted because of configuration constraints. >>>> >>>> ---------------- >>>> The reason why such advanced filters are not included is that the same >>>> objective can be achieved by defining multiple NAT instances; each with >>>> dedicated pools and port assignment policies . >>>> >>>> >>>> [Kris] True, but I was hoping that a more elegant solution can be >> found. >>>> Otherwise a new NAT instance would be required per pool. NAT instance >> even >>>> in your proposal supports multiple pools, it would be nice to find a >> way >>>> to selectively map traffic to those pools within the context of a NAT >>>> instance. >>>> >>>> Please note that a similar feature is supported for NAT64: the NAT64 >>>> prefix can be selected as a function of the destination prefix. >>>> >>>> +--rw nat64-prefixes* [nat64-prefix] >>>> | +--rw nat64-prefix inet:ipv6-prefix >>>> | +--rw destination-ipv4-prefix* [ipv4-prefix] >>>> | +--rw ipv4-prefix inet:ipv4-prefix >>>> >>>> One minor comment: from an IETF standpoint, "routing context" may be >>>> confusing for people as NAT is not a routing function. >>>> >>>>> >>>>> We have a different approach, with three main building blocks: >>>>> >>>>> 1) in inside (private) routing context we define parameters that are >>>>> related to inside. For example destination-prefix (what will get sent >>>>> to NAT for translation) in NAT44, then NAT64 prefix, deterministic nat >>>>> parameters, DS-lite AFTR address (I know that ds-lite is covered in >>>>> different draft), some other L2-Aware NAT parameters, etc. >>>> >>>> [Med] Putting aside that we mark explicitly those parameters as >> "inside", >>>> most of those parameters are supported in this version (and the DS-Lite >>>> YANG). >>>> >>>>> 2) then we go to outside routing contextS. There we define pool and >>>>> pool related parameters: outside-address range, pool watermarks, size >>>>> of the port-blocks in the pool, port-forwarding ranges in the pool, >>>>> number of subscribers per outside IP, etc. >>>> >>>> [Med] Great. Putting aside that we mark explicitly those parameters as >>>> "outside", those parameters are supported in this version. >>>> >>>>> 3) then we have a nat-policy that serves as a glue that connects the >>>>> inside routing context and the outside routing contexts (can be more >>>>> of >>>>> them) and the pools. >>>>> In nat-policy definition we reference a pool, enable ALGs, set the >>>>> session limit per subscriber, number of port-blocks per subscriber, >>>>> filtering mode, priority sessions (based on forwarding-class), timouts >>>>> (tpc, udp, icmp), etc. >>>>> This policy is then referenced in the inside routing context. At that >>>>> point when the packet is received in the inside, it knows which pool >>>>> (and outside routing context) it needs to go to - based on the >>>>> classification in the ip-filter with action NAT (applied to an >>>>> interface) or based on the destination-prefix (as configured in the >>>> inside routing context). >>>>> >>>>> The key is that we allow forking to multiple pools from the same >>>>> inside routing context. For example: >>>>> Destination-prefix 10.10.10.0/24 nat-policy "nat-pol-name-1" ==> >>>> nat- >>>>> pol-name-1 references a pool and the outside routing context >>>>> Destination-prefix 10.20.20.0/24 nat policy "nat-pol-name-2" ==> >>>>> nat-pol- >>>>> name-2 reference a different pool in the same outside routing context >>>>> as above or a different one >>>>> >>>>> (same can be achieved with filters that are applied to interfaces - >>>>> with filters we have a much wider range of classification options - >>>>> what gets diverted to NAT). >>>> >>>> [Med] Agree. Those are out of the scope. >>>> >>>>> >>>>> Then on a side, we have nat-classifiers that deal with destination- >> nat. >>>>> There we identify traffic that needs to be dNTAed and we specify the >>>>> dest- ip address in the same classifier. This classifier is then >>>>> applied in nat- policy as well. >>>>> >>>>> There are a few other pieces that deal with logging, pcp etc functions >>>>> that are scattered around, but this can be consolidated. But I'm >>>>> afraid that this 3 prong structure (inside, outside, nat-policy) would >>>>> be harder to consolidate. >>>>> >>>>> >>>>> From your proposal in the draft, I'm not clear how do you ensure >>>>> separation of routing context and selection of different pools. >>>> >>>> [Med] As mentioned above, the current model does support this by >> defining >>>> multiple NAT instances. >>>> >>>> I see that >>>>> inside interfaces and outside interfaces are referenced in the nat- >>>>> instance, but there is no mention of routing context (although this >>>>> can be derived from the interface name, assuming that intf name are >>>>> unique chassis wide). Moreover I can't see how do you ensure selection >>>>> of a pool based on some classification on ingress (say >>>>> destination-prefix A go to pool 1, destination-prefix B to pool 2). >>>> >>>> [Med] This is not supported within the same NAT instance. I'm open to >>>> discuss if/how to update the module to include this feature. >>>> >>>>> >>>>> >>>>> We definitely want to be part of this discussion >>>> >>>> [Med] Great! >>>> >>>> , but at this point I'm >>>>> not sure how to proceed. It would be great if you can advise. Thanks. >>>> >>>> [Med] I see the following options: >>>> (1) Continue the discussion in private to figure out what modifications >>>> can be implemented to address your comments. >>>> (2) Forward this mail to the OPSAWG mailing list and take it for there. >>>> >>>> Proceeding with both is also an option. For example, I can start by >>>> sharing your concern with the WG and then discuss in private how to >>>> address it. >>>> >>>> Please let me know your preference. >>>> >>>>> Kris >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Henderickx, Wim (Nokia - BE/Antwerp) >>>>> Sent: Thursday, August 31, 2017 11:31 PM >>>>> To: Poscic, Kristian (Nokia - US) <kristian.pos...@nokia.com> >>>>> Subject: FW: Request to review draft-ietf-opsawg-nat-yang-01 >>>>> >>>>> Can you comments on this? >>>>> >>>>> On 22/08/2017, 14:23, "mohamed.boucad...@orange.com" >>>>> <mohamed.boucad...@orange.com> wrote: >>>>> >>>>> Hi Wim, >>>>> >>>>> I hope you are doing well! >>>>> >>>>> Can you please review this model? I'm particularly interested to >>>>> see if the model is aligned with your 7750 NAT44/NAT64 implementation. >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>> > -----Message d'origine----- >>>>> > De : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] >>>>> > Envoyé : lundi 21 août 2017 11:10 >>>>> > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET >>>>> Christian >>>>> > IMT/OLN; opsawg-cha...@ietf.org; Qin Wu >>>>> > Objet : New Version Notification for draft-ietf-opsawg-nat-yang- >>>>> 01.txt >>>>> > >>>>> > >>>>> > A new version of I-D, draft-ietf-opsawg-nat-yang-01.txt >>>>> > has been successfully submitted by Mohamed Boucadair and posted >>>>> to the >>>>> > IETF repository. >>>>> > >>>>> > Name: draft-ietf-opsawg-nat-yang >>>>> > Revision: 01 >>>>> > Title: A YANG Data Model for Network Address >>>>> Translation >>>>> (NAT) >>>>> > and Network Prefix Translation (NPT) >>>>> > Document date: 2017-08-21 >>>>> > Group: opsawg >>>>> > Pages: 73 >>>>> > URL: https://www.ietf.org/internet-drafts/draft-ietf- >>>>> opsawg- >>>>> > nat-yang-01.txt >>>>> > Status: https://datatracker.ietf.org/doc/draft-ietf- >>>> opsawg- >>>>> nat- >>>>> > yang/ >>>>> > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg- >> nat- >>>>> yang-01 >>>>> > Htmlized: https://datatracker.ietf.org/doc/html/draft- >> ietf- >>>>> opsawg- >>>>> > nat-yang-01 >>>>> > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf- >>>> opsawg- >>>>> nat- >>>>> > yang-01 >>>>> > >>>>> > Abstract: >>>>> > For the sake of network automation and the need for >> programming >>>>> > Network Address Translation (NAT) function in particular, a >>>> data >>>>> > model for configuring and managing the NAT is essential. >> This >>>>> > document defines a YANG data model for the NAT function. >>>>> > >>>>> > NAT44, Network Address and Protocol Translation from IPv6 >>>> Clients >>>>> to >>>>> > IPv4 Servers (NAT64), Customer-side transLATor (CLAT), >> Explicit >>>>> > Address Mappings for Stateless IP/ICMP Translation (SIIT >> EIM), >>>>> and >>>>> > IPv6 Network Prefix Translation (NPTv6) are covered in this >>>>> document. >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > Please note that it may take a couple of minutes from the time >> of >>>>> > submission >>>>> > until the htmlized version and diff are available at >>>> tools.ietf.org. >>>>> > >>>>> > The IETF Secretariat >>>>> >>>>> >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>> > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
