Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt

[Dave Thaler <[e-mail]>]

I read through the latest version and I think this is very close now.



Here's my feedback on -02:



> REQ-7:  When a CGN loses state (due to a crash, reboot, failover to a

>         cold standby, etc.), it MUST NOT reuse the same external IP

>         addresses for new dynamic mappings for at least 120 seconds.

          ^^^^^^^^^



I believe REQ-7 should probably say "ports" (or "address/port pairs")

not "addresses".   As long as there's no collisions between old and new

addr/port pairs, it doesn't matter whether it uses different ports for

the same address or a different address.



> REQ-9:  A CGN MUST handle the IPv4 ID field of translated packets as

>         described in [I-D.ietf-intarea-ipv4-id-update] section 9.



Is this really specific to a CGN?  Or would it apply to *all* NATs?

The justification section implies that I-D.ietf-intarea-ipv4-id-update

section 9 already provides a justification for this being CGN specific.

It doesn't, as far as I can tell, so additional elaboration is needed

if this (or at least raising it to a MUST) is CGN specific.



> REQ-10:  A CGN SHOULD support a port forwarding protocol such as the

>          Port Control Protocol [I-D.ietf-pcp-base].



Wording is ambiguous.  What does "support" mean?  For example, if it

can be a PCP client but not a PCP server, does that pass? (it shouldn't)

Furthermore, the justification provided is insufficient in my opinion,

given that a specific protocol is not even recommended.  For example,

would it be ok if someone implemented the SHOULD with some protocol

no CPE supported, or if every CGN vendor had a proprietary protocol?

Again my point is that it's ambiguous.  My personal preference would be

to explicitly say that PCP server support is a SHOULD, and move pcp-base

to a normative reference.



>   REQ-13:  When a CGN is unable to create a mapping due to resource

>            contraints or administrative restrictions (i.e. quotas)...

             ^^^^^^^^^^

Typo: constraints



[...]

>            D.  and it MUST NOT delete existing mappings in order to

>                "make room" for the new one.



I don't understand why the above is a MUST NOT (especially if the old

mapping has been idle for a long time).  Either provide justification

or relax this.



Section 4:

>   o  destination address (but see below)

>   o  destination port (but see below)



It's unclear whether this means a CGN MUST, SHOULD,

or MAY log dest addr/port.   This document should be

clear enough for someone to write a compliance test.

In fact this entire section has no normative

requirements language :(



My personal opinion is that logging support is a

SHOULD, but dest addr/port support is only a MAY.

But I'm open to other opinions.



Section 5:

> There is a range of things a CGN can do:



Suggest s/can/MAY/



(And as it says, it's not a complete list and

I can easily imagine other algorithms that would

be better in many/most cases.)



-Dave



> -----Original Message-----

> From: [e-mail] [mailto:[e-mail]] On Behalf

> Of Simon Perreault

> Sent: Monday, July 11, 2011 12:11 PM

> To: [e-mail]

> Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-02.txt

>

> [e-mail]<mailto:[e-mail]> wrote, on 07/11/2011 03:08 PM:

> > A New Internet-Draft is available from the on-line Internet-Drafts

> directories. This draft is a work item of the Behavior Engineering for

> Hindrance Avoidance Working Group of the IETF.

> >

> > Title           : Common requirements for Carrier Grade NAT (CGN)

> > Author(s)       : Simon Perreault

> >                           Ikuhei Yamagata

> >                           Shin Miyakawa

> >                           Akira Nakagawa

> >                           Hiroyuki Ashida

> > Filename        : draft-ietf-behave-lsn-requirements-02.txt

> > Pages           : 16

> > Date            : 2011-07-11

>

> This revision introduces many important changes. As far as I know it

> addresses every issue that was raised.

>

> Here's the change log:

>

>    o  CGNs MUST support at least TCP, UDP, and ICMP.

>

>    o  Add requirement from [I-D.ietf-intarea-ipv4-id-update].

>

>    o  Add informative reference to

>       [I-D.ietf-intarea-shared-addressing-issues].

>

>    o  Add requirement (SHOULD level) for a port forwarding protocol.

>

>    o  Allow any pooling behavior on a per-application protocol basis.

>

>    o  Adjust wording for external port allocation rate limiting.

>

>    o  Add requirement for RFC4008 support (SHOULD level).

>

>    o  Adjust wording for swapping address pools when rebooting.

>

>    o  Add DSCP requirement (stolen from draft-jennings-behave-nat6).

>

>    o  Add informative reference to

>       draft-boucadair-intarea-nat-reveal-analysis.

>

>    o  Add requirement for hold-down pool.

>

>    o  Change definition of CGN.

>

>    o  Avoid usage of "device" loaded word throughout the document.

>

>    o  Add requirement about resource exhaustion.

>

>    o  Change title.

>

>    o  Describe additional CGN topology where there is no NAT444.

>

>    o  Better justification for "Paired" pool behavior.

>

>    o  Make it clear that rate limiting allocation is for preserving CPU

>       resources

>

>    o  Generalize the requirement for limiting the number of TCP sessions

>       per mapping so that it applies to all memory-consuming state

>       elements.

>

>    o  Change CPE to subscriber where it applies throughout the text.

>

>    o  Better terminology for bulk port allocation mechanisms.

>

>    o  Explain how external address pairing works with DS-Lite.

>

> Simon

> --

> DTN made easy, lean, and smart --> http://postellation.viagenie.ca

> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca

> STUN/TURN server               --> http://numb.viagenie.ca

> _______________________________________________

> Behave mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/behave