Re: [pcp] Revising PANA side-by-side approach

Hi Margaret:

Just a clarification below.

El 06/10/2012, a las 02:58, Margaret Wasserman escribió:

> 
> Hi Yoshi,
> 
>>> 1) Provide a clear explanation of what parts of PANA will be used with PCP.   For example, the notion of a network access enforcement point doesn't really make sense in a PCP context.
>> 
>> I agree that EP is not needed in the context of PCP authentication. We probably do not need
>> to use 'I' (IP Reconfiguration) and 'P' (Ping) flags either.
> 
> I doubt we have any major disconnect regarding what parts of PANA would/wouldn't be used with PCP.  However, we need to capture that understanding and document it, for people who are attempting to implement PANA for use with PCP.  I believe we will find that we are only using a fairly small subset of PANA for this purpose.

Let me give some insight regarding your last sentence here. For people who are implementing PANA (we are, for example), Flags I (IP Reconfiguration) and P represents nearly nothing in source code. So removing it, it does not imply too much.

Curiously, OpenPANA does not add code for IP reconfig so far (it just includes #define I_FLAG). Adding it, it would not be a problem at all. However, it would not imply too much source code either.

Regarding PANA ping:
-- It would imply 4 transitions in PaC and PAA state machines, which is basically nothing.
-- In OpenPANA, it also includes alarm management once PaC is authenticated. It would imply to remove 15-20 lines of source code. Again, nothing.

Thus, if these are just the features that we do not have to implement to support PANA in the context PCP, it means we are still using a lot of PANA.

Best regards.  

> 
>>> 2) Describe a clean mechanism that allows PANA to be used for authentication of other protocols.
>>> 
>>> Overloading a single bit in the PCP version field, because it happens to coincide with a flag bit in PANA doesn't seem like a method that will work for other protocols, and I am concerned that it doesn't provide a clean basis for moving forward.
> 
> The cleanest mechanism, IMO, would be to define a demultiplexing header that is used to determine whether the contents beyond that header are a PCP packet or a PANA packet.  If we want to send that header over the PCP port, though, it needs to look like a PCP header, which quickly devolves to the encapsulation approach.
> 
> Margaret
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
-------------------------------------------------------