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

From: Meral Shirazipour <[email-masked]>
Date: Mon, 12 Oct 2015 05:49:06 +0000

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.

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.

-[Page 8], Section 4.3, "There is intentionally no port set capability discovery mechanism.".
What is the intention? I could not find anything on the list discussion. It would be good to clarify this to make this section puroposeful.

-[Page 16] ,  Ref. [RFC7596] should be revised-it still refers to the draft.

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com

---

From: <[email-masked]>
Date: Tue, 13 Oct 2015 11:41:44 +0000

Dear Meral,

Many thanks for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Meral Shirazipour [mailto:[email-masked]]
> Envoyé : lundi 12 octobre 2015 07:49
> À : [email-masked]; [email-masked]
> 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.
> 
> -[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.  

> 
> 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].

> 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   

> -[Page 16] ,  Ref. [RFC7596] should be revised-it still refers to the
> draft

[Med] Thank you for catching this. This will be fixed.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 13 Oct 2015 08:39:41 -0400

> 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…

Not sure what you mean exactly. The use case we had in mind when we
wrote that sentence was a LW4o6 B4 that would fetch as many ports as it
could to use as a port pool. So it doesn't know in advance how many
ports it will use. It's just asking for as many as the AFTR is willing
to provide. I suppose a heuristic to release unused ports could be
possible, but it would make much more sense to simply configure the
maximum port set size on the AFTR to a value that makes operational sense.

Does that answer your question? Do you think changes to the text are
warranted?

Simon

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 13 Oct 2015 16:31:14 +0000

Hi,
  Many thanks for the clarifications. Please see inline.

Best,
Meral

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2015 4:42 AM
> To: Meral Shirazipour; [email-masked]; gen-
> [email-masked]
> Subject: RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Dear Meral,
> 
> > À : [email-masked]; [email-masked] 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
> > -[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."
> [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]

> >
> > Nits/editorial comments:
> > -[Page 6], "In particular, the PREFER_FAILURE option MUST NOT be
> > present in a request that contains a PORT_SET option.".
> [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 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).
> 
> [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" ?

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 13 Oct 2015 16:31:45 +0000

Hi Simon,
  Thank you for the reply. Please also see the exchange with Mohamed on this thread. 
I agree that the client may not know in advance, but I think what happens to the unused ports (i.e. when are they released?) is worth mentioning. A heuristic, guidance etc. would be useful. Also what-if scenarios, like many clients at once request with 0xffff, how should the server react to that?

Best,
Meral

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, October 13, 2015 5:40 AM
> Subject: Re: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> > -[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."
> could to use as a port pool. So it doesn't know in advance how many ports it
> will use. It's just asking for as many as the AFTR is willing to provide. I suppose
> a heuristic to release unused ports could be possible, but it would make
> much more sense to simply configure the maximum port set size on the AFTR
> to a value that makes operational sense.
>

---

From: <[email-masked]>
Date: Wed, 14 Oct 2015 06:32:20 +0000

Hi Miral,

Please see inline.

Cheers,
Med

> Envoyé : mardi 13 octobre 2015 18:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]; [email-masked]
> Objet : RE: Gen-ART Last Call review of draft-ietf-pcp-port-set-10
> 
> Hi,
> [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?

[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. 

> [MSh] That looks great, thank you.

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

> [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.

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 14 Oct 2015 15:41:14 +0000

Hi,
  Thank you Mohamed, I am ok with the clarifications and changes.

Best,
Meral

> Sent: Tuesday, October 13, 2015 11:32 PM
> To: Meral Shirazipour
> Cc: [email-masked]; [email-masked]
> > > To: Meral Shirazipour; [email-masked];
> > > gen- [email-masked]
> > > > Envoyé : lundi 12 octobre 2015 07:49 À :
> > > > [email-masked]; [email-masked] Objet
> > > > 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.
> > > >
> > >
> > > 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
> > [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?
> [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.
> 
> It is up to each operator to set those parameters. Traffic analyses are likely to
> help operators to set the appropriate values.
> 
> > > > 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
> http://www.ietf.org/proceedings/interim/2014/08/26/pcp/minutes/minut
> > > es -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].
> > >
> >
> > > 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).
> > >
> > > 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-
> > [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
> > >

---

From: <[email-masked]>
Date: Thu, 15 Oct 2015 05:27:18 +0000

Hi Meral,

Thank you again for your review. 

FWIW, the changes you requested have been included in the new revision available at: https://tools.ietf.org/html/draft-ietf-pcp-port-set-11 
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-port-set-11 

Cheers,
Med

> Envoyé : mercredi 14 octobre 2015 17:41

---

From: Meral Shirazipour <[email-masked]>
Date: Thu, 15 Oct 2015 06:02:10 +0000

Hi,
  Thank you.

Best,
Meral

> Sent: Wednesday, October 14, 2015 10:27 PM
> To: Meral Shirazipour
> FWIW, the changes you requested have been included in the new revision
> available at: https://tools.ietf.org/html/draft-ietf-pcp-port-set-11
> > Envoyé : mercredi 14 octobre 2015 17:41 À : BOUCADAIR Mohamed
> IMT/OLN
> > > > Envoyé : mardi 13 octobre 2015 18:31 À : BOUCADAIR Mohamed
> IMT/OLN
> > > > > To: Meral Shirazipour;
> > > > > [email-masked];
> > > > > gen- [email-masked]
> > > > > > -[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
> > > > > 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
> > > > [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.
> > > size of the port sets to be assigned taking into account various
> > > inputs
> > such as:
> > > port set and the actual usage from this set. This is exactly the
> > > same
> > issue with
> > > setting a port quota.
> > >
> > > It is up to each operator to set those parameters. Traffic analyses
> > > are
> > likely to
> > > > > > -[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
> > > > > 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].
> > > > >
> > > >
> > > > > capability. As a generic comment, the working group felt it is
> > > > > early to
> > > > define a
> > > > > http://www.ietf.org/proceedings/85/minutes/minutes-85-pcp
> > > > > (search for draft-boucadair-pcp-capability).
> > > > >
> > > [Med] Yes, that was the main issue raised at that time. After
> > > re-reading
> > the
> > > > > > -[Page 16] ,  Ref. [RFC7596] should be revised-it still refers
> > > > > > to the draft
> > > > >