Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

[<[e-mail]>]

Andreas, 

An additional use case that does not require the THIRD_PARTY option together with THIRD_PARTY_ID is described in http://tools.ietf.org/html/draft-reddy-pcp-sdn-firewall-00.

A reference to THIRD_PARTY_ID option is explicitly called out in that document. An excerpt is provided below: 

" The encoding in Section 3 and the support of the
   THIRD_PARTY_ID ([I-D.ripke-pcp-tunnel-id-option]) covers most of
   these functionalities. " 

Cheers,
Med

-----Message d'origine-----
De : pcp [mailto:[e-mail]] De la part de [e-mail]
Envoyé : mardi 16 décembre 2014 07:34
À : Andreas Ripke; [e-mail]
Objet : Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

Hi Andreas,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : pcp [mailto:[e-mail]] De la part de Andreas Ripke
Envoyé : lundi 15 décembre 2014 17:26
À : [e-mail]
Objet : Re: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-00

Hi,

Med's comments contain two technical modifications.

1. A recommended fixed maximum option length of 128 octets.

Why should we (unnecessarily?) set an explicit limit to this option?
The fixed option length (16 octets) was changed to a variable length with the current draft version.
The maximum PCP packet size is 1100 octets and the client must ensure not to cause an overrun according to RFC6887.
But then, in RFC7220 the maximum variable length for the description option is limited to 1016 octets.
Is there any special reason to have an explicit maximum option length defined?

[Med] Fixing a maximum is required to help dimensioning the server and to avoid exhausting server's resources. Most of the identifiers I'm aware of don't exceed 128 octets. Hence my recommendation to use that maximum. 


2. The newly specified THIRD_PARTY_ID option can be used alone without the THIRD_PARTY option.

The THIRD_PARTY_ID option is defined as an extension to the THIRD_PARTY option in case the THIRD_PARTY address is not sufficient.
Using the THIRD_PARTY_ID alone  seems to be a very special use case.
Is there a practical application to it?

[Med] A host directly connected to a network or a CPE embedding a PCP client can use this option to carry the identifier. The internal IP address is carried in the opcode header; no need for the THIRD_PARTY in that case. Injecting both a THIRD_PARTY option and this one is deployment-specific. 

Andreas


> -----Original Message-----
> From: pcp issue tracker [mailto:[e-mail]]
> Sent: Thursday, December 11, 2014 10:23 PM
> To: [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: [pcp] #74 (third-party-id-option): Mohamed Boucadair's comments on
> draft-ietf-pcp-third-party-id-option-00
> 
> #74: Mohamed Boucadair's comments on draft-ietf-pcp-third-party-id-option-
> 00
> 
>  Comments inline in PDF copy currently at
>  http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-id-
>  option-00-Med.pdf
> 
> --
> -------------------------------------+-------------------------------------
>  Reporter:                           |      Owner:  draft-ietf-pcp-third-
>   [e-mail]       |  [e-mail]
>      Type:  defect                   |     Status:  new
>  Priority:  major                    |  Milestone:  milestone1
> Component:  third-party-id-option    |    Version:  1.0
>  Severity:  In WG Last Call          |   Keywords:
> -------------------------------------+-------------------------------------
> 
> Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/74>
> pcp <http://tools.ietf.org/pcp/>

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

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