Hi Joe, Thank you for sharing your thoughts.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Joe Clarke [mailto:jcla...@cisco.com] > Envoyé : mercredi 27 septembre 2017 14:36 > À : BOUCADAIR Mohamed IMT/OLN; opsawg@ietf.org > Cc : Poscic, Kristian (Nokia - US) (kristian.pos...@nokia.com) > Objet : Re: [OPSAWG] TR: Request to review draft-ietf-opsawg-nat-yang-01 > > On 9/26/17 10:06, mohamed.boucad...@orange.com wrote: > > Dear OPSAWG, > > > > I have requested an external review of the draft from a vendor who is > not a co-author of the draft. > > > > Kris (cced) has kindly shared his comments about the current structure > of the module and voiced for some features (mainly to allow for distinct > pools; each with its specific parameters). I'm forwarding the latest > exchange. > > > > As you can read in the exchange below, the current version of the draft > allows to achieve the same objective by defining multiple NAT instances. > Each of these instances may have its own parameters and policies. Further, > the draft allows to define multiple pools within the same instance, but it > is silent about how to bind specific flows to a given pool. The initial > reason was that we wanted to focus on the NAT function rather than > overloading the module with advanced classification functions (that are > not specific to NAT). > > > > Of course, we will continue the discussion with Kris to figure out which > changes are to be implemented. In the meantime, inputs from the working > group are more than welcome. > > Speaking as a co-chair, I would want to avoid over-complicating the > model to the point that it can never be ratified. [Med] Same here as an editor of the document. 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. 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 > > 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
