Re: [OPSAWG] CLAT (was TR: New Version Notification for draft-ietf-opsawg-nat-yang-00.txt)

[<[e-mail]>]

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:[e-mail]]
> Envoyé : vendredi 18 août 2017 17:18
> À : BOUCADAIR Mohamed IMT/OLN; Lee Howard
> Cc : [e-mail]; JACQUENET Christian IMT/OLN; Senthil Sivakumar
> (ssenthil); Qin Wu; [e-mail]
> 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: <[e-mail]>
> Responder a: <[e-mail]>
> Fecha: viernes, 18 de agosto de 2017, 16:19
> Para: Lee Howard <[e-mail]>, "[e-mail]"
> <[e-mail]>
> CC: "[e-mail]" <[e-mail]>, JACQUENET Christian
> IMT/OLN <[e-mail]>, "Senthil Sivakumar (ssenthil)"
> <[e-mail]>, Qin Wu <[e-mail]>, "[e-mail]"
> <[e-mail]>
> 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:[e-mail]] De la part de
>     > [e-mail]
>     > Envoyé : vendredi 18 août 2017 15:46
>     > À : [e-mail]
>     > Cc : [e-mail]; 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 : [e-mail] [mailto:[e-mail]]
>     > > Envoyé : vendredi 18 août 2017 15:31
>     > > À : BOUCADAIR Mohamed IMT/OLN; Senthil Sivakumar; JACQUENET
> Christian
>     > > IMT/OLN; [e-mail]; 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
>     > [e-mail]
>     > 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.
> 
>