Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10

<mohamed.boucadair@orange.com> Wed, 14 October 2015 06:32 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A281ACD8A for <gen-art@ietfa.amsl.com>; Tue, 13 Oct 2015 23:32:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWUdW71o-efs for <gen-art@ietfa.amsl.com>; Tue, 13 Oct 2015 23:32:23 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9ED1ACD70 for <gen-art@ietf.org>; Tue, 13 Oct 2015 23:32:23 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A906B18C465; Wed, 14 Oct 2015 08:32:21 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 858AD238059; Wed, 14 Oct 2015 08:32:21 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0248.002; Wed, 14 Oct 2015 08:32:21 +0200
From: mohamed.boucadair@orange.com
To: Meral Shirazipour <meral.shirazipour@ericsson.com>
Thread-Topic: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
Thread-Index: AdEEsYXry8YyyGNTSQm7Xt/5JSS3SQA2sBSgABGCrRAAHSW24A==
Date: Wed, 14 Oct 2015 06:32:20 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933008C72ED7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <ABCAA4EF18F17B4FB619EA93DEF7939A45432563@eusaamb107.ericsson.se> <787AE7BB302AE849A7480A190F8B933008C72649@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ABCAA4EF18F17B4FB619EA93DEF7939A454350E8@eusaamb107.ericsson.se>
In-Reply-To: <ABCAA4EF18F17B4FB619EA93DEF7939A454350E8@eusaamb107.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.14.33317
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/Lkoi26KOGFO03QE_Du27qzAXBd0>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-pcp-port-set.all@tools.ietf.org" <draft-ietf-pcp-port-set.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pcp-port-set-10
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2015 06:32:26 -0000

Hi Miral,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Meral Shirazipour [mailto:meral.shirazipour@ericsson.com]
> Envoyé : mardi 13 octobre 2015 18:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : draft-ietf-pcp-port-set.all@tools.ietf.org; gen-art@ietf.org
> Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi,
>   Many thanks for the clarifications. Please see inline.
> 
> Best,
> Meral
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > [mailto:mohamed.boucadair@orange.com]
> > Sent: Tuesday, October 13, 2015 4:42 AM
> > To: Meral Shirazipour; draft-ietf-pcp-port-set.all@tools.ietf.org; gen-
> > art@ietf.org
> > Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> >
> > Dear Meral,
> >
> > Many thanks for the review.
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Meral Shirazipour [mailto:meral.shirazipour@ericsson.com]
> > > Envoyé : lundi 12 octobre 2015 07:49
> > > À : draft-ietf-pcp-port-set.all@tools.ietf.org; gen-art@ietf.org Objet
> > > : Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> > >
> > > I am the assigned Gen-ART reviewer for this draft. For background on
> > > Gen- ART, please see the FAQ at
> > > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
> > >
> > > Please resolve these comments along with any other Last Call comments
> > > you may receive.
> > >
> > > Document: draft-ietf-pcp-port-set-10
> > > Reviewer: Meral Shirazipour
> > > Review Date: 2015-10-10
> > > IETF LC End Date:  2015-10-14
> > > IESG Telechat date: NA
> > >
> > >
> > > Summary:
> > > This draft is ready to be published as Standards Track RFC but I have
> > > some comments.
> > >
> > >
> > > Major issues:
> > > N/A
> > >
> > > Minor issues:
> > > -[Page 7], Section 4.1, "If the PCP Client does not know the exact
> > > number of ports its requires, it MAY then set the Port Set Size to
> > > 0xffff, indicating that it is willing to accept as many ports as the
> > > PCP server can offer."
> > > Question/clarification to add: Mention if there a mechanism where the
> > > server will know which of the mapped ports are going to be used by the
> > > client? and which mappings can be discarded/reused in a subsequent
> > > request.
> > >
> >
> > [Med] I'm not sure to get your point, especially the link with the
> sentence
> > you quoted. But fwiw policies about granted port ranges (size), ports to
> be
> > excluded from assignment, etc. are implementation-specific. These are
> > similar to the behavior of the PCP server assigning single port numbers
> > (RFC6887). If the question is about renewal and/or port overlap, the
> behavior
> > is called out in Section 4.4.
> >
> 
> [MSh] Sorry I was a bit unclear here. I was wondering what happens if the
> client asks with 0xffff, receives e.g. 100 ports but only uses 20 of them.
> What happens to the rest? Would they be unused until the next renewal? If
> so efficiency is not affected?
> [please also see the thread reply by Simon]

[Med] Thank you for clarifying. The size of port ranges that are assigned to PCP clients is deployment-specific. Operators will need to tune the maximum size of the port sets to be assigned taking into account various inputs such as: optimize the use of the shared addresses, reduce the amount of pcp messages, etc. Of course, efficiency will depend on the size of the assigned port set and the actual usage from this set. This is exactly the same issue with setting a port quota. 

FWIW, below is provided a sample YANG excerpt to configure the port set feature in a PCP server. 

   grouping port-set-option {
       description
                    "PORT_SET option.";

       leaf port-set-enable {
          type boolean;
          description
             "Enable/disable PORT_SET option.";
       }

       leaf default-port-set-size {
          type uint16;
          description
             "Indicates the default size of a port set.";
       }

       leaf maximum-port-set-size {
          type uint16;
          description
             "Indicates the maximum size of a port set.";
       }
   }

It is up to each operator to set those parameters. Traffic analyses are likely to help operators to set the appropriate values. 

The port-set draft does not need to deal with these aspects as those are deployment-specific. 

> 
> > >
> > > Nits/editorial comments:
> > > -[Page 6], "In particular, the PREFER_FAILURE option MUST NOT be
> > > present in a request that contains a PORT_SET option.".
> > > Suggestion: Please add a sentence after this one suggesting why
> > > PREFER_FAILURE option MUST NOT be used. It was not clear to me until I
> > > read the rest of the draft...although I am still not sure why this
> > > behavior is to be a MUST NOT.
> >
> > [Med] PREFER_FAILURE was specifically designed for the interworking with
> > UPnP IGD:1 (RF6970). The rationale why it should not be used by other
> PCP
> > clients (than the iwf) is discussed in Section 13.2 of RFC6887. The
> language in
> > this draft is stronger than RFC6887, though. The decision about the
> language
> > to use was made in an interim meeting (see the minutes at:
> > http://www.ietf.org/proceedings/interim/2014/08/26/pcp/minutes/minutes
> > -interim-2014-pcp-1). We can add the following sentence.
> >
> > NEW:
> > As a reminder PREFER_FAILURE was specifically designed for the Universal
> > Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol
> > Interworking Function (IGD-PCP IWF) [RF6970]. The reasons for not
> > recommending the use of PREFER_FAILURE are discussed in Section 13.2 of
> > [RFC6887].
> >
> 
> [MSh] That looks great, thank you.

[Med] This will be added to the next revision of the draft.

> 
> > >
> > > -[Page 8], Section 4.3, "There is intentionally no port set capability
> > > discovery mechanism.".
> > > What is the intention?
> >
> > [Med] This sentence is there to explicitly call out that this
> specification does
> > not define a mean to discover whether the PCP server support the port
> set
> > capability. As a generic comment, the working group felt it is early to
> define a
> > mechanism to retrieve the capabilities of the PCP server (and the PCP-
> > controlled device): see the minutes available here:
> > http://www.ietf.org/proceedings/85/minutes/minutes-85-pcp (search for
> > draft-boucadair-pcp-capability).
> >
> >  I could not find anything on the list discussion.
> > > It would be good to clarify this to make this section puroposeful.
> > >
> >
> > [Med] This section was added to address the comment recorded in the
> > minutes: http://www.ietf.org/proceedings/88/minutes/minutes-88-pcp. See
> > the changes here: https://www.ietf.org/rfcdiff?url1=draft-ietf-pcp-port-
> set-
> > 04&url2=draft-ietf-pcp-port-set-05
> >
> 
> [MSh] Thank you for the pointers, so if I understand correctly the reason
> is "because they cause unnecessary failures" ?
> 

[Med] Yes, that was the main issue raised at that time. After re-reading the text, I think we can delete "There is intentionally no port set capability discovery mechanism.", the rest of the paragraph is clear enough. 

> 
> > > -[Page 16] ,  Ref. [RFC7596] should be revised-it still refers to the
> > > draft
> >
> > [Med] Thank you for catching this. This will be fixed.