Re: [pcp] New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

[RAFAEL ALEJANDRO LOPEZ DA SILVA <[e-mail]>]

Hi Med:

Thank you for your suggestions, and as Andreas says we will have to describe better the scenario in a next version.

Just as an advance though on the options for the UPnP IGD-PCP IWF. Some operators are deploying layer 2 CPEs, while moving some layer 3 CPE functionalities to the network. With that you are extending the Layer 2 domain of the Home LAN into the ISP network. One of the Layer 3 CPE functionalities shifted to the network could be the UPnP IGD to PCP IWF, for allowing devices without PCP support request dynamic mappings to a CGN. To achieve scalability this IWF could be located off-path (even though with Layer 2 visibility of the Home devices) and use a mediation system to signal the mappings to the CGN on its behalf using the Tunnel Id option.

That is achievable with legacy CPEs in bridge mode.

Best
Rafael López da Silva


-----Mensaje original-----
De: pcp [mailto:[e-mail]] En nombre de [e-mail]
Enviado el: viernes, 11 de julio de 2014 16:45
Para: Andreas Ripke; [e-mail]
Asunto: Re: [pcp] New Version Notification for draft-ripke-pcp-tunnel-id-option-01.txt

Hi Andreas,

I'm curious to see how this can work with legacy CPEs.

Looking forward to reading an updated version of the draft.

Cheers,
Med

>-----Message d'origine-----
>De : Andreas Ripke [mailto:[e-mail]] Envoyé : vendredi
>11 juillet 2014 16:42 À : BOUCADAIR Mohamed IMT/OLN; [e-mail] Objet
>: RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
>01.txt
>
>Hi Med,
>
>Thanks for the hint on UPnP relay. This might not be necessary.
>Apparently, we have to describe the scenario in more detail.
>
>Best,
>
>Andreas
>
>> -----Original Message-----
>> From: [e-mail]
>> [mailto:[e-mail]]
>> Sent: Wednesday, July 09, 2014 4:27 PM
>> To: Andreas Ripke; [e-mail]
>> Subject: RE: New Version Notification for draft-ripke-pcp-tunnel-id-
>option-
>> 01.txt
>>
>> Re-,
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> >-----Message d'origine-----
>> >De : Andreas Ripke [mailto:[e-mail]] Envoyé :
>> >mercredi 9 juillet 2014 12:02 À : BOUCADAIR Mohamed IMT/OLN; [e-mail] Objet :
>> >RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
>> >01.txt
>> >
>> >Hi Med,
>> >
>> >Thanks for your comments.
>> >
>> >Our scenario is a supplement to situations when PCP is not yet on
>> >hand in the subscriber realm.
>> >The carrier IWF is offered as a service to the subscribers.
>> >It does not prevent subscribers to directly use PCP to control ports
>> >on the CGN.
>>
>> [Med] But how the CPE will decide to leak UPnP IGD outside the LAN?
>> Shouldn't this require an upgrade of the CPE to support some "kind"
>> of
>UPnP
>> IGD relay?
>>
>> >
>> >And thanks for your pointer to your pcp-sfc draft.
>> >It looks like the PCP TUNNEL_ID option aligns to this direction of
>> >an extension proposal.
>> >
>> >The decision we called the new option TUNNEL_ID was driven by the
>> >given scenario.
>> >Yes, it might be an idea to change and generalize the option name to
>> >ID instead of TUNNEL_ID.
>>
>> [Med] Great!
>>
>> >
>> >Best,
>> >
>> >Andreas
>> >
>> >> -----Original Message-----
>> >> From: [e-mail]
>> >> [mailto:[e-mail]]
>> >> Sent: Wednesday, July 09, 2014 10:42 AM
>> >> To: Andreas Ripke; [e-mail]
>> >> Subject: RE: New Version Notification for
>> >> draft-ripke-pcp-tunnel-id-
>> >option-
>> >> 01.txt
>> >>
>> >> Hi Andreas,
>> >>
>> >> Thank you for sharing this updated version of the document.
>> >>
>> >> I'm not sure about the carrier-hosted IWF because one of the
>> >> motivations for PCP to avoid overloading the carrier network with
>> >> a
>> chatty protocol.
>> >>
>> >> FWIW, I have identified in this document as case that require an
>> >> identification information that cannot be included in a
>> >> THIRD_PARTY
>> >option:
>> >> http://tools.ietf.org/html/draft-boucadair-pcp-sfc-classifier-cont
>> >> rol-
>00
>> >> "   o  Extended THIRD_PARTY option to include a L2 identifier (e.g.,
>MAC
>> >>       address), an opaque subscriber-identifier, an IMSI, etc."
>> >>
>> >> I suggest you change TUNNEL_ID to something that won't mislead the
>> >> reader that a tunneling technique is always in place when this
>> >> option is
>> >in
>> >> use.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >> >-----Message d'origine-----
>> >> >De : pcp [mailto:[e-mail]] De la part de Andreas
>> >> >Ripke Envoyé : vendredi 4 juillet 2014 13:05 À : [e-mail] Objet :
>> >> >[pcp]
>> >> >FW: New Version Notification for draft-ripke-pcp-tunnel-id-
>> >> >option-01.txt
>> >> >
>> >> >Dear all,
>> >> >
>> >> >Thank you for all the feedback we received at the last meeting on
>> >> >the TUNNEL_ID option. This was very helpful. We have updated our
>> >> >draft accordingly and aligned our use case with use cases from
>> >> >existing PCP drafts/RFCs. Particularly we moved the focus from a
>> >> >rather static web portal scenario to a more dynamic UPnP
>> >> >Interworking
>> scenario.
>> >> >
>> >> >http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-opt
>> >> >ion
>> >> >-01
>> >> >.txt
>> >> >
>> >> >Please have a look at the draft and give us your feedback.
>> >> >
>> >> >Best regards,
>> >> >
>> >> >Andreas
>> >> >
>> >> >
>> >> >NEC Europe Ltd | Registered Office: Athene, Odyssey Business
>> >> >Park, West End Road, London, HA4 6QE, GB | Registered in England
>> >> >2832014
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >A new version of I-D, draft-ripke-pcp-tunnel-id-option-01.txt
>> >> >has been successfully submitted by Andreas Ripke and posted to
>> >> >the IETF repository.
>> >> >
>> >> >Name:            draft-ripke-pcp-tunnel-id-option
>> >> >Revision:        01
>> >> >Title:           PCP Tunnel-ID Option
>> >> >Document date:   2014-07-03
>> >> >Group:           Individual Submission
>> >> >Pages:           10
>> >> >URL:            http://www.ietf.org/internet-drafts/draft-ripke-pcp-
>> >tunnel-
>> >> >id-option-01.txt
>> >> >Status:         https://datatracker.ietf.org/doc/draft-ripke-pcp-
>tunnel-
>> >id-
>> >> >option/
>> >> >Htmlized:       http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-
>> >> >option-01
>> >> >Diff:           http://www.ietf.org/rfcdiff?url2=draft-ripke-pcp-
>tunnel-
>> >id-
>> >> >option-01
>> >> >
>> >> >Abstract:
>> >> >   This document describes a new Port Control Protocol (PCP) option
>> >> >   called TUNNEL_ID.  It serves for identifying a Third Party in
>> >> >   addition to the means that PCP's THIRD_PARTY option already
>provides
>> >> >   for that purpose.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >Please note that it may take a couple of minutes from the time of
>> >> >submission until the htmlized version and diff are available at
>> >> >tools.ietf.org.
>> >> >
>> >> >The IETF Secretariat
>> >> >
>> >> >_______________________________________________
>> >> >pcp mailing list
>> >> >[e-mail]
>> >> >https://www.ietf.org/mailman/listinfo/pcp

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

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição