Re: [OPSAWG] WG LC for Service Models Explained
> Authors: > Although this is an informational document, please indicate with an email on the > mailing list explicitly whether you are aware or you are not aware of any IPRs > related to the drafts. > > [Qin]: Receive kindly reminder from chairs recently, thanks. here I confirm that > we have no IPR and also we are not aware of any IPRs related to this draft. Not sure whether I responded. Anyway... No, I am not aware of any IPR related to this draft. Thanks, Adrian ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] WG adoption poll for draft-sivakumar-yang-nat-07
Hello opsawg, We are at the end of our call for adoption, and based on discussion on this list, there seems to be enough support to adopt this work for the opsawg. In addition to simple replies of support, this work is being leveraged in other working groups. I would ask the authors to keep in contact with the softwire work at least to make sure there aren't any bottlenecks, as well as to get additional reviews. Additionally, authors, can you please update the draft and resubmit as a WG document? Joe for the opsawg chairs On 7/27/17 10:09, Joe Clarke wrote: > Greetings OPSAWG, > > After this draft was presented in Prague, it was stated that we would do > a call for adoption on the list. There seemed to be general support for > the work. Therefore, this will serve as the chairs’ formal adoption > poll for this document into OPSAWG. > > YANG Data Model for Network Address Translation (NAT) > https://datatracker.ietf.org/doc/draft-sivakumar-yang-nat/ > > This poll request will go for three weeks to allow for the summer > vacation time. Please get your feedback (and initial reviews) in by > August 17, 2017. > > In addition to simply supporting the adoption, please also let us know > if you are willing to review the work as it progresses. > > Thank you. > > Joe (for the co-chairs) ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] I-D Action: draft-ietf-opsawg-nat-yang-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group WG of the IETF. Title : A YANG Data Model for Network Address Translation (NAT) and Network Prefix Translation (NPT) Authors : Mohamed Boucadair Senthil Sivakumar Christian Jacquenet Suresh Vinapamula Qin Wu Filename: draft-ietf-opsawg-nat-yang-00.txt Pages : 67 Date: 2017-08-18 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-nat-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-00 https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-nat-yang-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[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 : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Envoyé : vendredi 18 août 2017 15:31 > À : 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-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 OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt)
Re-, Forwarded to the OPSAWG list. Please use this messages when replying. Apologies for the inconvenience. Cheers, Med > -Message d'origine- > De : BOUCADAIR Mohamed IMT/OLN > Envoyé : vendredi 18 août 2017 16:19 > À : 'Lee Howard'; jordi.pa...@consulintel.es > Cc : opsawg-cha...@ietf.org; JACQUENET Christian IMT/OLN; Senthil > Sivakumar (ssenthil); 'Qin Wu'; sure...@juniper.net > Objet : 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-prefixinet:ipv4-prefix > > NEW: > > +--rw nat64-prefixes* [nat64-prefix] > | +--rw nat64-prefix inet:ipv6-prefix > | +--rw destination-ipv4-prefix* [ipv4-prefix] > | +--rw ipv4-prefixinet: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:opsawg-boun...@ietf.org] De la part de > > mohamed.boucad...@orange.com > > Envoyé : vendredi 18 août 2017 15:46 > > À : opsawg@ietf.org > > Cc : sure...@juniper.net; 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 : internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > > > Envoyé : vendredi 18 août 2017 15:31 > > > À : 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-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
Re: [OPSAWG] 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: Responder a: Fecha: viernes, 18 de agosto de 2017, 16:19 Para: Lee Howard , "jordi.pa...@consulintel.es" CC: "opsawg-cha...@ietf.org" , JACQUENET Christian IMT/OLN , "Senthil Sivakumar (ssenthil)" , Qin Wu , "sure...@juniper.net" 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-prefixinet:ipv4-prefix NEW: +--rw nat64-prefixes* [nat64-prefix] | +--rw nat64-prefix inet:ipv6-prefix | +--rw destination-ipv4-prefix* [ipv4-prefix] | +--rw ipv4-prefixinet: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:opsawg-boun...@ietf.org] De la part de > mohamed.boucad...@orange.com > Envoyé : vendredi 18 août 2017 15:46 > À : opsawg@ietf.org > Cc : sure...@juniper.net; 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) > - Inclu
