Hi Jordi, all, Thank you for the feedback.
A new version that takes into account your suggestions is available online. Please check: 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 Cheers, Med > -----Message d'origine----- > De : JORDI PALET MARTINEZ [mailto:[email protected]] > Envoyé : vendredi 18 août 2017 17:18 > À : BOUCADAIR Mohamed IMT/OLN; Lee Howard > Cc : [email protected]; JACQUENET Christian IMT/OLN; Senthil Sivakumar > (ssenthil); Qin Wu; [email protected] > Objet : Re: CLAT (was TR: New Version Notification for draft-ietf-opsawg- > nat-yang-00.txt) > > Hi Med, > > Looks good to me, and I think it covers all the possible options, which > one exception: > > +--rw clat-ipv4-address? inet:ipv4-address > > You may want to use a prefix, not an address. If you have a CLAT serving a > “big” network, instead of a small CE, you may need to use a pool of > several IP addresses. For example, in a recent testing, I used for the > stateless CLAT (NAT46) the following EAMT (Explicit Address Mappings > Table, RFC7757): > > Pool IPv4/NAT46: 100.64.0.0/10 > Pool IPv6: 2001:470:68ee:30::/106 > > (I was a bit exaggerated here, with so big pool, but is only an example) > > So may be something like: > +--rw clat-ipv4-address? inet:ipv4-address > +--rw clat-ipv4-mask? inet:ipv4-mask > > Note that I’m NOT expert in YANG, but I just read thru all your ID and > looks ok. > > Some other details that you may want to consider: > 1) Say something about CLAT/NAT46/464XLAT in the abstract. > 2) Same for the intro. > 3) Same in section 2.2. > 4) You may need to add also something in 2.8, at paragraph: > In order to cover both NAT64 and NAT44 flavors in particular, the NAT > mapping structure allows to include an IPv4 or an IPv6 address as an > internal IP address. Remaining fields are common to both NAT > schemes. > 5) Also I think in 2.8 “Note that a mapping table is maintained only for > stateless NAT” you actually mean stateful NAT ? > 6) You could also rewrite (2.8) “Obviously, no mapping table is maintained > for NPTv6 given that it is stateless and transport-agnostic” as > “Obviously, no mapping table is maintained for any stateless NAT (such as > NAT46), neither for NPTv6 given that it is stateless and transport- > agnostic” > 7) Instead of +--rw subscriber-mask-v6?, should mask be prefix-length? > 8) In section 3, I see you have some “code” for each NAT type, so you may > need also for NAT46? > 9) And of course, you may want to add a CLAT example at the appendix ;-) > > Hope it helps! > > Saludos, > Jordi > > > -----Mensaje original----- > De: <[email protected]> > Responder a: <[email protected]> > Fecha: viernes, 18 de agosto de 2017, 16:19 > Para: Lee Howard <[email protected]>, "[email protected]" > <[email protected]> > CC: "[email protected]" <[email protected]>, JACQUENET Christian > IMT/OLN <[email protected]>, "Senthil Sivakumar (ssenthil)" > <[email protected]>, Qin Wu <[email protected]>, "[email protected]" > <[email protected]> > Asunto: CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat- > yang-00.txt) > > Hi Lee, > > (I'm adding Jordi to the discussion since he is familiar with CLAT in > a CPE) > > You suggested in Prague to add CLAT to the NAT YANG module. > > Please find below how we are planning to cover it in the next > iteration of the draft: > > (1) If a dedicated prefix is configured for CLAT, then only a > stateless XLAT will be required. That is, no mapping table will be > maintained at all. Since the module already includes NAT64 prefix(es), the > CLAT IPv6 prefix will be missing. The tree structure can be updated as > follows: > > OLD: > +--rw nat64-prefixes* [nat64-prefix] > | +--rw nat64-prefix inet:ipv6-prefix > | +--rw destination-ipv4-prefix* [ipv4-prefix] > | +--rw ipv4-prefix inet:ipv4-prefix > > NEW: > > +--rw nat64-prefixes* [nat64-prefix] > | +--rw nat64-prefix inet:ipv6-prefix > | +--rw destination-ipv4-prefix* [ipv4-prefix] > | +--rw ipv4-prefix inet:ipv4-prefix > +--rw clat-ipv6-prefix? inet:ipv6-prefix > > (2) If no dedicated /64 prefix is provided, a NAT44 will be required. > A stateless XLAT will be then applied on NATed packets. This case is > natively supported by the current YANG model. > > A CLAT module can automatically select an IPv4 address from > 192.0.0.0/29 (RFC7335). This address can also be set. To do so, the tree > structure can be updated with: > > NEW: > ... > +--rw clat-ipv4-address? inet:ipv4-address > ... > > The CLAT IPv4 address will be taken by default from 192.0.0.0/29. > Other addresses can be used. > > Lee/Jordi, are there any other required changes? > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : OPSAWG [mailto:[email protected]] De la part de > > [email protected] > > Envoyé : vendredi 18 août 2017 15:46 > > À : [email protected] > > Cc : [email protected]; JACQUENET Christian IMT/OLN > > Objet : [OPSAWG] TR: New Version Notification for draft-ietf-opsawg- > nat- > > yang-00.txt > > > > Dear all, > > > > The -00 version integrates the comments received during the Call for > > Adoption: > > > > - Clarify how Destination NAT is covered (Tianran) > > - Follow the NMDA guidelines (Juergen and Qin) > > - Include a generic structure for ALGs instead of listing supported > ones > > (Juergen) > > - Include a discussion about how other transport protocols are/can > be > > supported (Juergen) > > - Include a comprehensive list of examples (Juergen) > > - Move the example to an appendix (Juergen) > > > > We do still have one pending comment that was raised by Lee Howard > when I > > presented in Prague: add CLAT to the list. > > > > Comments are more than welcome. Please review. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : [email protected] [mailto:[email protected]] > > > Envoyé : vendredi 18 août 2017 15:31 > > > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET > Christian > > > IMT/OLN; [email protected]; Qin Wu > > > Objet : New Version Notification for draft-ietf-opsawg-nat-yang- > 00.txt > > > > > > > > > A new version of I-D, draft-ietf-opsawg-nat-yang-00.txt > > > has been successfully submitted by Mohamed Boucadair and posted to > the > > > IETF repository. > > > > > > Name: draft-ietf-opsawg-nat-yang > > > Revision: 00 > > > Title: A YANG Data Model for Network Address > Translation > (NAT) and > > > Network Prefix Translation (NPT) > > > Document date: 2017-08-18 > > > Group: opsawg > > > Pages: 67 > > > URL: https://www.ietf.org/internet-drafts/draft-ietf- > opsawg- > > > nat-yang-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-ietf- > opsawg-nat- > > > yang/ > > > Htmlized: https://tools.ietf.org/html/draft-ietf-opsawg-nat- > yang- > > 00 > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf- > opsawg- > > > nat-yang-00 > > > > > > > > > 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, > > > NAT64, and 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. > > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
