Subject: Re: [pcp] pcp-base-19

From: Tina TSOU <[email-masked]>
Date: Wed, 21 Dec 2011 18:19:21 +0000

Hi all,
Some comments on pcp-base-19:

1. P17, section 6.3 / P18, section 6.4
"If the PCP server does not implement this Option, ..."
"UNSUPP_OPTION: Unsupported Option.  This error only occurs if the Option is in the mandatory-to-process range."
	 
Why do we set this restriction "only occurs if the Option is in the mandatory-to-process range."?
I think UNSUPP_OPTION error code is better than MALFORMED_OPTION if there is an unsupported optional Option. 

2. P28, section 9 
"It is REQUIRED that the PCP-controlled device assign the same
external IP address to PCP-created explicit dynamic mappings and to
implicit dynamic mappings for a given Internal Address. In the absence 
of a PCP option indicating otherwise, it is REQUIRED that all
PCP-created explicit dynamic mappings be assigned the same external
IP address."
   
How about replace "In the absence of a PCP option indicating otherwise, it is REQUIRED that all PCP-created explicit dynamic mappings be assigned the same external IP address." 
with 
"It is indicated by the PCP client that PCP-created explicit dynamic 
mappings be assigned the same external IP address, unless there are 
explicit reasons of not doing so, e.g. http://tools.ietf.org/html/draft-penno-pcp-zones-00"?
   
Because "It is REQUIRED that the PCP" give the requirement from the server's point of view, I think we should also give the requirement from the client's point of view. 
This is more or less what Dan suggested before, perhaps an oversight.

3. P38, section 10.2 
"the PCP server may not be able grant the suggested External IP Address and Port"
	 
typo? be able to?  
	 
4. P57, section 12.3
"the value of the Prefix Length pertains only to to the IPv4 portion of the address." 
	 
typo, duplicate "to"
	 
5. P59, section 13.1.1
"In many networking APIs is is difficult or	impossible to have two independent clients listening for both unicasts and multicasts on the same port at the same time.  For this reason, two ports are used."
 	 
typo, duplicate "is"
 	      
6. P61, section 13.1.4 Processing a PEER Response

the title "PEER Response", 

guess it should be "ANNOUNCE"

"then for all PCP mappings it made at that server address the client should issue new PCP requests to to recreate any lost mapping state. "

typo, duplicate "to"

Happy holidays,
Tina

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Monday, December 19, 2011 5:21 PM
To: 'PCP'
Subject: [pcp] pcp-base-19

Major changes in -19 are summarized in the Changes section, and
are:

   o  Described race condition with MAP containing PREFER_FAILURE and
      Mapping Update.

   o  Added state machine (Section 14.5).

   o  Fully integrated Rapid Recovery, with a separate Opcode having its
      own processing description.

   o  Clarified that due to Mapping Update, a single MAP or PEER request
      can receive multiple responses, each updating the previous
      request, and that the PCP client needs to handle MAP updates or
      PEER updates accordingly.

Side-by-side diffs,
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-19.txt

-d

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Dec 2011 14:56:03 -0800

> From: Tina TSOU [mailto:[email-masked]]
> Sent: Wednesday, December 21, 2011 10:19 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] pcp-base-19
> 
> Hi all,
> "UNSUPP_OPTION: Unsupported Option.  This error only occurs if the
> Option is in the mandatory-to-process range."
> 

Unsupported optional Options don't cause errors to be generated;
they are simply ignored (as if not present in the request) and the 
PCP response won't contain those Options (as if not present in the 
request)

The full text is:

   The most significant bit in the Option Code indicates if its
   processing is optional or mandatory.  If the most significant bit is
   set, handling this Option is optional, and a PCP server MAY process
   or ignore this Option, entirely at its discretion.  If the most
   significant bit is clear, handling this Option is mandatory, and a
   PCP server MUST process this Option or return an error code if it
   cannot.  If the PCP server does not implement this Option, or cannot
   perform the function indicated by this Option (e.g., due to a parsing
   error with the Option), it MUST generate an error response with code
   UNSUPP_OPTION or MALFORMED_OPTION (as appropriate).

That last sentence is intended to only apply if the significant bit
is clear.  I agree that is not clear.  I will replace the paragraph above
with this new paragraph, which indicates any sort of parsing error
generates MALFORMED_OPTION, and indicates when options are included
in responses:

        <t>If an Option cannot successfully be parsed, the PCP server
        MUST generate an error response with code MALFORMED_OPTION.
        The most significant bit in the Option Code indicates if its
        processing is optional or mandatory.  If the most significant
        bit is set, handling this Option is optional, and a PCP server
        MAY process or ignore this Option, entirely at its discretion.
        If the most significant bit is clear, handling this Option is
        mandatory, and a PCP server MUST process this Option or return
        the error UNSUPP_OPTION if it cannot.  All processed options
        are returned in successful responses, and unprocessed options 
        are not included in successful responses.</t>

> How about replace "In the absence of a PCP option indicating otherwise,
> it is REQUIRED that all PCP-created explicit dynamic mappings be
> assigned the same external IP address."
> with
> explicit reasons of not doing so, e.g.
> http://tools.ietf.org/html/draft-penno-pcp-zones-00"?
>
> Because "It is REQUIRED that the PCP" give the requirement from the
> server's point of view, I think we should also give the requirement
> from the client's point of view.

I don't understand the nuance between the wording.  Can you give an
example of what the existing text prohibits / breaks / disallows?

> "the PCP server may not be able grant the suggested External IP Address

Thanks, fixed.

> "the value of the Prefix Length pertains only to to the IPv4 portion of

Thanks, fixed.

> 5. P59, section 13.1.1
> "In many networking APIs is is difficult or	impossible to have two
> independent clients listening for both unicasts and multicasts on the
> same port at the same time.  For this reason, two ports are used."
> 
> typo, duplicate "is"

Thanks, fixed to read "it is".

> guess it should be "ANNOUNCE"

Oops, thanks.  Fixed.

> "then for all PCP mappings it made at that server address the client
> should issue new PCP requests to to recreate any lost mapping state. "
> 
> typo, duplicate "to"

Thanks, fixed.

-d

---

From: Tina TSOU <[email-masked]>
Date: Wed, 21 Dec 2011 23:06:00 +0000

Sent from my iPad

On Dec 21, 2011, at 2:56 PM, "Dan Wing" <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]]
Sent: Wednesday, December 21, 2011 10:19 AM
To: Dan Wing
Cc: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]>
Subject: Re: [pcp] pcp-base-19

Hi all,

Why do we set this restriction "only occurs if the Option is in the
mandatory-to-process range."?
I think UNSUPP_OPTION error code is better than MALFORMED_OPTION if
there is an unsupported optional Option.

The full text is:

Will get back to u after my current meeting.

2. P28, section 9

I don't understand the nuance between the wording.  Can you give an
example of what the existing text prohibits / breaks / disallows?
The existing text disallows client to request same external IP proactively. You agreed my comments earlier before.

3. P38, section 10.2
"the PCP server may not be able grant the suggested External IP Address
and Port"

typo? be able to?

Thanks, fixed.

4. P57, section 12.3
"the value of the Prefix Length pertains only to to the IPv4 portion of
the address."

typo, duplicate "to"

Thanks, fixed.

5. P59, section 13.1.1

typo, duplicate "is"

Oops, thanks.  Fixed.

typo, duplicate "to"

Thanks, fixed.
If there are tools to find this kind of nits, our work would be easier.

-d

Happy holidays,
Tina

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Dan Wing
Sent: Monday, December 19, 2011 5:21 PM
To: 'PCP'
Subject: [pcp] pcp-base-19

  o  Fully integrated Rapid Recovery, with a separate Opcode having
its
     own processing description.

  o  Clarified that due to Mapping Update, a single MAP or PEER
request
     can receive multiple responses, each updating the previous
     request, and that the PCP client needs to handle MAP updates or
     PEER updates accordingly.

Side-by-side diffs,

-d

_______________________________________________
pcp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pcp

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Dec 2011 15:55:38 -0800

> Sent: Wednesday, December 21, 2011 3:06 PM
> To: Dan Wing
> Cc: [email-masked]
...
> The existing text disallows client to request same external IP
> proactively.

The client can request the address it wants in the Suggested 
External Address field, which exists for both MAP and PEER.

> You agreed my comments earlier before.

I recall a discussion on this previously, yes.  I don't recall any
definitive conclusion.  Here are pointers to the end of two
threads related to the previous discussion:

http://www.ietf.org/mail-archive/web/pcp/current/msg01632.html
http://www.ietf.org/mail-archive/web/pcp/current/msg01627.html

If there was a definitive conclusion previously please provide 
a pointer and accept my apologies for my oversight.

-d

---

From: Tina TSOU <[email-masked]>
Date: Fri, 23 Dec 2011 08:51:30 +0000

Dan,
In line...

- Tina

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, December 21, 2011 3:56 PM
To: Tina TSOU
Cc: [email-masked]
Subject: RE: [pcp] pcp-base-19

...

The client can request the address it wants in the Suggested 
External Address field, which exists for both MAP and PEER.
[Tina: Excellent! So some descriptive text is needed here to describe these protocol operations before digging into the messages and fields.]

[Tina:
http://www.ietf.org/mail-archive/web/pcp/current/msg01391.html
You said in Date: Tue, 7 Jun 2011 11:26:39 -0700
"I think see what you're wanting the document to say.  

How about this proposed text, instead:

  If there is already an active explicit dynamic mapping,
  it will be mapped to a certain external IP address.
  When the PCP client makes another explicit dynamic mapping,
  it SHOULD place the external IP address of the existing
  mapping into the Requested External Address of the MAP 
  request.  By doing this, all of the PCP client's explicit
  dynamic mappings will be on the same external address.

Does that say the same thing?

Is it acceptable?

-d"

I answer now "Yes, it is." Sorry for the very laaate answer from summer till X'mas. Merry X'mas!
]

-d

-d

---

From: Tina TSOU <[email-masked]>
Date: Fri, 23 Dec 2011 08:52:39 +0000

Dan,

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Wednesday, December 21, 2011 2:56 PM
To: Tina TSOU
Cc: [email-masked]
Subject: RE: [pcp] pcp-base-19

The full text is:

[Tina: OK, it sounds reasonable now. I have no further issue for this point.]

Thanks, fixed.

Thanks, fixed.

Oops, thanks.  Fixed.

Thanks, fixed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 23 Dec 2011 11:01:41 -0800

> Sent: Friday, December 23, 2011 12:52 AM
> To: Dan Wing
> Cc: [email-masked]
> [Tina: Excellent! So some descriptive text is needed here to describe
> these protocol operations before digging into the messages and fields.]
> 

Ok, I think I understand now.  My proposed text, above, isn't
quite right, either (the last sentence of my proposed text is
cannot be true, because no matter the value in Suggested 
External Address, the PCP server can ignore that value; it is
only draft-penno-pcp-zones that changes that).

Please review this change:

OLD (contents of -19):
   It is REQUIRED that the PCP-controlled device assign the same
   external IP address to PCP-created explicit dynamic mappings and to
   implicit dynamic mappings for a given Internal Address.  In the
   absence of a PCP option indicating otherwise, it is REQUIRED that all
   PCP-created explicit dynamic mappings be assigned the same external
   IP address.  It is RECOMMENDED that static mappings for that Internal
   Address (e.g., those created by a command-line interface on the PCP
   server or PCP-controlled device) also be assigned to the same IP
   address.  Once an Internal Address has no implicit dynamic mappings
   and no explicit dynamic mappings in the PCP-controlled device, a
   subsequent PCP request for that Internal Address MAY be assigned to a
   different External Address.  Generally, this re-assignment would
   occur when a CGN device is load balancing newly-seen hosts to its
   public IPv4 address pool.

NEW:
   The MAP and PEER requests include a Suggested External IP Address
   field.  This field is a hint and ignored by the PCP-controlled device
   if there are other mappings for that Internal Address, unless there
   is an explicit Option in the request indicating otherwise (e.g.,
   PREFER_FAILURE, [I-D.penno-pcp-zones]).  For a PCP explicit dynamic
   mapping request for a given Internal Address, which does not
   contain an explicit Option to override the following behavior, the
   PCP-controlled device MUST assign the same External Address to that
   PCP-created explicit dynamic mapping and MUST assign it the same
   External Address as existing implicit dynamic mappings.  Static 
   mappings for that Internal Address (e.g., those created by a 
   command-line interface on the PCP server or PCP-controlled device) 
   SHOULD also be assigned to the same External Address.  Once an 
   Internal Address has no implicit dynamic mappings and no explicit 
   dynamic mappings in the PCP-controlled device, a subsequent implicit 
   or explicit mapping for that Internal Address MAY be assigned to a 
   different External Address.  Generally, this re-assignment would 
   occur when a CGN device is load balancing newly-seen Internal 
   Addresses to its public pool of External Addresses.

-d

---

From: Tina TSOU <[email-masked]>
Date: Sat, 24 Dec 2011 05:14:46 +0000

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Friday, December 23, 2011 11:02 AM
To: Tina TSOU
Cc: [email-masked]; [email-masked]
Subject: clarification on Axternal Address assignment [was RE: [pcp] pcp-base-19]

OLD (contents of -19):

NEW:

[Tina:
>From the client point of view, simpler and more straight forward, how about this?
"The client should request same external IP address if there is any existing mapping, unless there is an explicit reason for not doing so, e.g. [I-D.penno-pcp-zones]]."
]

-d