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

[<[e-mail]>]

Hi Rafael,

Thank you for the clarification. 

But given that a legacy CPE, even in the bridge mode, does not leak UPnP IGD messages in the WAN interface, I guess an upgrade is still needed to relax that?

BTW, are you aware of tests that have been conducted to confirm this behavior (I'm talking about the UPnP IGD leg)?

Thank you.

Cheers,
Med

>-----Message d'origine-----
>De : RAFAEL ALEJANDRO LOPEZ DA SILVA
>[mailto:[e-mail]]
>Envoyé : vendredi 11 juillet 2014 17:00
>À : BOUCADAIR Mohamed IMT/OLN; Andreas Ripke; [e-mail]
>Objet : RE: New Version Notification for draft-ripke-pcp-tunnel-id-option-
>01.txt
>
>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