Re: [pcp] Resolving contentious issue #3

Med:

It seems that the DSCP remarking would be done in a dedicated IE, right?
Then, it would seem that what you need is a Mandatory bit semantic **within** that IE,
not a global M bit... Am I missing something?

  - Alain.

On Nov 3, 2010, at 2:53 AM, <mohamed.boucadair@orange-ftgroup.com> wrote:

>   Dear all,
> 
>   In some cases the PCP Server should be instructed it must honour
>   a request received from the PCP Client.  Examples of such cases is
>   DSCP re-marking policies or returning the external perceived IP
>   Address/port to detect the presence of the NAT.
> 
>   For illustration purposes, let focus on the DSCP marking case, the
>   PCP Client should have means to assess whether
> 
>   1.  The PCP Server is able to enforce DSCP (re-)marking policies; in
>       other words the PCP Server must support DSCP IE.
> 
>   2.  Its requested DSCP markings policies (direction: IN, OUT or both)
>       has been successfully enforced by the PCP Server.  If the PCP Server
>       fails to satisfy the DSCP marking policy as requested by the PCP
>       Client, an error should be returned back to the PCP Client.
> 
>   A solution is to define a dedicated IE to instruct the PCP Server it
>   MUST honour the request received from a PCP Client. The format of this
>   IE is as follows:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   IE Code     | Reserved      |             0x00              |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>   Mandatory IE
> 
>   1.  This IE can be included as the only IE in a request.  In such
>       case, it is like the M-bit.
> 
>   2.  It can be included together with other IEs such as DSCP IE: The
>       PCP Server must support those IEs and must satisfy the request,
>       otherwise an error should be returned.
> 
> 
>   The UPnP IGD-PCP IWF can be designed without a M-bit (see for
>   instance http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.1) or with a
>   M-bit as described in http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-00#section-5.7.2.2.  There are
>   tradeoffs between the two alternatives.  Having the Mandatory-IE
>   described above allows to design an UPnP IGD-PCP IWF in both modes.
> 
>   Cheers,
> 
>   Med
> 
> PS: The idea of the Mandatory-IE came in a discussion I had with Alain.
> 
> 
> 
> 
> -----Message d'origine-----
> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Alain Durand
> Envoyé : mercredi 3 novembre 2010 00:29
> À : pcp@ietf.org
> Cc : Dave Thaler
> Objet : [pcp] Resolving contentious issue #3
> 
> The issue is: do we need a mandatory bit in the packet format?
> 
> It has been argued that a mandatory bit would simplify the UPnP/PCP inter-networking function.
> So, the first question to resolve is:
> 
> 3a: Is there a need for a mandatory bit for the pure PCP case? (ie outside the UPnP relay case)?
> I have not heard any argument in that direction so far, so if there is a need there, now is the time to articulate it.
> 
> The second question to resolve is:
> 3b: for the UPnP intern-etworking function, a mandatory bit would simplify the server side implementation
> because there will be less state to keep. Does this outweigh the added complexity in the protocol?
> It has been argued that UPnP apps would go away and be replaced by PCP apps, so we can envision
> a not too far future where the UPnP relay is not needed, so if the answer to 3a) is no, then PCP would
> be better off long term by not having a mandatory bit.
> 
> I would like to open a 48 hour discussion window until Nov 4th, 5pm pacific time.
> 
>   - Alain.
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp
> 
> *********************************
> This message and any attachments (the "message") are confidential and intended solely for the addressees. 
> Any unauthorised use or dissemination is prohibited.
> Messages are susceptible to alteration. 
> France Telecom Group shall not be liable for the message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
> ********************************
> 